HTTP: support multiple Content-Encodings

This is implemented as an output streaming stack of unencoders, the last
calling the client write procedure.

New test 230 checks this feature.

Bug: https://github.com/curl/curl/pull/2002
Reported-By: Daniel Bankhead
This commit is contained in:
Patrick Monnerat 2017-11-05 15:09:48 +01:00
parent 462f3cac34
commit dbcced8e32
11 changed files with 736 additions and 283 deletions

View file

@ -673,7 +673,7 @@ Content Encoding
where string is the intended value of the Accept-Encoding header.
Currently, libcurl does not support multiple encodings and only
Currently, libcurl does support multiple encodings but only
understands how to process responses that use the "deflate" or "gzip"
Content-Encoding, so the only values for [`CURLOPT_ACCEPT_ENCODING`][5]
that will work (besides "identity," which does nothing) are "deflate"

View file

@ -67,7 +67,6 @@
5.7 Brotli compression
5.8 QUIC
5.9 Leave secure cookies alone
5.10 Support Multiple Content-Encodings
6. TELNET
6.1 ditch stdin
@ -538,12 +537,6 @@ This is not detailed in any FTP specification.
https://tools.ietf.org/html/draft-ietf-httpbis-cookie-alone-01
5.10 Support Multiple Content-Encodings
RFC 7231 Section 3.1.2.2 allows multiple encodings for a single request. Using
this may result in lower bandwidth and promotes a more resource-friendly web.
Currently, Chrome and Firefox support multiple encodings.
6. TELNET