Re: the eCAP gzip module

Hi,

I am currently testing a new version of the gzip module based on the
hints of Alex Rousskov from January, 8th:

1. Adding a Warning header if transformation is applied.

2. Adding support for "deflate" encoding as well.

3. Check if response already contains a "Content-Encoding" header and
leave it untouched in this case.

4. Check the HTTP status code.
Although we could gzip any response body, it should be restricted to
2xx HTTP status codes. Alex asked how to deal with 206 Partial
Content. Well, I think setting the Vary header to "Accept-Encoding,
Range" would be the right way in this case. Opinions?

5. Dealing with other headers (Vary, ETag, If-*)
(a) Generally, if the gzip module is active, we have to send "Vary:
Accept-Encoding" even if we do not transform the response. The module
has decided to send a variant (identity or gzip) based on accept-
encoding, so we have to add this.
(b) Concerning the ETag and If-* headers, I am open to your comments.
How should we deal with them? Simply adding a "GZ" suffix to the ETag,
if available?

I am planning to release the next version of the gzip module this
weekend, implementing 1-4 and 5a.
Regarding ETag and If-* header handling, I would like to discuss this
before start coding.

On 28.01.2009 at 17:06 Henrik Nordstrom wrote:

> Hi,
>
> how does the gzip module handle the ETag and it's reladed
> If-None-Match/If-Match/If-Range headers?
>
> Regards
> Henrik

Best Regards,
Constantin
Received on Thu Jan 29 2009 - 22:27:21 MST