Juliusz Chroboczek <[EMAIL PROTECTED]> writes:
> JV> But many servers [don't implement on-the-fly Content-Encoding compression]
>
> And rightly so.
>
> HTTP/1.1 defines two distinct methods for doing compression. There's
> instance-level compression, declared by the Content-Encoding header,
> which is ``end-to-end'' compression: it is a way of declaring that a
> file on the origin server is compressed. For example, an html.gz file
> should be served with Content-Type: text/html, Content-Encoding: gzip.
> There is also entity-level compression, declared by the
> Transfer-Encoding header, which can be correctly used for hop-to-hop
> compression, as done by WWWOFFLE. Unfortunately, entity-level
> compression is not widely deployed yet.
Just to clarify, WWWOFFLE doesn't use the Transfer-Encoding header for
hop-to-hop compression, it works the way everybody else does for
end-to-end compression.
> As entity-level compression is not deployed, Andrew did the courageous
> thing: hacking hop-to-hop support at the instance level. If you look
> at his code, you'll realise how difficult it is to do reliably. A
> better solution, however, than getting sysadmins to use the hack known
> as mod_gzip would be to get the Apache developers to implement proper
> hop-to-hop compression.
There is no reason for Apache to make a change like this if there are
no clients that support it. There is no reason for the browser people
to make a change like this if there is no server that supports it.
The real problem is that using the Content-Encoding header to signal
compression of the requested entity has been implemented by everybody
now. I don't think that the using 'Transfer-Encoding: gzip' will take
over and replace 'Content-Encoding: gzip'.
As an interesting side note; using Transfer-Encoding gzip would force
chunked encoding (or non-persistent connections) to be used for the
data (see HTTP/1.1 specification section 3.6). This means that
Juliusz's solution of "getting sysadmins to implement proper
hop-to-hop compression" would result in not being able to see the
progress of downloads in browsers just like the latest version of
WWWOFFLE.
The use of Content-Encoding rather than Transfer-Encoding for
compression is very similar to the implementation of deflate
compression. So that everybody can interoperate with each other all
implementations of deflate encoding/decoding are different from the
one in the specification. This is why the deflate encoding didn't
work in previous versions of WWWOFFLE (before v2.8) and was disabled.
--
Andrew.
----------------------------------------------------------------------
Andrew M. Bishop [EMAIL PROTECTED]
http://www.gedanken.demon.co.uk/
WWWOFFLE users page:
http://www.gedanken.demon.co.uk/wwwoffle/version-2.8/user.html
