Compression - is transfer encoding possible with content encoding

Author

is transfer encoding possible with content encoding

p.raghavulu@gmail.com

2005-11-11, 9:55 pm

Hello,

I'm using the transfer-encoding HTTP hearder with the combination of
content-encoding header. that means i'm actually sending the response
chunk by chunk to the client and each chunk is in gzip format(i zipped
each chunk using the zlib library). now my question is when i send all
the chunks to the browser with proper headers, the browser is able to
decode and showing the data of first chunk only but not able to combile

all the chunks? does anyone know why is it like that? any clue will be
of a great help...

the header i sent for the first chunk is as follows and rest of all the

chunks are just compressed and sent to the network transfer without
http header.

HTTP/1.1 200 OK
Set-Cookie: POSESSIONIDF865433E=4d5946b6afac8f1005fb
f9abe8b66cfd;
path=/
Last-Modified: Thu, 10 Nov 2005 15:51:26 GMT
ETag: {d9a5d620-5201-11da-9709-f2432e79815f}
Expires: Thu, 17 Nov 2005 16:42:13 GMT
Server: ISIS-Papyrus/pocw3ppl/Nov 10 2005
Date: Thu, 10 Nov 2005 16:42:13 GMT
Content-type: application/pdf
Transfer-Encoding: chunked
Content-Encoding: gzip

Thanks in advance
Raghavulu

Nir Halowani

2005-11-12, 7:55 am

Hi,

The problem is that while passing the stream data to a ZLIB (/gzip)
decompression routine for example without first removing the chunking
bytes then ZLIB is going to blow sky-high. This is the reason most
browsers are screwing up. They are actually passing the response stream
off to an embedded mime-handler ( like an Adobe plug-in for PDF files
or some ill-coded Javascript engine, etc. ) that has no idea how to
remove the chunking bytes AND get it decompressed. The only way for all
of this to currently work 'out there' is to never rely on the
Accpet-Encoding:" field at all and always have a 'list' of exclusion
mime-types that can be tied to 'User-Agent' since they are all
different as far as what they are able to do. In your case just first
dechunk and then decompress the data (Before sending it to acrobat).

Your can also look at this link, which specifies what browsers can
handle Content-Encoding: gzip:
http://www.schroepl.net/projekte/mod_gzip/browser.htm

And also at this link which suggests a hotfix for IE problems:

http://support.microsoft.com/kb/871205

- Nir

p.raghavulu@gmail.com

2005-11-14, 6:55 pm

Hello Nir,

I tried what you have suggested now with a simple text file which is of
size 1 MB. so now there shouldnt be no plugin involved and the browser
is able to decode and aggregate all the chunks which it gets... but
unfortunately its still not and i just see the data of the first chunk
which has the length of my chunk size (32kb).

on the other note, when i disable the content-encoding: gzip and send
the data as normal across the browser with transfer-encoding: chunked,
i can see the whole data (1 MB) at the client side. however it just
simply shows first chunk only, when i enable both content-encoding and
transfer-encoding while sending the response.

Also i'm sure my browser supports content-encoding and using HTTP
protocol now

Awaiting for your reply!

Thanks
-Raghavulu

p.raghavulu@gmail.com

2005-11-25, 6:55 pm

its solved. found out the calculation of crc was wrong. thanks for your
inputs.

ciao
-Raghavulu

Sponsored Links