-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
http: client aborted should be boolean. #20230
Conversation
doc/api/http.md
Outdated
@@ -1288,6 +1287,13 @@ the server, then sockets are destroyed when they time out. If a handler is | |||
assigned to the request, the response, or the server's `'timeout'` events, | |||
timed out sockets must be handled explicitly. | |||
|
|||
### response.aborted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should go before ### response.addTrailers(headers)
ABC-wise.
doc/api/http.md
Outdated
<!-- YAML | ||
added: REPLACEME | ||
--> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Properties need explicit types documented, in this case:
* {boolean}
doc/api/http.md
Outdated
added: REPLACEME | ||
--> | ||
|
||
If a request has been aborted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a typo or confusing API? response.aborted means request is aborted?
doc/api/http2.md
Outdated
@@ -2918,6 +2918,13 @@ the server, then [`Http2Stream`]()s are destroyed when they time out. If a | |||
handler is assigned to the request, the response, or the server's `'timeout'` | |||
events, timed out sockets must be handled explicitly. | |||
|
|||
### response.aborted |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This should go before
#### response.addTrailers(headers)
ABC-wise. - Heading level should be increased from
###
to####
.
doc/api/http2.md
Outdated
<!-- YAML | ||
added: REPLACEME | ||
--> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Properties need explicit types documented, in this case:
* {boolean}
doc/api/http2.md
Outdated
added: REPLACEME | ||
--> | ||
|
||
If a request has been aborted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it a typo or confusing API? response.aborted means request is aborted?
f854fb7
to
01820dd
Compare
doc/api/http.md
Outdated
|
||
* {boolean} | ||
|
||
<<<<<<< HEAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should not have passed a make test
. If it did, we need to update Makefile
to fix the conflict detection.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That was just me in a hurry. Apologies.
01820dd
to
3711eb5
Compare
@lpinca because of the test |
Ok, I'm pretty sure we are already testing the |
Like |
3711eb5
to
69d16fc
Compare
@lpinca fixed |
@@ -48,11 +48,13 @@ server.listen(0, () => { | |||
if (size > maxSize) { | |||
aborted = true; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be removed, and the assertion above changed to assert.strictEqual(req.aborted, false)
;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
69d16fc
to
0d5ccde
Compare
@ronag Can you rebase to resolve conflicts? It seems we need two reviews from the @nodejs/tsc as this is semver-major. |
Just out of curiosity, why is this change necessary/desirable? |
0d5ccde
to
793c2c3
Compare
@cjihrig: performance and consistency |
Rerun one failed task: https://ci.nodejs.org/job/node-test-commit-freebsd/17576/ (green). |
@nodejs/tsc Please review as this is semver-major. |
@nodejs/tsc, how can we proceed with this PR? |
@vsemozhetbyt this needs two @nodejs/tsc LGTMs to land. @ronag can you please elaborate on This requires a CITGM to land. CITGM (master): https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/1406/ |
Calling |
* {boolean} | ||
|
||
The `request.aborted` property will be `true` if the request has | ||
been aborted. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you add a changes:
block in the metadata for this property? (e.g. what we have for createServer()
further below in the file)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
793c2c3
to
0995002
Compare
changes: | ||
- version: REPLACEME | ||
pr-url: https://github.com/nodejs/node/pull/20230 | ||
description: The aborted property is no longer a timestamp number. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: aborted
-> `aborted`
?
We have 2 approvements from the TSC, so this is the final CI: I will land soon if there are no objections and CI is green (I can fix the doc nit on landing). |
PR-URL: #20230 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Landed in 4b00c4f |
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() ```
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() ```
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 #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. #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() ```
This is a semver-major.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes