RE: Support for compression in XHR?

Dom,
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:
http://httpd.apache.org/docs/2.0/mod/mod_deflate.html#DeflateBufferSize

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...

Dom

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