Version 1.7 2009-05-11
- Now does not compress content types like application/gzip
- Won't compress responses that already have a Content-Encoding
like gzip.
If it regenerates the response and then compares ETags then it should work, since both times the ETag will have been modified by the filter identically?.
Yes I understand what you are saying. The client will use an ETag value with a '-gzip' suffix. I hope that Tomcat somehow remembers the ETag value that the filter set, but I don't know that it does. I hope so, but I don't know what we can do if it doesn't.
If it doesn't work, all that happens is that Tomcat doesn't know to send 304 and instead sends the whole response. It still functions...
I think you are thinking of no-cache? A 'private' response may be cached by the browser but not intermediate proxies. In any event the filter itself does not cache or pay attention to any directive except 'no-transform' (which cancels compression).
