Skip to content
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

TODO: Support Multiple Content-Encodings #2002

Closed
wants to merge 1 commit into from
Closed
Changes from all commits
Commits
File filter...
Filter file types
Jump to…
Jump to file or symbol
Failed to load files and symbols.

Always

Just for now

TODO: Support Multiple Content-Encodings

  • Loading branch information...
danielbankhead committed Oct 20, 2017
commit 39a8226a526b4604ee72bfed145af0459645b698
@@ -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
@@ -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

ProTip! Use n and p to navigate between commits in a pull request.
You can’t perform that action at this time.