aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorDaniel Bankhead <dan@danielbankhead.com>2017-10-20 13:01:32 -0400
committerDaniel Stenberg <daniel@haxx.se>2017-10-28 11:01:32 +0200
commit1d0c8dea95794dd0591bdbf742de32e542365a3a (patch)
tree3e1504cd9d30f93cf9566ac2b52ca4d41bc14704
parent516d3b9ff9527a0acf1bd8796d521a7e0524e3c9 (diff)
TODO: support multiple Content-Encodings
Closes #2002
-rw-r--r--docs/INTERNALS.md49
-rw-r--r--docs/TODO11
2 files changed, 34 insertions, 26 deletions
diff --git a/docs/INTERNALS.md b/docs/INTERNALS.md
index 2e273a9dc..e2cebfabe 100644
--- a/docs/INTERNALS.md
+++ b/docs/INTERNALS.md
@@ -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.
-
- 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).
+ 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.
+
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
diff --git a/docs/TODO b/docs/TODO
index 264d559ad..b10323a9d 100644
--- a/docs/TODO
+++ b/docs/TODO
@@ -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