fix(websocket): handle errors in handleUpgrade #823
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
When there is an error from user-provided code (
pathFilter
,rewritePath
, orrouter
), that error is now handled and exposed to the user viaproxy.emit('error', ...)
.error-response-plugin
was also updated to handle the fact that it might receive a socket. If it does, it will callsocket.destroy()
.Motivation and Context
See #822 for a description of the issue being fixed. This PR closes #822.
How has this been tested?
I added a new test case. It fails on master, and works correctly with my new changes.
Types of changes
I'm split on whether or not this should be considered a breaking change. Folks could have written code assuming that the error handler would always get a
Response
as the third argument, whereas now it would get aSocket
. That said, the TypeScript types fromhttp-proxy
do reflect that that could be aSocket
, so it shouldn't come as too much of a surprise.Checklist: