moparisthebest
/
curl
mirror of https://github.com/moparisthebest/curl
1
0
Fork 0
Code Issues Releases Wiki Activity

TODO: support multiple Content-Encodings 

Closes #2002
This commit is contained in:
Daniel Bankhead 2017-10-20 13:01:32 -04:00 committed by Daniel Stenberg
parent 516d3b9ff9
commit 1d0c8dea95
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
2 changed files with 33 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
docs/INTERNALS.md
View File

@ -656,27 +656,26 @@ Content Encoding
## About content encodings
[HTTP/1.1][4] specifies that a client may request that a server encode its
response. This is usually used to compress a response using one of a set of
commonly available compression techniques. These schemes are 'deflate' (the
zlib algorithm), 'gzip' and 'compress'. A client requests that the server
perform an encoding by including an Accept-Encoding header in the request
document. The value of the header should be one of the recognized tokens
'deflate', ... (there's a way to register new schemes/tokens, see sec 3.5 of
the spec). A server MAY honor the client's encoding request. When a response
is encoded, the server includes a Content-Encoding header in the
response. The value of the Content-Encoding header indicates which scheme was
used to encode the data.
response. This is usually used to compress a response using one (or more)
encodings from a set of commonly available compression techniques. These
schemes include 'deflate' (the zlib algorithm), 'gzip' and 'compress'. A
client requests that the server perform an encoding by including an
Accept-Encoding header in the request document. The value of the header
should be one of the recognized tokens 'deflate', ... (there's a way to
register new schemes/tokens, see sec 3.5 of the spec). A server MAY honor
the client's encoding request. When a response is encoded, the server
includes a Content-Encoding header in the response. The value of the
Content-Encoding header indicates which encodings were used to encode the
data, in the order in which they were applied.
A client may tell a server that it can understand several different encoding
schemes. In this case the server may choose any one of those and use it to
encode the response (indicating which one using the Content-Encoding header).
It's also possible for a client to attach priorities to different schemes so
that the server knows which it prefers. See sec 14.3 of RFC 2616 for more
information on the Accept-Encoding header.
information on the Accept-Encoding header. See sec [3.1.2.2 of RFC 7231][15]
for more information on the Content-Encoding header.
## Supported content encodings
The 'deflate' and 'gzip' content encoding are supported by libcurl. Both
The 'deflate' and 'gzip' content encodings are supported by libcurl. Both
regular and chunked transfers work fine. The zlib library is required for
this feature.
@ -688,14 +687,15 @@ Content Encoding
where string is the intended value of the Accept-Encoding header.
Currently, libcurl 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" and "gzip" If a response is encoded using the
"compress" or methods, libcurl will return an error indicating that the
response could not be decoded. If <string> is NULL no Accept-Encoding header
is generated. If <string> is a zero-length string, then an Accept-Encoding
header containing all supported encodings will be generated.
Currently, libcurl does not support multiple encodings and 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"
and "gzip". If a response is encoded using the "compress" or methods,
libcurl will return an error indicating that the response could
not be decoded. If <string> is NULL no Accept-Encoding header is generated.
If <string> is a zero-length string, then an Accept-Encoding header
containing all supported encodings will be generated.
The [`CURLOPT_ACCEPT_ENCODING`][5] must be set to any non-NULL value for
content to be automatically decoded. If it is not set and the server still
@ -1091,3 +1091,4 @@ for older and later versions as things don't change drastically that often.
[12]: https://curl.haxx.se/libcurl/c/curl_multi_fdset.html
[13]: https://curl.haxx.se/libcurl/c/curl_multi_add_handle.html
[14]: https://curl.haxx.se/libcurl/c/curl_multi_info_read.html
[15]: https://tools.ietf.org/html/rfc7231#section-3.1.2.2

11
docs/TODO
View File

@ -66,7 +66,8 @@
5.6 Refuse "downgrade" redirects
5.7 Brotli compression
5.8 QUIC
5.10 Leave secure cookies alone
5.9 Leave secure cookies alone
5.10 Support Multiple Content-Encodings
6. TELNET
6.1 ditch stdin
@ -530,13 +531,19 @@ This is not detailed in any FTP specification.
implemented. This, to allow other projects to benefit from the work and to
thus broaden the interest and chance of others to participate.
5.10 Leave secure cookies alone
5.9 Leave secure cookies alone
Non-secure origins (HTTP sites) should not be allowed to set or modify
cookies with the 'secure' property:
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