feat: allow sending a custom proxy timeout error #1650
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.
When using
proxyTimeout
it's very difficult to tell the difference between a regular socket hangup and a timeout because, in both cases, anECONNRESET
error is thrown. Ideally we should be able to identify when a proxy request has failed because it took too long, this would allow us to do things like send appropriate504
status code.Suddenly throwing a different error would probably be considered a breaking change because it's possible that users of http-proxy are relying on the
ECONNRESET
error. I decided to add the custom timeout error behind a new option for now so that people can opt into using it.If you set this option:
Then the error that gets thrown will have a message of
"The proxy request timed out"
and a code ofETIMEDOUT
to match Node.js: https://nodejs.org/api/errors.html#common-system-errorsThis allows for custom error handling code like this:
A note on implementation
I had to switch from
request.abort()
torequest.destroy()
for this to work.request.abort()
has been deprecated since Node.js v14.1.0 andrequest.destroy()
has been available since Node.js v0.3.0 so I think this is a safe bet. If you're worried about it then I could always switch torequest.abort()
for the case whenproxyTimeoutCustomError
is falsy.Resolves #1331.