Martin Jonsson wrote:
>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
That explains the problems I still see here and there.
>>Maybe you can compare solutions?
>Sure, but my patch will need a little bit more attention first. It seems
Well, if you'd care to mail it to me, I can finish it for you earlier
perhaps. It's ok if it's buggy as is. Unless you think you can do an
overall better job than I can.
>(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.
Possible, yes. Then again, probably needlessly more complex.
At the decoding end, decoding the various formats (MS-deflate,
standards-deflate and gzip) merely involves jumping to the right
offset in the stream (skipping a few header bytes) and then starting
the decompressor (it's the same decompressor for all three formats).
It is therefore rather unlikely that a browser will support deflate but
not gzip (it doesn't cost a lot at the decoding end to support both).
--
Sincerely,
Stephen R. van den Berg.
Real programmers don't produce results, they return exit codes.
|