-
Notifications
You must be signed in to change notification settings - Fork 52
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
curl >=7.56 form post uses chunked transfer encoding, which is not supported by upstream libraries #204
Comments
looks like your downloaded response includes UTF8 BOM header. |
I can't fully reproduce this:
However, when I do this:
I do get a modified file. I looked at what curl is doing with a setup like this:
I found that the part boundary edge (including leading \r\n\r\n) begins with:
While the file itself begins with:
This is contrast to the response from pb:
|
@Earnestly I've known since the beginning that werkzeug meddles with request/form data in ways that contradict pb's goals, but I'm not able to reproduce your It appears that only the latter case causes this byte-mangling behavior. |
That's odd because
With
|
That's not showing the request body, so I don't know.
Hmm... Nice. I was using the old curl |
Looks like this is maybe a regression caused by curl/curl#1839 merged in 7.56
|
|
|
So this is all actually caused by curl 7.56 / curl/curl#1839 curl/curl@e6ececb switching to |
If I try this in a development environment, I get:
It's a miracle that the production deployment is giving you a paste response at all (some interaction between nginx and/or uwsgi). |
After doing some reading, I updated the production nginx configuration so that you now "correctly" get a 400 response when using chunked TE.
|
I was about to report this upstream, and it seems someone already has, for competitor ix.io: curl/curl#1965
Confirmed, if you don't use stdin, curl generates a non-chunked request:
As for actually fixing this, I need to drop/replace all of:
That's a complete rewrite. |
That's quite the rabbit hole, nice work at uncovering the core issues. As you (and I) mentioned, I have been using files directly instead of stdin for the time being. Thanks for all your effort, hopefully curl can get this fixed soon. |
Closing because curl reverted this behavior and fixing this is a rewrite anyway. |
Fixed in ptpb/apocrypha@d1a4c03 |
I'm not sure if there's an issue open for this already (I couldn't find one) and I'm not entirely sure if this is an issue with pb or
curl
, but here is what I'm experiencing.For a long time I've used
curl -F 'c=<-' 'https://ptpb.pw/?u=1'
and redirected anything I've uploaded using a pipeline or redirection, however lately when using redirection with images (png, jpeg, etc.) I'm getting nonsense.Here's an example:
However, this works if I use
curl -F 'c=@foo.png' 'https://ptpb.pw/?u=1'
. Both<-
and@-
seem to cause the same corruption and I'm not sure where to look to find out why.Thanks
The text was updated successfully, but these errors were encountered: