Skip to content

Tags: HuangMeiheng/nock

Tags

v13.0.2

Toggle v13.0.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(intercept): mark Interceptors consumed immediately (nock#2033)

When an request is matched to an Interceptor, mark it consumed immediately so
that similar requests made in parallel don't get matched incorrectly.

This changes the behavior of aborted requests slightly.
Previously, an Interceptor was marked consumed just prior to the "response" event.
Now it will be marked consumed just prior to the "finished" event.
The change can only be noticed if a request is aborted while in a "finished" listener.

v13.0.1

Toggle v13.0.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix: allow Content-Type request introspection when header is an array (

…nock#2010)

* Gzipped request bodies also work when header is passed as an array (nock#2009)

v13.0.0

Toggle v13.0.0's commit message

Verified

This commit was signed with the committer’s verified signature.
mastermatt Matt R. Wilson
Merge branch 'beta' into next

# Conflicts:
#	README.md

v13.0.0-beta.5

Toggle v13.0.0-beta.5's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(ClientRequest): Use native `abort` and `destroy` (nock#2000)

- Stop monkey patching `abort` on the overridden `ClientRequest`.
- Stop prematurely associating the socket with the request.
- Prefer `destroy` instead of emitting an error when appropriate.

v13.0.0-beta.4

Toggle v13.0.0-beta.4's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
feat: remove socketDelay (nock#1974)

From a user's perspective, having both `delayConnection` and
`socketDelay` is confusing and unnecessarily.

The differences between the two are subtle, and in my experience, users
need to be fairly well versed in both the Node HTTP module and the
internals of Nock in order to accurately determine which to use.

On the surface there seems to be two use cases:
- A user wants to test how their code handles a `timeout` event.
  Whether their client is expected to abort the request, or some other
  action is taken in response to the event. Either way, the user
  doesn't care if wall-clock time passes, and would prefer the timeout
  be simulated so their test suite can get on with it.
- A user wants to force wall-clock time to pass before a `response` event.
  This is usually to test some timeout feature that is not based on the
  `timeout` event, or to give other code time to complete a task first.

Based on those two use cases, it seems obvious that there should be two
different delay functions, like we seem to have now. However, there are
two subtle aspects that blur the line.
- When a socket emits a `timeout` event, which the request propagates,
  the request does not end. This is true in Node and in Nock today.
  Clients my choose to abort a request upon a timeout event, they may not.
- In Nock today, when the socket is "applying" the artificial timeout,
  to determine if it should emit a `timeout`, it doesn't just use the
  value passed to `socketDelay`. It uses the sum of the values passed
  to `delayConnection` and `socketDelay`. This covers the flow of a
  user wanting to ensure their code sees a `timeout` event even if no
  action is taken.

Therefore, there is no reason to have two different options for users.
The value passed to `delayConnection` can trigger a `timeout` event
right away and if the code chooses not to act on the event, then it
will wait in real time until `response` is triggered.

In fact, when I began working on this, I went into the
`test_socket_delay.js` file and replaced all `socketDelay` with
`delayConnection`. All the tests passed.

Other minor tweaks included in this change:
- The delay methods on the Interceptor are now just setters instead
  of additive. This was undocumented, unintuitive behavior.
- Fixed a bug from nock#1973, where `replayWithError` would cause
  Interceptors to be consumed twice.

BREAKING CHANGE:

- `socketDelay` has been removed. Use `delayConnection` instead.
- `delay`, `delayConnection`, and `delayBody` are now setters instead of additive.
  example:

```js
nock('http:https://example.com')
  .get('/')
  .delay(1)
  .delay({ head: 2, body: 3 })
  .delayConnection(4)
  .delayBody(5)
  .delayBody(6)
  .reply()
```

Previously, the connection would have been delayed by 7 and the body delayed by 14.
Now, the connection will be delayed by 4 and the body delayed by 6.

v13.0.0-beta.3

Toggle v13.0.0-beta.3's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
feature: remove Scope.log in favor of more debug (nock#1966)

Consolidates the behavior around debugging and logging to exclusively use [`debug`](https://github.com/visionmedia/debug).

The use of `scope.log(console.log)` was problematic and confusing for consumers as that
appeared to be the correct approach when debugging unless they found the correct section in the README.
The use of the logger vs directly using `debug` in the core of Nock was inconsistent, especially when matching.
Now any failure to match a request will be directed to `debug` and if a single Interceptor is in context,
the namespace in the log will include the host from the Scope. This allows for filtering of logs to stdout
as well as differentiating colors from `debug`, when enabled.

BREAKING CHANGE:  `Scope.log` has been removed. Use the `debug` library when [debugging](https://github.com/nock/nock#debugging) failed matches.

v13.0.0-beta.2

Toggle v13.0.0-beta.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(router): bring behavior of `abort()` inline with native Node (noc…

…k#1960)

Nocks behavior around events and errors relating to aborting and ending requests has not lined up
with Node for while. I dug into an investigation of how it differs, if there were git commits/pull-requests explaining why they differ,
and trying to answer the question of should Nock change to line up better.

The single largest deviation were the errors emitted around aborting or already aborted requests.
Emitting an error on abort was added to fix issue nock#439.
The conversation talks about how Node emits an error post abort.
> ... in practice the `http` module does emit an `ECONNRESET` error after aborting. ... - Jan 7, 2016

However, this is only true between the 'socket' and 'response' events.
Otherwise calling abort does not emit an error of any kind.

Determining exactly what Nock should do is a bit of moving target.
As Node's internals of HTTP, Net, Stream, and micro task timing have changed a lot since
iojs/v4, when Nock added these errors, and v13, current at this time.

My conclusion is that none of Nock's deviations from Node's _documented_ behavior
are user features that should be maintained. If anything, bringing Nock closer to Node
better fulfills original requests.
nock#282

The entire `test_abort.js` file was scraped and rewritten by writing assertions against Node behavior, without Nock first.
Then adding Nock into each test to ensure events and errors were correct.

BREAKING CHANGE:

Calling `request.abort()`:
- Use to always emit a 'socket hang up' error. Now only emits the error if `abort` is called between the 'socket' and 'response' events.
- The emitted 'abort' event now happens on `nextTick`.
- The socket is now only destroyed if the 'socket' event has fired, and now emits a 'close' event on `nextTick` that propagates though the request object.
- `request.aborted` attribute is set to `true` instead of a timestamp. Changed in Node v11.0 nodejs/node#20230

Calling `write`, `end`, or `flushHeaders` on an aborted request no longer emits an error.
However, writing to a request that is already finished (ended) will emit a 'write after end' error.

Playback of a mocked responses will now never happen until the 'socket' event is emitted.
The 'socket' event is still artificially set to emit on `nextTick` when a ClientRequest is created.
This means in the following code the Scope will never be done because at least one tick needs
to happen before any matched Interceptor is considered consumed.
```js
const scope = nock(...).get('/').reply()
const req = http.get(...)
scope.done()
```

v13.0.0-beta.1

Toggle v13.0.0-beta.1's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
chore: remove body matching using "*" using definitions (nock#1964)

* chore: remove body matching using "*" using definitions

BREAKING CHANGE: Skipping body matching using "*" is no longer supported.
Set the definition `body` to `undefined` instead.

v12.0.3

Toggle v12.0.3's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(router): stall finish event to avoid dup (nock#1954)

* fix(router): stall finish event to avoid dup

Delays the emitting of the "finish" event on the request until it knows for sure an Interceptor is going to playback.
This stops a double emit for unmocked requests.

Also removes the "end" event from firing on the request. This event was added in the first commit with code for Nock
and was used to kicked off the internals that now live in `startPlayback`.
nock@31a500c#diff-503754c07b5098227646f913eee85885R27-R76

closes nock#1832

v12.0.2

Toggle v12.0.2's commit message

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
fix(types): remove inaccurate Scope.restore method (nock#1940)

This method does not exist and was added on accident.