Return-Path: Delivered-To: apmail-httpd-users-archive@www.apache.org Received: (qmail 74440 invoked from network); 13 Sep 2008 14:02:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 13 Sep 2008 14:02:58 -0000 Received: (qmail 31104 invoked by uid 500); 13 Sep 2008 14:02:44 -0000 Delivered-To: apmail-httpd-users-archive@httpd.apache.org Received: (qmail 31092 invoked by uid 500); 13 Sep 2008 14:02:44 -0000 Mailing-List: contact users-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: users@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@httpd.apache.org Received: (qmail 31081 invoked by uid 99); 13 Sep 2008 14:02:43 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Sep 2008 07:02:43 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [74.54.22.178] (HELO association.mompopmedia.net) (74.54.22.178) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 13 Sep 2008 14:01:43 +0000 Received: from blk-215-86-98.eastlink.ca ([24.215.86.98] helo=home.lan) by association.mompopmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1KeVhU-0000xf-7o for users@httpd.apache.org; Sat, 13 Sep 2008 10:02:12 -0400 Message-ID: <48CBC7E3.5030204@eggplant.ws> Date: Sat, 13 Sep 2008 11:02:11 -0300 From: Michael Caplan User-Agent: Thunderbird 2.0.0.16 (X11/20080725) MIME-Version: 1.0 To: users@httpd.apache.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - association.mompopmedia.net X-AntiAbuse: Original Domain - httpd.apache.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - eggplant.ws X-Source: X-Source-Args: X-Source-Dir: X-Virus-Checked: Checked by ClamAV on apache.org Subject: [users@httpd] Chunked + Gzip Hi, I have a question about how Transfer-Encoding: chunked works with a Content-Encoding gzip. Reading the HTTP 1.1 RFC, http://en.wikipedia.org/wiki/Chunked_transfer_encoding 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 chunked. 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 (http://schroepl.net/projekte/mod_gzip/config.htm) 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: Hi

Hi

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:1.8.1.16) Gecko/20080703 Mandriva/2.0.0.16-1.1mdv2008.1 (2008.1) Firefox/2.0.0.16 FirePHP/0.1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 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 6c ..........D.. .0..{..<.Y I...<..A....AI$.../.g.5...g..a.&...x...T...h.b..d...../.\ .='..ns..X$.N.L.;]....... 32 ....S*...r..Sl.@dj.........`..).n..;......F.L=.... 0 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 subject? Thanks, Mike --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See for more info. To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org " from the digest: users-digest-unsubscribe@httpd.apache.org For additional commands, e-mail: users-help@httpd.apache.org