-
Notifications
You must be signed in to change notification settings - Fork 30k
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
http2: client browser refresh crashing the server. #15385
Comments
Related #15387? |
Ping @mcollina |
@apapirovski https://github.com/akc42/simple-server.git shows this, and I also built against yesterdays master and tried that, but no difference |
Thanks so much! As far as I can tell, comparing to http, we should not be throwing in this situation at all — it should just @mcollina Do you see any reason that in if (chunk !== null && chunk !== undefined) {
this.write(chunk, encoding);
}
if (stream === undefined) {
return;
} |
@akc42 I'm still looking at why it actually closes the stream, that bit seems weird. |
Ignore the comment above, the stream being closed made complete sense since the client aborted the request. It looks to me like you're listening to I'll get started on a PR to fix the incorrect Let me know if any of this doesn't line up for you though, @akc42. |
@apapirovski I was half way responding when you made your posts I presume what you are saying is that I'll get an 'aborted' event on the request and then response.end doesn't fail but silently returns. That is good for me. BUT according to the docs - there should have been a 'close' event on the response which I didn't get. I assume that should have happened at the same time the aborted event was thrown. |
Ah, yea I see what you mean. It doesn't look this was ever working for http2. Working on a PR. |
Fix Http2ServerRequest and Http2ServerResponse to emit close event if the request is aborted before response.end can be called. Fixes: nodejs#15385
This shouldn't really be closed until #15415 is |
Fixed in 8fa5fcc. |
Calling Http2ServerResponse.end multiple times should never cause the code to throw an error, subsequent calls should instead return false. Fix behaviour to match http1. Fixes: #15385 PR-URL: #15414 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Calling Http2ServerResponse.end multiple times should never cause the code to throw an error, subsequent calls should instead return false. Fix behaviour to match http1. Fixes: nodejs/node#15385 PR-URL: nodejs/node#15414 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Fix Http2ServerRequest and Http2ServerResponse to emit close event if the request is aborted before response.end can be called. Fixes: nodejs/node#15385 PR-URL: nodejs/node#15415 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Calling Http2ServerResponse.end multiple times should never cause the code to throw an error, subsequent calls should instead return false. Fix behaviour to match http1. Fixes: nodejs/node#15385 PR-URL: nodejs/node#15414 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Fix Http2ServerRequest and Http2ServerResponse to emit close event if the request is aborted before response.end can be called. Fixes: nodejs/node#15385 PR-URL: nodejs/node#15415 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This is with version 8.5.0 of node.
I have a situation where as the browser window is closing (or refreshing!) it sends a last ditch attempt to release locks that the user may hold. There is an api function for this which when it has completed calls
response.end('{}')
(I have a convention that all api calls should return a valid json object even if its a null object).I catch unhandled rejections and print the error stack, along with what url is being processed at the time. The url is a red herring (its a call several milliseconds into the new browser window starting up), but the error is real.
My server falls over with
What I believe is happening is the api call gets through, takes a while to make a database call to release the locks, and then tries to send the
response.end()
, by which time the original stream (and maybe even the session) have disappeared.I would have expected from the new compatability api docs that request would have fired an 'aborted' event at some point before this happens, but I log those and nothing happened.
Looking at the compat code, I can see the error would not have thrown if a callback had been provided to
response.write()
, but as is indicated in the stack this is called fromresponse.end()
where no callback is passed through. Regardless of this issue I do have an on('error') listener on the response. and that wasn't fired either. Should the error be sent there?The text was updated successfully, but these errors were encountered: