TODO: support multiple Content-Encodings

## 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.

 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

[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

 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

 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