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

Reply via email to