Timeline for How to properly handle a gzipped page when using curl?
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 26, 2022 at 19:03 | comment | added | Thanatos |
> But it does go on to say that servers SHOULD in that case not encode the content, hmm, go figure I think the part of the standard you're referencing ("An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response.") is for an empty Accept-Encoding: header. (vs. the header not being present at all.) (Unless you mean the next sentence, "If an Accept-Encoding header field is present in a request […] listed as acceptable", I think that just applies to other cases, but I agree it's confusingly worded.)
|
|
| Jan 5, 2021 at 4:56 | comment | added | x-yuri | A funny thing is that the man page say, "Headers are not modified." Although they clearly are. | |
| Apr 15, 2019 at 20:56 | comment | added | jonincanada | (and remove --raw if it's there). | |
| Jan 8, 2019 at 20:06 | comment | added | rjh |
Surprisingly, setting Accept-Encoding: deflate, gzip is not enough - even if the server returns a gzip response with Content-Encoding: gzip, curl won't automatically ungzip it. The --compressed flag is required.
|
|
| Apr 18, 2018 at 23:15 | comment | added | Faraway | help my QA with this solution in 1 minute ! thank you ! That said, my application is actually sending gzip response with Content-Encoding: gzip. Browsers and modern tools (e.g. httpie) automatically handles it. I guess curl just need a "hint" | |
| Feb 27, 2017 at 15:47 | comment | added | mbert | this also sets the request header: "Accept-Encoding: deflate, gzip" thats great since if the server serves gzip and no gzip, you just need --compressed and not add the accept encoding header yourself | |
| Jun 13, 2016 at 13:14 | comment | added | Radu Toader | actually on my version works --comp --compress --compressed | |
| Feb 21, 2013 at 16:37 | comment | added | George Lund | This would appear to be a curl bug, because it should trigger its decoding based on the response, not on what it requested (given that it does support gzip). To quote HTTP 1.1: "If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding." But it does go on to say that servers SHOULD in that case not encode the content, hmm, go figure. | |
| Dec 7, 2011 at 16:30 | vote | accept | BryanH | ||
| Dec 3, 2011 at 2:47 | history | answered | Martin | CC BY-SA 3.0 |