Repository navigation
http2: client browser refresh crashing the server. #15385
Description
Activity
@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
return falseto match http.@mcollina Do you see any reason that in
Http2ServerResponse.endwe wouldn't swap the order of these two statements to match the http behaviour? (We would also need to check forstream.finishedin addition tostream === undefined.)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
abortrather thanabortedwhich explains why it's not logging. When I switched it toabortedit works as expected.I'll get started on a PR to fix the incorrect
endbehaviour though as it doesn't match the http module.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.
- added a commit that references this issue
on Sep 18, 2017 - added 2 commits that reference this issue
on Sep 20, 2017 - added a commit that references this issue
on Jul 27, 2026
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?