http2: refactor error handling #14991

mcollina · 2017-08-23T16:35:12Z

This changes the error handling model of ServerHttp2Stream,
ServerHttp2Request and ServerHttp2Response.
An 'error' emitted on ServerHttp2Stream will not go to
'uncaughtException' anymore, but to the server 'clientError'.
On the stream 'error', ServerHttp2Request will emit 'abort', while
ServerHttp2Response would do nothing

See: #14963

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

http2

mcollina · 2017-08-23T16:35:25Z

cc @nodejs/http2 @akc42

jasnell · 2017-08-23T16:36:30Z

lib/internal/http2/compat.js

@@ -58,8 +58,12 @@ function onStreamEnd() {
 }

 function onStreamError(error) {
-  const request = this[kRequest];
-  request.emit('error', error);
+  // this is purpusefully left blank


s/purpusefully/purposefully

jasnell · 2017-08-23T16:37:20Z

lib/internal/http2/core.js

+    const server = session[kServer];
+
+    if (err && server) {
+      server.emit('clientError', err, this);


question: should this be nextTick'd?

I think so - or at least I'd expect it to. Do we have a guarantee that it will always be deferred by the time _destroy is called?

there is a nextTick on top, https://github.com/nodejs/node/blob/master/lib/internal/http2/core.js#L1509

_destroy is called synchronously. But the error of the _destroy callback will be emitted asynchronously, see https://github.com/nodejs/node/blob/master/lib/internal/streams/destroy.js#L32-L37.

jasnell

LGTM but it may be good to add some detail to the documentation.

benjamingr

LGTM with 2 nits - would love docs for the newly exposed Http2Stream and Http2Session

benjamingr · 2017-08-23T18:40:18Z

lib/http2.js

@@ -28,4 +30,6 @@ module.exports = {
  connect,
  Http2ServerResponse,
  Http2ServerRequest,
+  Http2Session,


I'm fine with this - but increasing the surface of the API is not trivial - and I'd like to see docs.

I've added them just for test purpose. I'll require the internals.

benjamingr · 2017-08-23T18:42:07Z

lib/internal/http2/core.js

+    const server = session[kServer];
+
+    if (err && server) {
+      server.emit('clientError', err, this);


I think so - or at least I'd expect it to. Do we have a guarantee that it will always be deferred by the time _destroy is called?

akc42 · 2017-08-24T06:09:48Z

The two use cases I have been battling with is

Client sends a last ditch "release_locks" api call on window unload, but has gone away before that api call completes and calls response.end(). I want to catch that situation and log that it has occurred - not have the server crash. But this is distinctly different from ...
When client requests a static file that doesn't exist. This might be because the file genuinely doesn't exist (and therefore I send a 404), or because the client has tried to open a client side route which I need to respond with index.html. I don't really want to be opening a file just to check that prior to using respondWithFile. From a compat layer point of view, it might be better to hoist the core function on the ServerHttp2Stream to the ServerHttp2Response and have that error on this.

mcollina · 2017-08-24T10:18:35Z

I have moved Http2Stream from emitting 'clientError' to emitting 'streamError', because 'clientError' has a specific semantics on HTTP1, and we cannot provide that semantic with HTTP2.

mcollina · 2017-08-24T14:31:06Z

I've added a commit that introduces onError for respondWithFile, that should allow to handle 404 or redirects correctly (cc @akc42).

@jasnell @benjamingr please reaffirm your LGTM. It has changed enough to be worth a fresh review.

mcollina · 2017-08-24T14:32:02Z

CI: https://ci.nodejs.org/job/node-test-pull-request/9824/

mcollina · 2017-08-24T14:32:29Z

This would be a semver-major change if we were not experimental.

jasnell

I likes it!

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs#14963 PR-URL: nodejs#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

jasnell · 2017-08-25T21:30:12Z

Landed in 4ca8ff2

Trott · 2017-08-26T19:26:35Z

Sorry to report: This has broken CI.

By all appearances, this should never have landed in this condition. The CI was not green. One of the tests added failed on all Windows variants.

Trott · 2017-08-26T19:33:23Z

Windows test failure with this:

https://ci.nodejs.org/job/node-test-binary-windows/10729/RUN_SUBSET=1,VS_VERSION=vcbt2015,label=win10/console

not ok 202 parallel/test-http2-respond-file-404
  ---
  duration_ms: 0.170
  severity: fail
  stack: |-
    (node:4708) ExperimentalWarning: The http2 module is an experimental API.
    assert.js:42
      throw new errors.AssertionError({
      ^
    
    AssertionError [ERR_ASSERTION]: 'ENOENT: no such file or directory, open \'c:\\workspace\\node-test-binary-windows\\RUN_SUBSET\\1\\VS_VERSION\\vcbt2015\\label\\ === 'ENOENT: no such file or directory, open \'./not-a-file\''
        at c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\common\index.js:715:16
        at c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\common\index.js:509:15
        at onError (c:\workspace\node-test-binary-windows\RUN_SUBSET\1\VS_VERSION\vcbt2015\label\win10\test\parallel\test-http2-respond-file-404.js:25:9)
        at ServerHttp2Stream.afterOpen (internal/http2/core.js:1704:7)
        at FSReqWrap.oncomplete (fs.js:135:15)

Trott · 2017-08-26T20:14:31Z

Reverted, so reopening so the test can be fixed and this can hopefully be re-landed soon.

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs#14963

Fixes: nodejs#14963

mcollina · 2017-08-27T12:56:31Z

CI: https://ci.nodejs.org/job/node-test-pull-request/9851/

(should be ok this time, please verify)

cc @jasnell

mcollina · 2017-08-27T20:52:22Z

Landed as 53c5bf5.

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: #14963 PR-URL: #14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing See: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: nodejs/node#14963 PR-URL: nodejs/node#14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

This changes the error handling model of ServerHttp2Stream, ServerHttp2Request and ServerHttp2Response. An 'error' emitted on ServerHttp2Stream will not go to 'uncaughtException' anymore, but to the server 'streamError'. On the stream 'error', ServerHttp2Request will emit 'abort', while ServerHttp2Response would do nothing. It also updates respondWith* to the new error handling. Fixes: #14963 PR-URL: #14991 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Benjamin Gruenbaum <[email protected]>

There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991

There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: #14991 PR-URL: #19232 Reviewed-By: James M Snell <[email protected]>

There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991 PR-URL: nodejs#19232 Reviewed-By: James M Snell <[email protected]>

There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: #14991 Backport-PR-URL: #19478 PR-URL: #19232 Reviewed-By: James M Snell <[email protected]>

There should be no default error handling when using Http2Stream. All errors will end up in `'streamError'` on the server anyway, but they are emitted on `'stream'` as well, otherwise some error conditions are impossible to debug. See: nodejs#14991 PR-URL: nodejs#19232 Reviewed-By: James M Snell <[email protected]>

mcollina requested a review from jasnell August 23, 2017 16:35

nodejs-github-bot added the http2 Issues or PRs related to the http2 subsystem. label Aug 23, 2017

jasnell reviewed Aug 23, 2017

View reviewed changes

jasnell approved these changes Aug 23, 2017

View reviewed changes

benjamingr approved these changes Aug 23, 2017

View reviewed changes

mcollina force-pushed the http2-errors branch 2 times, most recently from 22498dd to 4d49f2a Compare August 24, 2017 10:16

jasnell approved these changes Aug 24, 2017

View reviewed changes

jasnell closed this Aug 25, 2017

Trott mentioned this pull request Aug 26, 2017

Revert "http2: refactor error handling" #15047

Closed

1 task

Trott reopened this Aug 26, 2017

mcollina added 2 commits August 27, 2017 14:04

http2: respondWith* to the new error handling

2857f15

Fixes: nodejs#14963

mcollina force-pushed the http2-errors branch from 45708fe to 2857f15 Compare August 27, 2017 12:55

mcollina closed this Aug 27, 2017

mcollina mentioned this pull request Sep 1, 2017

test: increase Http2ServerResponse test coverage #15074

Closed

3 tasks

MylesBorins mentioned this pull request Sep 10, 2017

v8.5.0 proposal #15308

Merged

mcollina mentioned this pull request Sep 12, 2017

http2 - compat request forward error #15359

Closed

MylesBorins added the dont-land-on-v6.x label Sep 20, 2017

mcollina mentioned this pull request Mar 8, 2018

http2: fixes error handling #19232

Closed

3 tasks

mcollina mentioned this pull request Mar 20, 2018

[v9.x backport] http2: fixes error handling #19478

Closed

4 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

http2: refactor error handling #14991

http2: refactor error handling #14991

mcollina commented Aug 23, 2017 •

edited

Loading

mcollina commented Aug 23, 2017

jasnell Aug 23, 2017

jasnell Aug 23, 2017

benjamingr Aug 23, 2017

mcollina Aug 24, 2017 •

edited

Loading

jasnell left a comment

benjamingr left a comment

benjamingr Aug 23, 2017

mcollina Aug 24, 2017

benjamingr Aug 23, 2017

akc42 commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

jasnell left a comment

jasnell commented Aug 25, 2017

Trott commented Aug 26, 2017

Trott commented Aug 26, 2017

Trott commented Aug 26, 2017

mcollina commented Aug 27, 2017

mcollina commented Aug 27, 2017

http2: refactor error handling #14991

http2: refactor error handling #14991

Conversation

mcollina commented Aug 23, 2017 • edited Loading

Checklist

Affected core subsystem(s)

mcollina commented Aug 23, 2017

jasnell Aug 23, 2017

Choose a reason for hiding this comment

jasnell Aug 23, 2017

Choose a reason for hiding this comment

benjamingr Aug 23, 2017

Choose a reason for hiding this comment

mcollina Aug 24, 2017 • edited Loading

Choose a reason for hiding this comment

jasnell left a comment

Choose a reason for hiding this comment

benjamingr left a comment

Choose a reason for hiding this comment

benjamingr Aug 23, 2017

Choose a reason for hiding this comment

mcollina Aug 24, 2017

Choose a reason for hiding this comment

benjamingr Aug 23, 2017

Choose a reason for hiding this comment

akc42 commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

mcollina commented Aug 24, 2017

jasnell left a comment

Choose a reason for hiding this comment

jasnell commented Aug 25, 2017

Trott commented Aug 26, 2017

Trott commented Aug 26, 2017

Trott commented Aug 26, 2017

mcollina commented Aug 27, 2017

mcollina commented Aug 27, 2017

mcollina commented Aug 23, 2017 •

edited

Loading

mcollina Aug 24, 2017 •

edited

Loading