-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow access to chunked transfer trailers #570
Comments
At this point I'm open to forking the upstream project into a local mod or just write our own take. The one danger is request smuggling, care must be taken to ensure that's not possible. |
I'm in favor of accepting chunked responses with trailers, and maybe eventually providing access to them, though the interface would need some thought. I happen to have a branch where I already forked rust-chunked-transfer into a local mod, in pursuit of #559. I'll put that up for review now, independent of the #559 changes (which still need some work). |
ureq 3.x is accepting trailers, but they are skipped. This shouldn't be too hard to fix. |
The solve is not super easy. But something like |
I am talking to a webserver which uses chunked transfer encoding with an additional trailer, similar to what is explained here: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer
But I'm getting a "Error while decoding chunks" when requesting it with ureq. It's a bit similar to #325, but in this case the response is correct. Before the last '\r\n' the trailing headers are added to the response stream, which are then ended with a double set of '\r\n'.
I'm not necessarily interested in the trailing headers, but I am interested in properly reading the response without getting an error.
From what I've read in #454 and frewsxcv/rust-chunked-transfer#11 the double '\r\n' handling is done in the rust-chunked-transfer crate, but proper trailing handling is not the concern of the rust-chunked-transfer crate. That means that the rust-chunked-transfer crate should not or allow not to handle the double '\r\n' handling so ureq can process the trailing headers.
I'm not sure what the best approach is here or whether this is something you'd like to handle in ureq. I'd like to pick this up if it's clear what the approach would be.
The text was updated successfully, but these errors were encountered: