feat: allow sending a custom proxy timeout error #1650
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When using `proxyTimeout` it's very difficult to tell the difference
between a regular socket hangup and a timeout because, in both cases, an
`ECONNRESET` 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 appropriate `504` 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:
```js
var proxy = httpProxy.createProxyServer({
target: 'http://example.com',
proxyTimeout: 100,
proxyTimeoutCustomError: true
});
```
Then the error that gets thrown will have a message of `"The proxy
request timed out"` and a code of `ETIMEDOUT` to match Node.js:
https://nodejs.org/api/errors.html#common-system-errors
This allows for custom error handling code like this:
```js
proxy.on('error', function(err, req, res) {
if (err.code === 'ETIMEDOUT') {
res.writeHead(504);
} else {
res.writeHead(503);
}
// ...
});
```
Resolves http-party#1331.
|
Hi, I took the liberty of implementing this in my fork. https://github.com/squarecloudofc/http-proxy |
Denoder
added a commit
to refactorjs/http-proxy
that referenced
this pull request
Oct 22, 2023
Added Pull Request from: - http-party/node-http-proxy#1634 - http-party/node-http-proxy#1638 - http-party/node-http-proxy#1650 fix tests that were having issues with the ports (if it fails the tests needs to be reran, seems to be an async issue)
ravin00
suggested changes
Oct 29, 2024
| timeoutError.code = 'ETIMEDOUT'; | ||
| return proxyReq.destroy(timeoutError); | ||
| } | ||
| proxyReq.destroy(); |
| expect(err).to.be.an(Error); | ||
| expect(errReq).to.be.equal(req); | ||
| expect(errRes).to.be.equal(res); | ||
| expect(new Date().getTime() - started).to.be.greaterThan(99); |
There was a problem hiding this comment.
what about adding the expect(new Date().getTime() - started).to.be.above(99); . Will it make a difference to this line or to the whole code
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
proxyTimeoutit's very difficult to tell the difference between a regular socket hangup and a timeout because, in both cases, anECONNRESETerror 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 appropriate504status 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
ECONNRESETerror. 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 ofETIMEDOUTto 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 whenproxyTimeoutCustomErroris falsy.Resolves #1331.