httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Caplan <>
Subject [users@httpd] Chunked + Gzip
Date Sat, 13 Sep 2008 14:02:11 GMT

I have a question about how Transfer-Encoding: chunked works with a 
Content-Encoding gzip.  Reading the HTTP 1.1 RFC, and other 
discussions on the net that touch on this subject I'm a little confused 
on how the web server and browser client handles preparing and reading 
the data.

The RFC isn't clear on this point (or at least I'm not finding the right 
information), but what I have gathered is that:

 1. the gzip content encoding happens on the entire body before it is 
 2. the ungzipping happens on the entire body after it is dechunked.

If I got this right (which I don't think I do), the web server would 
need to first dechunk data produced from a dynamic source (PHP) before 
it can apply the gzip content encoding.  For example, mod_gzip would not 
apply the content encoding until it dechunked the data 
( and then delivered it 
to the client.

Likewise, on the client end, it would only be able to begin interpreting 
HTML following receiving the entire chucked payload, dechunk it, and 
then ungzip it.

But, that seems contrary to what Apache + mod_deflate actually does, as 
well as my browser (Firefox).  For example, I can create a PHP script 
that controls the chunks created by calling the flush() function:

        <link rel="stylesheet" href="style.css" type="text/css" 
media="all" />
<?php flush(); sleep(5); ?>
    <body onload="loaded();">

The complete client server communication looks like this:

GET /samples/flush/test.php HTTP/1.1
Host: ***
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: 
Gecko/20080703 Mandriva/ (2008.1) Firefox/ 

Accept-Language: en-ca,en;q=0.7,en-us;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sat, 13 Sep 2008 13:03:26 GMT
Server: Apache
Vary: User-Agent,Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/html
..........D.. .0..{..<.Y 

If I have Apache + mod_deflate configured to gzip up the output, the 
chunks created reflect where I flush in the PHP script -- in this case 
two chunks -- one for the header, and another for the body.  If I put in 
an artificial time delay that will delay the delivery of the second 
chunk (as I did above with sleep(5)), I can also see two other 
interesting things. 

 1. The first gzip compressed chunk is delivered independently of the 
second chunk (that comes 5 seconds later).  Which indicates the gzipping 
is happening chunk by chunk, not on the entire body at once.
 2. Second, the browser receives the first gzip chunk and is able to 
interpret it _before_ it gets the entire payload and dechunks it all.  I 
say this because while the browser is waiting on the second chunk, it 
will download the referenced CSS file.

This seems to fly in he face of what I've read on how it is supposed to 
work.  Instead, it appears to be working like this:

 1. the gzip content encoding happens on the entire body, chunk by chunk.
 2. the ungzipping happens on the entire body, chunk by chunk.

Is this behavior noted mean I am mis interpreting the HTTP RFC, or is 
the implementation not compliant?  Can anyone shine some light on the 



The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message