Hi,
Martin Stjernholm wrote:
Just recently, Marty (cc'd) made an experimental patch to get
compression directly in the http protocol. One reason to do that was
to make it happen after the protocol module has fixed the charset
encoding. Another is that it can be tied in with the protocol cache
(it might not be wise to spend cpu on compressing dynamic answers).
That's right, since the charset recoding isn't done until the request
data is considered complete (i.e. after all filter modules have been
called), the charset recoding routines might corrupt the compressed
data. I, as well as the other gzip filter module authors, tried to
circumvent the problem by not compressing wide string data -- the
problem, however, is that even narrow string data might get recoded and
then the compressed data might still end up corrupted (I experienced
that myself.) Even if you detect that the request is going to be recoded
you would lose compression on such requests.
Maybe you can compare solutions?
Sure, but my patch will need a little bit more attention first. It seems
I'm a bit busy this week but I expect to have it done by the weekend.
(I also noticed that Microsoft misinterpreted RFC 2616 paragraph 3.5. It
clearly states that the "deflate" transfer encoding is a combination of
a zlib header (RFC 1950) and the deflate compression mechanism, while
MSIE expects a raw deflate stream. Since MSIE seems to announce both
"deflate" and "gzip" in the Accept-Encoding header, I guess a pragmatic
solution could be to use gzip as the default if both are accepted. That
way the "deflate" mechanism could still be supported and
standards-compliant. (To be honest, I don't know if there is any browser
that supports deflate but not gzip so I don't know if "deflate" would
ever be used in reality.)
Regards,
Martin
--
Martin Jonsson E-mail: <[email protected]>
Developer Cell: +46-709-153931
Roxen Internet Software AB
