https://bz.apache.org/bugzilla/show_bug.cgi?id=63932
--- Comment #8 from Michael Osipov <micha...@apache.org> --- (In reply to Konstantin Kolinko from comment #6) > (In reply to Mark Thomas from comment #5) > > Please take care, as Julian did, to be specific about whether you are > > talking about weak or strong validators. > > > > RFC 7232 states (section 2.1) > > <quote>[...]</quote> > > > > So the Default servlet (that only ever sets a weak ETag) is fine. As is the > > WebDAV servlet. > > +1 > > > Where things get "interesting" is when resources set their own, strong ETag. > > It looks to me that the simplest solution would be for the container > > provided compression to check for the presence of a strong ETag and, if it > > finds one, prepend the weakness indicator to the ETag if it is going to > > compress the resource. > > Interesting idea. But I think such feature has to be documented. A server > administrator should be aware that changing a Connector setting will change > behaviour of a web application in that way as well. (Changing strong ETag to > a weak one may affect performance of caches.) > > Another possible solution is to do not compress a response if a strong ETag > is encountered. The same what we do when a response is already compressed. > > https://github.com/apache/tomcat/blob/9.0.29/java/org/apache/coyote/ > CompressionConfig.java#L203 That sounds like an option. WDYT about adding a suffix and removing it on the fly like mod_deflate should do? I get the feeling that compression configuration must be moved sooner or later to a subelement <Compression> beneath a connector. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
