Handling/ignoring undici errors
csvan opened this issue · 12 comments
🚀 Feature Proposal
Version 5.0 uses fastify-reply-from 5.0, which now uses Undici as default HTTP client.
In our projects, this has led to interesting new errors where calls will fail due to Undici errors, e.g
code: "UND_ERR_CONTENT_LENGTH_MISMATCH"
error: "Internal Server Error"
message: "Request body length does not match content-length header"
statusCode: 500
We did not see these under 4.0, and our clients are not having problem with anything not using Undici.
It would be nice if http-proxy could allow Undici errors to be ignored or otherwise handled.
Motivation
To give greater control to developers over what Undici errors can cause the proxy to fail, if any.
A couple of notes. You can always use Node.js http if you want. It's still fully supported.
FYI, UND_ERR_CONTENT_LENGTH_MISMATCH is being thrown if the Content-Length is different from what's in the Header.
Can you upload an example to reproduce the problem you are facing?
No, unfortunately it's happening on a proprietary API which I am not allowed share :-/
If I understand this correctly, it seems to be a problem with the proxied backend, which is running Spring. The request is a simple GET which returns a JSON object - don't know what Spring is doing but it seems indeed that the header and response size are differing.
But in either case - it would be nice to be able to ignore stuff like this since it is unique to undici and not something we would consider an error - no other http client we use have the same problem, and all seem to handle the differing sizes just fine.
However, maybe this is a problem that should be handled in fastify-reply-from?
No, unfortunately it's happening on a proprietary API which I am not allowed share :-/
A replication does not need to (and should not) include sensitive code.
Undici does not allow us to handle these cases, and there is nothing fastify-http-proxy or fastify-reply-from could do. The API you are calling is violating the HTTP specs. Undici is a lot stricter than other clients, even this could be possibly be lifted. I would essentially open an issue in undici itself and see if there some more "lenient" mode that could be added.
The support for more lenient parsing is using the node core library. Maybe we should document this clearly..
Yea, I suppose that would be the best way to handle this. Closing since - apart from adding documentation - there is nothing for http-proxy to do here. Thanks for the feedback!
For anybody landing on this issue looking for the previous behavior, simply add http: true to your config:
server.register(require('fastify-http-proxy'), {
upstream: 'http://my-api.example.com',
prefix: '/api',
http: true
})
Opened a ticket at Undici here: nodejs/undici#581
@csvan do u use fastify-http-proxy on k8s? Since I have the same issue, I can not reproduce it locally but it happens to me only on our k8s cluster
on the other side, there is fastify service pod, without any special manipulations on the content
http flag as boolean doesn't support anymore in latest version 7.0.0 and I am not sure how should I solve the UND_ERR_CONTENT_LENGTH_MISMATCH error as I am still getting the error using fastify-http-proxy with serverless.
@mayank2424 In case it's still relevant...
I solved the whole thing with these settings.
server.register(require('fastify-http-proxy'), {
upstream: 'http://my-api.example.com',
prefix: '/api',
undici: {
strictContentLength: false,
},
})
just in case its relevant because i couldn't make strictContentLength: false, work...
before registering plugin;
fastify.removeContentTypeParser("text/plain");
fastify.addContentTypeParser("*", { parseAs: "buffer" }, (req, body, done) => {
done(null, body);
});