Discussion:
Problem with CONTENT-ENCODING
Dobromir Velev
2005-12-02 13:41:48 UTC
Permalink
Hi,
I'm writing a simple script for a client of mine using the libcurl library.
There seems to be a problem with the CURLOPT_ENCODING option when the
content is compressed with zlib (Content-Encoding: deflate) curl will return
"Error while processing content unencoding: incorrect header check".

Any help will be appreciated.


I'm using libcurl with the following setup
#curl -V
curl 7.15.0 (i686-pc-linux-gnu) libcurl/7.15.0 OpenSSL/0.9.7a zlib/1.2.3
Protocols: tftp ftp gopher telnet dict ldap http file https ftps
Features: Largefile NTLM SSL libz

Here is a sample session from curl, and if you need additional info please
let me know.

* About to connect() to www.brazilianfightwear.com port 80
* Trying 65.36.133.119... connected
* Connected to www.brazilianfightwear.com (65.36.133.119) port 80
GET / HTTP/1.1
Host: www.brazilianfightwear.com
Accept: */*
Accept-Encoding: deflate, gzip
< HTTP/1.1 302 Object moved
< Date: Fri, 02 Dec 2005 13:01:00 GMT
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Location:
http://www.brazilianfightwear.com/store/stores_app/store.asp?Store_Id=117&page_id=5
< Content-Length: 208
< Content-Type: text/html
< Set-Cookie: ASPSESSIONIDCSQRSBTS=HADNNGAAKKGJEAJANGMJFJEM; path=/
< Cache-control: private
* Ignoring the response-body
* Connection #0 to host www.brazilianfightwear.com left intact
* Issue another request to this URL: '
http://www.brazilianfightwear.com/store/stores_app/store.asp?Store_Id=117&page_id=5
'
* Re-using existing connection! (#0) with host www.brazilianfightwear.com
* Connected to www.brazilianfightwear.com (65.36.133.119) port 80
GET /store/stores_app/store.asp?Store_Id=117&page_id=5 HTTP/1.1
Host: www.brazilianfightwear.com
Accept: */*
Accept-Encoding: deflate, gzip
< HTTP/1.1 200 OK
< Cache-Control: private
< Date: Fri, 02 Dec 2005 13:01:01 GMT
< Content-Type: text/html
< Server: Microsoft-IIS/6.0
< X-Powered-By: ASP.NET
< Set-Cookie: ASPSESSIONIDCSQRSBTS=IADNNGAAGLAGNIGPPJEPAAKN; path=/
< Content-Encoding: deflate
< Vary: Accept-Encoding
< Transfer-Encoding: chunked
Error while processing content unencoding: incorrect header check
* Failed writing data
* Closing connection #0
curl: (23) Error while processing content unencoding: incorrect header check


--
Dobromir Velev
---------------------------------------------------------------------------
"Never attribute to malice that which can be
adequately explained by stupidity"
Daniel Stenberg
2005-12-02 13:59:00 UTC
Permalink
Post by Dobromir Velev
I'm writing a simple script for a client of mine using the libcurl library.
There seems to be a problem with the CURLOPT_ENCODING option when the
content is compressed with zlib (Content-Encoding: deflate) curl will return
"Error while processing content unencoding: incorrect header check".
Well, zlib returns an error when trying to deflate the stream. The "incorrect
header check" is actually the error message zlib provides.
--
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Dobromir Velev
2005-12-02 15:23:22 UTC
Permalink
Hi,
I guessed so, but I have the most recent zlib version, and the decoding
worked fine when I tried it with a Firefox browser. Also I can make it work
by changing the order in the "Accept-Encoding:" header to "gzip,deflate"
instead of the default 'deflate,gzip' or setting CURLOPT_ENCODING to 'gzip'.
I was just wondering if it could be something else I'm missing here.

Anyway thanks for the response. I'll continue digging and will let you know
if something comes up.

Dobromir Velev
Post by Dobromir Velev
Post by Dobromir Velev
I'm writing a simple script for a client of mine using the libcurl
library.
Post by Dobromir Velev
There seems to be a problem with the CURLOPT_ENCODING option when the
content is compressed with zlib (Content-Encoding: deflate) curl will
return
Post by Dobromir Velev
"Error while processing content unencoding: incorrect header check".
Well, zlib returns an error when trying to deflate the stream. The "incorrect
header check" is actually the error message zlib provides.
--
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
--
Dobromir Velev
---------------------------------------------------------------------------
"Never attribute to malice that which can be
adequately explained by stupidity"
Dan Fandrich
2005-12-02 17:59:39 UTC
Permalink
Hi,
I guessed so, but I have the most recent zlib version, and the decoding worked
fine when I tried it with a Firefox browser. Also I can make it work by
changing the order in the "Accept-Encoding:" header to "gzip,deflate" instead
of the default 'deflate,gzip' or setting CURLOPT_ENCODING to 'gzip'.
In that case, the server is probably sending you gzip encoded data instead
of deflate.
I was just wondering if it could be something else I'm missing here.
Anyway thanks for the response. I'll continue digging and will let you know if
something comes up.
The probably is likely that your server is sending you bad deflated data; it
seems like quite a few servers do. It's such a problem that some browsers
even detect the invalid data and work around it, which is evidently what
Firefox does. See this thread for a similar discussion:
http://curl.haxx.se/mail/lib-2003-08/0204.html
Dan
--
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved
Dobromir Velev
2005-12-05 14:49:25 UTC
Permalink
Thanks for the response.

Any idea where I can find more information about the data header expected by
zlib. It seems that IIS is sending incorrect deflated data - probably some
header is missing and the browsers don't check the header or have some other
way to deal with such cases. May be I'll be able to write some workaround.

Dobromir Velev
Post by Dan Fandrich
Post by Dobromir Velev
Hi,
I guessed so, but I have the most recent zlib version, and the decoding
worked fine when I tried it with a Firefox browser. Also I can make it
work by changing the order in the "Accept-Encoding:" header to
"gzip,deflate" instead of the default 'deflate,gzip' or setting
CURLOPT_ENCODING to 'gzip'.
In that case, the server is probably sending you gzip encoded data instead
of deflate.
Post by Dobromir Velev
I was just wondering if it could be something else I'm missing here.
Anyway thanks for the response. I'll continue digging and will let you
know if something comes up.
The probably is likely that your server is sending you bad deflated data;
it seems like quite a few servers do. It's such a problem that some
browsers even detect the invalid data and work around it, which is
http://curl.haxx.se/mail/lib-2003-08/0204.html
Post by Dobromir Velev
Dan
Daniel Stenberg
2005-12-05 15:00:40 UTC
Permalink
Post by Dobromir Velev
Any idea where I can find more information about the data header expected by
zlib. It seems that IIS is sending incorrect deflated data - probably some
header is missing and the browsers don't check the header or have some other
way to deal with such cases. May be I'll be able to write some workaround.
I assume all details are in RFC1951 "DEFLATE Compressed Data Format
Specification". Available all over, but here's the one on the curl site:

http://curl.haxx.se/rfc/rfc1951.txt

I recall someone once making a patch that would make libcurl try with and
without a header or something, but I couldn't find it now and I know it was
never applied because it was done against an older incarnation of libcurl's
deflate code... (perhaps it had nothing to do with this and I'm just
rambling!)
--
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Dobromir Velev
2005-12-12 18:50:01 UTC
Permalink
Here is a small patch that fixes the problem with the missing deflate header
in the IIS response. It checks the first byte of the content and if it
doesn't look like a header it tells zlib inflate() to process the raw deflate
data without looking for headers.

--- content_encoding.c 2005-03-31 10:02:03.000000000 +0300
+++ content_encoding.new.c 2005-12-12 20:29:23.389573722 +0200
@@ -149,14 +149,21 @@
z_stream *z = &k->z; /* zlib state structure */

/* Initialize zlib? */
- if (k->zlib_init == ZLIB_UNINIT) {
+ if (k->zlib_init == ZLIB_UNINIT && nread) {
z->zalloc = (alloc_func)Z_NULL;
z->zfree = (free_func)Z_NULL;
z->opaque = 0;
z->next_in = NULL;
z->avail_in = 0;
- if (inflateInit(z) != Z_OK)
- return process_zlib_error(data, z);
+ if((k->str[0] & 0xf) != Z_DEFLATED){
+ if(inflateInit2(z,-MAX_WBITS) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+ else{
+ if(inflateInit(z) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+
k->zlib_init = ZLIB_INIT;
}

While testing it I encountered one more problem with broken server encoding.
Some server when asked explicitly for deflate encoding will respond with
"Content-encoding: deflate" header but will GZIP encode the data so the
decoding will fail.

This is definitely not a curl issue but I just wanted to let you know about
it.


Regards
Dobromir Velev
Post by Daniel Stenberg
Post by Dobromir Velev
Any idea where I can find more information about the data header expected
by zlib. It seems that IIS is sending incorrect deflated data - probably
some header is missing and the browsers don't check the header or have
some other way to deal with such cases. May be I'll be able to write some
workaround.
I assume all details are in RFC1951 "DEFLATE Compressed Data Format
http://curl.haxx.se/rfc/rfc1951.txt
I recall someone once making a patch that would make libcurl try with and
without a header or something, but I couldn't find it now and I know it was
never applied because it was done against an older incarnation of libcurl's
deflate code... (perhaps it had nothing to do with this and I'm just
rambling!)
Dan Fandrich
2005-12-12 19:51:30 UTC
Permalink
Post by Dobromir Velev
Here is a small patch that fixes the problem with the missing deflate header
in the IIS response. It checks the first byte of the content and if it
doesn't look like a header it tells zlib inflate() to process the raw deflate
data without looking for headers.
--- content_encoding.c 2005-03-31 10:02:03.000000000 +0300
+++ content_encoding.new.c 2005-12-12 20:29:23.389573722 +0200
@@ -149,14 +149,21 @@
z_stream *z = &k->z; /* zlib state structure */
/* Initialize zlib? */
- if (k->zlib_init == ZLIB_UNINIT) {
+ if (k->zlib_init == ZLIB_UNINIT && nread) {
z->zalloc = (alloc_func)Z_NULL;
z->zfree = (free_func)Z_NULL;
z->opaque = 0;
z->next_in = NULL;
z->avail_in = 0;
- if (inflateInit(z) != Z_OK)
- return process_zlib_error(data, z);
+ if((k->str[0] & 0xf) != Z_DEFLATED){
+ if(inflateInit2(z,-MAX_WBITS) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+ else{
+ if(inflateInit(z) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+
k->zlib_init = ZLIB_INIT;
}
This patch will probably cause a crash if Curl_unencode_deflate_write
is ever called with nread==0. I'm not sure if that will ever happen,
but I suppose it could if the TCP segment ends right after the HTTP
headers and before the first byte of data. In any case, this makes the
code more brittle. Also, the if((k->str[0] & 0xf) != Z_DEFLATED) hack
should be well commented so the next maintainer understands the reason
for the brokenness.
Post by Dobromir Velev
While testing it I encountered one more problem with broken server encoding.
Some server when asked explicitly for deflate encoding will respond with
"Content-encoding: deflate" header but will GZIP encode the data so the
decoding will fail.
This is definitely not a curl issue but I just wanted to let you know about
it.
I wasn't aware of this issue. Do you know which server does this? Have
you reported it to the maintainer?
Post by Dobromir Velev
Dan
--
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved
Dobromir Velev
2005-12-13 09:25:40 UTC
Permalink
Hi,
Post by Dan Fandrich
Post by Dobromir Velev
Here is a small patch that fixes the problem with the missing deflate
header in the IIS response. It checks the first byte of the content and
if it doesn't look like a header it tells zlib inflate() to process the
raw deflate data without looking for headers.
--- content_encoding.c 2005-03-31 10:02:03.000000000 +0300
+++ content_encoding.new.c 2005-12-12 20:29:23.389573722 +0200
@@ -149,14 +149,21 @@
z_stream *z = &k->z; /* zlib state structure */
/* Initialize zlib? */
- if (k->zlib_init == ZLIB_UNINIT) {
+ if (k->zlib_init == ZLIB_UNINIT && nread) {
z->zalloc = (alloc_func)Z_NULL;
z->zfree = (free_func)Z_NULL;
z->opaque = 0;
z->next_in = NULL;
z->avail_in = 0;
- if (inflateInit(z) != Z_OK)
- return process_zlib_error(data, z);
+ if((k->str[0] & 0xf) != Z_DEFLATED){
+ if(inflateInit2(z,-MAX_WBITS) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+ else{
+ if(inflateInit(z) != Z_OK)
+ return process_zlib_error(data, z);
+ }
+
k->zlib_init = ZLIB_INIT;
}
This patch will probably cause a crash if Curl_unencode_deflate_write
is ever called with nread==0. I'm not sure if that will ever happen,
but I suppose it could if the TCP segment ends right after the HTTP
headers and before the first byte of data. In any case, this makes the
code more brittle. Also, the if((k->str[0] & 0xf) != Z_DEFLATED) hack
should be well commented so the next maintainer understands the reason
for the brokenness.
That's why added nread in the if clause on line 152. The only possible problem
here is that z will not be inited before any bytes were received but I
thought that was OK. I will send another patch with more comments if needed
- I just saw that zlib is using a similar test in inflate.c to check the
headers and that was were the IIS deflate encoding was failing.
Post by Dan Fandrich
Post by Dobromir Velev
While testing it I encountered one more problem with broken server
encoding. Some server when asked explicitly for deflate encoding will
respond with "Content-encoding: deflate" header but will GZIP encode the
data so the decoding will fail.
This is definitely not a curl issue but I just wanted to let you know
about it.
I wasn't aware of this issue. Do you know which server does this? Have
you reported it to the maintainer?
The problem is that I don't have a lot of different setups to test with so I
tried with several servers on the Internet. Most of the failing servers
ignore the order in the Accept-Encoding header and when a
"Accept-Encoding: deflate, gzip" request is sent they will ignore deflate and
use gzip instead. The problem appears only when a "Accept-Encoding: deflate"
requeste header is sent. Here are two sample sessions that fail
Post by Dan Fandrich
GET / HTTP/1.1
User-Agent: curl/7.15.1 (i686-pc-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.7a
zlib/1.2.1.2 libidn/0.5.6
Post by Dan Fandrich
Host: www.port80software.com
Accept: */*
Accept-Encoding: deflate
< HTTP/1.1 200 OK
< Date: Mon, 12 Dec 2005 14:43:51 GMT
< Server: Yes we are using ServerMask!
< Set-Cookie: countrycode=BG; path=/
< Set-Cookie: ALT.COOKIE.NAME.2=8MQ21,..S801T.0.QFN4M04M0O,.6M050; path=/
< Cache-control: private
< Content-Length: 6206
< Content-Type: text/html
< Content-Encoding: deflate
< Vary: Accept-Encoding
Error while processing content unencoding: invalid block type
Post by Dan Fandrich
GET / HTTP/1.1
User-Agent: curl/7.15.1 (i686-pc-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.7a
zlib/1.2.1.2 libidn/0.5.6
Post by Dan Fandrich
Host: www.the-gdf.org
Accept: */*
Accept-Encoding: deflate
< HTTP/1.1 302 Found
< Date: Tue, 13 Dec 2005 08:46:55 GMT
< Server: Apache/2.0.40 (Red Hat Linux)
< Location: http://www.the-gdf.org/wiki/index.php?title=Main_Page
< Content-Length: 311
< Content-Type: text/html; charset=iso-8859-1
* Ignoring the response-body
* Connection #0 to host www.the-gdf.org left intact
* Issue another request to this URL:
'http://www.the-gdf.org/wiki/index.php?title=Main_Page'
* Re-using existing connection! (#0) with host www.the-gdf.org
* Connected to www.the-gdf.org (209.208.199.67) port 80
Post by Dan Fandrich
GET /wiki/index.php?title=Main_Page HTTP/1.1
User-Agent: curl/7.15.1 (i686-pc-linux-gnu) libcurl/7.15.1 OpenSSL/0.9.7a
zlib/1.2.1.2 libidn/0.5.6
Post by Dan Fandrich
Host: www.the-gdf.org
Accept: */*
Accept-Encoding: deflate
< HTTP/1.1 200 OK
< Date: Tue, 13 Dec 2005 08:46:55 GMT
< Server: Apache/2.0.40 (Red Hat Linux)
< Accept-Ranges: bytes
< X-Powered-By: PHP/4.2.2
< Content-language: en
< Vary: Accept-Encoding
< Expires: -1
< Cache-Control: private, must-revalidate, max-age=0
< Content-Encoding: deflate
< Content-Length: 3758
< Content-Type: text/html; charset=utf-8
Error while processing content unencoding: invalid block type
Post by Dan Fandrich
Post by Dobromir Velev
Dan
Daniel Stenberg
2005-12-13 09:38:37 UTC
Permalink
Post by Dobromir Velev
That's why added nread in the if clause on line 152. The only possible
problem here is that z will not be inited before any bytes were received but
I thought that was OK. I will send another patch with more comments if
needed
Please do. That code needs some comments to allow others (like me) to properly
understand what it does and why!

Thanks for your efforts!
--
Commercial curl and libcurl Technical Support: http://haxx.se/curl.html
Dan Fandrich
2005-12-13 18:28:09 UTC
Permalink
Post by Dobromir Velev
That's why added nread in the if clause on line 152. The only possible problem
here is that z will not be inited before any bytes were received but I
thought that was OK. I will send another patch with more comments if needed
That's not the only problem--if nread==0 then the code skips over the
zlib init call and dives right into inflate_stream() and then inflate(),
passing in an uninitialized z_stream pointer!
Post by Dobromir Velev
- I just saw that zlib is using a similar test in inflate.c to check the
headers and that was were the IIS deflate encoding was failing.
The problem is that I don't have a lot of different setups to test with so I
tried with several servers on the Internet. Most of the failing servers
ignore the order in the Accept-Encoding header and when a
"Accept-Encoding: deflate, gzip" request is sent they will ignore deflate and
use gzip instead. The problem appears only when a "Accept-Encoding: deflate"
requeste header is sent. Here are two sample sessions that fail
I was hoping the Server: line would provide the answer; the first one isn't
much help, but the second is showing Apache 2.0.40. That's one server I
would expect to get it right, especially since Apache 1.3 did :-)
Post by Dobromir Velev
Dan
--
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved
Michael Wallner
2005-12-14 12:26:53 UTC
Permalink
Hi all,

Sorry for jumping in that late, but I actually had to cope with that
issue the last few days too (but not within curl directly, though).

To me there seem to be two issues, the first being a deflate content-
encoding header with gzipped body (I'll leave that out now, cause I've
not seen that so far), and the second one being deflated/compressed
bodies with and without zlib header bytes.

Yeah, some research revealed that compress/deflate is actually the same
and the difference can, but need not to, be how deflateInit2() was called,
i.e. with MAX_WBITS which will give you the zlib bytes at the beginning
of the encoded data or -MAX_WBITS which will make deflate() leave them
out.

As curl only needs inflating I'll only talk about that and how I solved
that issue. So deflated/compressed data may come to you with and without
that zlib header bytes and cheking the first byte to be Z_DEFLATED looks
rather unreliable to me, so I'd suggest the following:

- inline the everything (except the gzip checks) into one function
- make the z_stream only live within that function
- try to inflate the stream first with inflateInit2(&z, -MAX_WBITS ...)
- if zlib returns Z_DATA_ERROR try with inflateInit2(&z, MAX_WBITS ...)

This should work fine with the inner part of gzip data as well as deflated
or compressed data and also make things easier in content_encoding.c.

You can look at http_encoding_inflate() here, but note that it tries to
decode the data as a whole, and not like curl as several chunks:
http://cvs.php.net/viewcvs.cgi/pecl/http/http_encoding_api.c?view=markup

Regards,
--
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
Michael Wallner
2005-12-14 14:33:29 UTC
Permalink
Post by Michael Wallner
To me there seem to be two issues, the first being a deflate content-
encoding header with gzipped body (I'll leave that out now, cause I've
not seen that so far), and the second one being deflated/compressed
bodies with and without zlib header bytes.
Ok, sorry -- I just read your post where you describe that former issue,
but the data returned doesn't seem to be valid gzip data either.

BTW, shouldn't curl send "gzip,deflate" instead of "deflate,gzip"?

Regards,
--
Michael - <mike(@)php.net> http://dev.iworks.at/ext-http/http-functions.html.gz
Dan Fandrich
2005-12-15 18:23:13 UTC
Permalink
Post by Michael Wallner
BTW, shouldn't curl send "gzip,deflate" instead of "deflate,gzip"?
The order doesn't matter. It might be an idea to send something like
"gzip,deflate;q=0.5" to indicate that we prefer gzip (to avoid the
interoperability problems of deflate), except that qvalues are not supported
by HTTP/1.0 servers and could cause the request to fail.
Post by Michael Wallner
Dan
Jamie Lokier
2005-12-15 18:36:18 UTC
Permalink
Post by Dan Fandrich
Post by Michael Wallner
BTW, shouldn't curl send "gzip,deflate" instead of "deflate,gzip"?
The order doesn't matter. It might be an idea to send something like
"gzip,deflate;q=0.5" to indicate that we prefer gzip (to avoid the
interoperability problems of deflate), except that qvalues are not supported
by HTTP/1.0 servers and could cause the request to fail.
RFC2616 recognises the problem of HTTP/1.0 servers, but does not
recommend against using them at all. It says:

Note: Most HTTP/1.0 applications do not recognize or obey qvalues
associated with content-codings. This means that qvalues will not
work and are not permitted with x-gzip or x-compress.

I.e. it recommends not using qvalues with x-gzip and x-compress.

A server that doesn't support qvalues seems unlikely to fail the
request - I would expect it to either ignore the qvalue, or treat it
as an encoding "deflate;q=0.5" which it doesn't recognise. Neither of
those would cause the request to fail.

Do you know of any servers which actually cause such a request to fail?

-- Jamie
Dan Fandrich
2005-12-15 18:52:56 UTC
Permalink
Post by Jamie Lokier
A server that doesn't support qvalues seems unlikely to fail the
request - I would expect it to either ignore the qvalue, or treat it
as an encoding "deflate;q=0.5" which it doesn't recognise. Neither of
those would cause the request to fail.
The latter would cause the request to fail if the server only supports
deflate.
Post by Jamie Lokier
Do you know of any servers which actually cause such a request to fail?
I'm not aware of any that would fail the request in a manner other than
mentioned above. In reality, it seems that servers themselves seem to
prefer gzip over deflate so adding a q= parameter isn't likely to make
much difference in practise.
Post by Jamie Lokier
Dan
--
http://www.MoveAnnouncer.com The web change of address service
Let webmasters know that your web site has moved
Jamie Lokier
2005-12-15 20:09:07 UTC
Permalink
Post by Dan Fandrich
Post by Jamie Lokier
A server that doesn't support qvalues seems unlikely to fail the
request - I would expect it to either ignore the qvalue, or treat it
as an encoding "deflate;q=0.5" which it doesn't recognise. Neither of
those would cause the request to fail.
The latter would cause the request to fail if the server only supports
deflate.
Oh? Wouldn't the server simply not compress the data?
Post by Dan Fandrich
Post by Jamie Lokier
Do you know of any servers which actually cause such a request to fail?
I'm not aware of any that would fail the request in a manner other than
mentioned above. In reality, it seems that servers themselves seem to
prefer gzip over deflate so adding a q= parameter isn't likely to make
much difference in practise.
I vaguely recall that some servers will send gzip data even with
"Accept-Encoding: deflate", and they might label it as
"Content-Encoding: deflate" despite the gzip data.

-- Jamie
Dan Fandrich
2005-12-15 20:22:38 UTC
Permalink
Post by Jamie Lokier
Oh? Wouldn't the server simply not compress the data?
Presumably. I meant "fail" as in it would fail to compress the data, which
I suppose is a pretty benign failure mode in most cases.
Post by Jamie Lokier
I vaguely recall that some servers will send gzip data even with
"Accept-Encoding: deflate", and they might label it as
"Content-Encoding: deflate" despite the gzip data.
That's what was reported here recently, but such servers are so severely
broken I doubt it's worth supporting them. But then, sending deflate data
without the header is just about as broken.
Post by Jamie Lokier
Dan
Continue reading on narkive:
Search results for 'Problem with CONTENT-ENCODING' (Questions and Answers)
3
replies
Internet problems: "Content Encoding Error" "file is corrupt" and more?
started 2009-09-22 07:59:09 UTC
computers & internet
4
replies
i have a loading problem with Google chrome..?
started 2011-06-18 03:32:58 UTC
google
5
replies
firefox browsing problem?
started 2009-02-13 06:07:58 UTC
internet
8
replies
How to solve "Content Encoding Error" on firefox?
started 2010-08-04 01:06:34 UTC
internet
3
replies
How can I stop content encoding errors on Firefox?
started 2011-01-10 18:13:51 UTC
internet
Loading...