From 64bbe9dfafc6693a96b742f3133c636385835a19 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 2 Sep 2002 22:31:18 +0000 Subject: James Gallagher's Content-Encoding work --- lib/README.encoding | 53 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 lib/README.encoding (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding new file mode 100644 index 000000000..ef5c8036f --- /dev/null +++ b/lib/README.encoding @@ -0,0 +1,53 @@ + + 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, ) + +where 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 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 -- cgit v1.2.1 From 019c4088cfcca0d2b7c5cc4f52ca5dac0c616089 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Fri, 11 Apr 2003 08:49:20 +0000 Subject: Dan Fandrich's gzip patch applied --- lib/README.encoding | 45 +++++++++++++++++++++++++-------------------- 1 file changed, 25 insertions(+), 20 deletions(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index ef5c8036f..5f878038e 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -5,15 +5,15 @@ 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. +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 @@ -24,11 +24,10 @@ 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). +Support for the 'deflate' and 'gzip' content encoding are supported by +libcurl. Both regular and chunked transfers should work fine. The library +zlib is required for this feature. 'deflate' support was added by James +Gallagher, and support for the 'gzip' encoding was added by Dan Fandrich. * The libcurl interface: @@ -39,15 +38,21 @@ To cause libcurl to request a content encoding use: where 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 is null -or empty no Accept-Encoding header is generated. +"deflate" or "gzip" Content-Encoding, so the only values for CURLOPT_ENCODING +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 + is NULL or empty no Accept-Encoding header is generated. + +The CURLOPT_ENCODING must be set to any non-NULL value for content to be +automatically decoded. If it is not set and the server still sends encoded +content (despite not having been asked), the data is returned in its raw form +and the Content-Encoding type is not checked. * The curl interface: Use the --compressed option with curl to cause it to ask servers to compress -responses using deflate. +responses using deflate. James Gallagher +Dan Fandrich -- cgit v1.2.1 From c0197f19cfcec0dd1ade0648d123b9399a6a1959 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Mon, 12 May 2003 12:45:14 +0000 Subject: Dan Fandrich changed CURLOPT_ENCODING to select all supported encodings if set to "". This frees the application from having to know which encodings the library supports. --- lib/README.encoding | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index 5f878038e..d81cf50fe 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -42,7 +42,9 @@ Currently, libcurl only understands how to process responses that use the 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 - is NULL or empty no Accept-Encoding header is generated. + is NULL no Accept-Encoding header is generated. If is a +zero-length string, then an Accept-Encoding header containing all supported +encodings will be generated. The CURLOPT_ENCODING must be set to any non-NULL value for content to be automatically decoded. If it is not set and the server still sends encoded -- cgit v1.2.1 From 1e5f6cc1dcf02ee156e4cbea0e9de49d4b9e1760 Mon Sep 17 00:00:00 2001 From: Dan Fandrich Date: Thu, 8 Dec 2005 18:59:19 +0000 Subject: Fixed a lingering omission of gzip support. --- lib/README.encoding | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index d81cf50fe..1666e239e 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -54,7 +54,7 @@ and the Content-Encoding type is not checked. * The curl interface: Use the --compressed option with curl to cause it to ask servers to compress -responses using deflate. +responses using any format supported by curl. James Gallagher Dan Fandrich -- cgit v1.2.1 From a07bc79117971b96ebf3188c0a34a73ee0a3609b Mon Sep 17 00:00:00 2001 From: Yang Tse Date: Sun, 14 Feb 2010 19:40:18 +0000 Subject: removed trailing whitespace --- lib/README.encoding | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index 1666e239e..ca9b4ec55 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -1,7 +1,7 @@ Content Encoding Support for libcurl -* About content encodings: +* 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 @@ -31,9 +31,9 @@ Gallagher, and support for the 'gzip' encoding was added by Dan Fandrich. * The libcurl interface: -To cause libcurl to request a content encoding use: +To cause libcurl to request a content encoding use: - curl_easy_setopt(curl, CURLOPT_ENCODING, ) + curl_easy_setopt(curl, CURLOPT_ENCODING, ) where is the intended value of the Accept-Encoding header. -- cgit v1.2.1 From 46b112bcd439f4413925a7300d66a3e6f148765e Mon Sep 17 00:00:00 2001 From: Yang Tse Date: Tue, 16 Feb 2010 13:32:45 +0000 Subject: replaced tabs with spaces --- lib/README.encoding | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index ca9b4ec55..0d31b3652 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -1,5 +1,5 @@ - Content Encoding Support for libcurl + Content Encoding Support for libcurl * About content encodings: -- cgit v1.2.1 From 5aae3c13e2ce95c1e06e8512948f5caac118aa1c Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Thu, 14 Apr 2011 22:59:34 +0200 Subject: transfer-encoding: document the options The new libcurl and command line options are now described. --- lib/README.encoding | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) (limited to 'lib/README.encoding') diff --git a/lib/README.encoding b/lib/README.encoding index 0d31b3652..1012bb9ec 100644 --- a/lib/README.encoding +++ b/lib/README.encoding @@ -33,21 +33,21 @@ Gallagher, and support for the 'gzip' encoding was added by Dan Fandrich. To cause libcurl to request a content encoding use: - curl_easy_setopt(curl, CURLOPT_ENCODING, ) + curl_easy_setopt(curl, CURLOPT_ACCEPT_ENCODING, ) where 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_ENCODING -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 - is NULL no Accept-Encoding header is generated. If is a -zero-length string, then an Accept-Encoding header containing all supported -encodings will be generated. - -The CURLOPT_ENCODING must be set to any non-NULL value for content to be -automatically decoded. If it is not set and the server still sends encoded +"deflate" or "gzip" Content-Encoding, so the only values for +CURLOPT_ACCEPT_ENCODING 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 is NULL no Accept-Encoding header +is generated. If is a zero-length string, then an Accept-Encoding +header containing all supported encodings will be generated. + +The CURLOPT_ACCEPT_ENCODING must be set to any non-NULL value for content to +be automatically decoded. If it is not set and the server still sends encoded content (despite not having been asked), the data is returned in its raw form and the Content-Encoding type is not checked. -- cgit v1.2.1