W3C home > Mailing lists > Public > public-bpwg@w3.org > October 2008

RE: Support for compression in XHR?

From: Sullivan, Bryan <BS3131@att.com>
Date: Tue, 7 Oct 2008 11:03:56 -0700
Message-ID: <8080D5B5C113E940BA8A461A91BFFFCD0BAAF57B@BD01MSXMB015.US.Cingular.Net>
To: "Dominique Hazael-Massieux" <dom@w3.org>
Cc: "David Storey" <dstorey@opera.com>, "public-bpwg" <public-bpwg@w3.org>
What web servers do will vary depending upon the design/configuration of the server. The server (or at least its underlying TCP stack) may use TCP segmentation to deliver a HTTP response in 8KB segments (pre-deflate size) as you mention. 

If there is a proxy in the path the proxy may change the HTTP segment size, e.g. to better match the client's network environment. We do see this as a typical behavior of network proxies deployed in mobile networks. The proxy-forwarded HTTP content may also be deflate-compressed if the client support it, and the content is not already compressed.

I do think there is value in providing guidance on the recommended deflate segment size for use with mobile clients. That may be a different value than the Apache default.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Tuesday, October 07, 2008 6:59 AM
To: Sullivan, Bryan
Cc: David Storey; public-bpwg
Subject: RE: Support for compression in XHR?

Le lundi 22 septembre 2008 à 22:32 -0700, Sullivan, Bryan a écrit :
> One more point on this thread. We in most cases do see an advantage in
> compressing HTML and XHTML web pages using GZIP/deflate in our network
> proxies, and since the compression is done on a per HTTP packet basis,
> the browser does not have to wait to get the whole page before
> uncompressing (the browser has to uncompress each packet individually
> anyway, since they are compressed as discrete transfer units).
> Only if the web server compressed the content itself, as a whole
> document, and then sent it over multiple HTTP CONTINUATION packets,
> would the browser need to get the whole page before uncompressing.
> But that is not normal behavior of web servers that we see in our
> network.

I'm still unclear whether you're saying that most Web servers (e.g.
Apache) send compressed pages by small enough packets that they won't
prevent progressive rendering, or if that's "only" a feature of the
specific network proxy set up on your network.

Looking at Apache (as an example), it seems the default size of the
fragment compressed by mod_deflate is 8KB:

which is probably sensible to enable progressive rendering, but probably
doesn't take into account the MTU of a packet on a mobile network.

I wonder again if this specific value is not something we could give
advice on; but then, I guess we can only do so if we have some way to
make measures and estimations on this whole question...


Received on Tuesday, 7 October 2008 18:04:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:42:59 UTC