Hi Oleg, I had a look at the GZIP content compression code. It's a good example for using the request and response interceptors, and for implementing content decompression.
In the *very* long run (not before we're running out of ideas what else is missing), we should reconsider wether to offer content decompression as part of the main package. I know that content handling is out of scope, but decompression is merely dealing with content representation. We do evaluate the charset attribute in the Content-Type occasionally, so we are already in the content representation business. Since we're not going to have the resources for implementing this anyway, I don't want to start a discussion now. I just wanted to have it mentioned once :-) >From the design point of view, I was surprised to see two different entities for compression and decompression. We had a long discussion about distinguishing incoming from outgoing entities and opted for a symmetrical interface in the end. Now, the distinction is creeping back in on the implementation level? ResponseGzipCompress should have a short comment that it does not attempt to cover the full complexity of the spec: qvalues (gzip;q=0), wildcards or multiple Accept-Encoding headers. Anyway, it is a good example as it is. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
