r...@apache.org wrote: > + 0: remm (zzz) :) > * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=47013 > @@ -258,12 +260,13 @@ > http://svn.apache.org/viewvc?rev=764985&view=rev > http://svn.apache.org/viewvc?rev=764997&view=rev > +1: markt > + -0: remm: Why should this be backported ? > -1: It is trivial so safe to backport, but equally unlikely to cause any issues so no need to backport. I lean towards backporting but I can see why others may disagree.
> * Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46538 > @@ -271,4 +274,10 @@ > Based on a patch by Oliver Schoett > http://svn.apache.org/viewvc?rev=765727&view=rev > +1: markt > - -1: > + -1: remm: A hack (from what I read in 39727, the proxy folks say they are > right that two representations of > + one resource should have different ETag; I disagree with that since it > makes ) I agree with the proxy folks in that each variant should have a different ETag from both my reading of the HTTP spec and the fact that caches do break. > + - how would the DefaultServlet match the ETag header sent in If > conditions with this hack ? Now that is a valid point. Since 46538 was raised and I reviewed the comments on 39727, Roy has added comment about on-the-fly encoding that makes a similar point. PUTs are similarly broken. > + - Tomcat does not do random compression, so unless the Connector > configuration changes, there should be no issue, > + so the issue is very rare, but will remove caching, so it has real > consequences (bad) We will see issues where clients access content via a cache and - noCompressionUserAgents includes some but not all clients - some clients (for whatever reason) cannot handle compression > + I would be +0 for Connector configuration to strip the ETag (since it > would be useless, that's the easiest solution), That still leaves us with the original issue as the proxies still won't be able to tell compressed and uncompressed apart. > + -1 for all other options since it has an impact and fixes an edge case Having now read Roy's comment on 39727 I'm leaning towards reverting this patch and seeing what is possible following the Transfer-Encoding route. I'll sleep on it in case a better idea occurs to me and come back to this tomorrow. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
