mirror of
https://github.com/curl/curl.git
synced 2024-11-27 05:50:21 +08:00
.. | ||
.cvsignore | ||
arpa_telnet.h | ||
base64.c | ||
base64.h | ||
ca-bundle.crt | ||
ca-bundle.h.in | ||
config-mac.h | ||
config-riscos.h | ||
config-vms.h | ||
config-win32.h | ||
connect.c | ||
connect.h | ||
content_encoding.c | ||
content_encoding.h | ||
cookie.c | ||
cookie.h | ||
curllib.dsp | ||
curllib.dsw | ||
dict.c | ||
dict.h | ||
dllinit.c | ||
easy.c | ||
escape.c | ||
escape.h | ||
file.c | ||
file.h | ||
formdata.c | ||
formdata.h | ||
ftp.c | ||
ftp.h | ||
getdate.c | ||
getdate.h | ||
getdate.y | ||
getenv.c | ||
getinfo.c | ||
getinfo.h | ||
getpass.c | ||
getpass.h | ||
hash.c | ||
hash.h | ||
hostip.c | ||
hostip.h | ||
http_chunks.c | ||
http_chunks.h | ||
http.c | ||
http.h | ||
if2ip.c | ||
if2ip.h | ||
inet_ntoa_r.h | ||
krb4.c | ||
krb4.h | ||
ldap.c | ||
ldap.h | ||
libcurl.def | ||
llist.c | ||
llist.h | ||
Makefile.am | ||
Makefile.b32 | ||
Makefile.b32.resp | ||
Makefile.m32 | ||
Makefile.riscos | ||
Makefile.vc6 | ||
memdebug.c | ||
memdebug.h | ||
mprintf.c | ||
multi.c | ||
netrc.c | ||
netrc.h | ||
progress.c | ||
progress.h | ||
README.encoding | ||
security.c | ||
security.h | ||
sendf.c | ||
sendf.h | ||
setup.h | ||
share.c | ||
share.h | ||
speedcheck.c | ||
speedcheck.h | ||
ssluse.c | ||
ssluse.h | ||
strequal.c | ||
strequal.h | ||
strtok.c | ||
strtok.h | ||
telnet.c | ||
telnet.h | ||
timeval.c | ||
timeval.h | ||
transfer.c | ||
transfer.h | ||
url.c | ||
url.h | ||
urldata.h | ||
version.c |
Content Encoding Support for libcurl * About content encodings: HTTP/1.1 [RFC 2616] 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' [sec 3.5, RFC 2616]. A client requests that the sever 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). 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. * Current support for content encoding: I added support for the 'deflate' content encoding to both libcurl and curl. Both regular and chunked transfers should work although I've tested only the former. The library zlib is required for this feature. Places where I modified the source code are commented and typically include my initials and the date (e.g., 08/29/02 jhrg). * The libcurl interface: To cause libcurl to request a content encoding use: curl_easy_setopt(curl, CURLOPT_ENCODING, <string>) where <string> is the intended value of the Accept-Encoding header. Currently, libcurl only understands how to process responses that use the `deflate' Content-Encoding, so the only value for CURLOPT_ENCODING that will work (besides "identity," which does nothing) is "deflate." If a response is encoded using either the `gzip' or `compress' methods, libcurl will return an error indicating that the response could not be decoded. If <string> is null or empty no Accept-Encoding header is generated. * The curl interface: Use the --compressed option with curl to cause it to ask servers to compress responses using deflate. James Gallagher <jgallagher@gso.uri.edu>