You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2009/04/16 23:24:21 UTC
svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: remm
Date: Thu Apr 16 21:24:19 2009
New Revision: 765764
URL: http://svn.apache.org/viewvc?rev=765764&view=rev
Log:
- Votes.
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=765764&r1=765763&r2=765764&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Apr 16 21:24:19 2009
@@ -141,42 +141,42 @@
* Fix some failures when testing WebDAV with litmus test suite
http://svn.apache.org/viewvc?view=rev&revision=761601
- +1: markt
+ +1: markt, remm
-1:
* Update native to 1.1.16
http://svn.apache.org/viewvc?view=rev&revision=762868
- +1: markt
+ +1: markt, remm
-1:
* Fix .exe and .pdf corruption in -src.tar.gz bundle
http://svn.apache.org/viewvc?view=rev&revision=762936
- +1: markt
+ +1: markt, remm
-1:
* Enable running of Tomcat directly from build directory on linux
http://svn.apache.org/viewvc?view=rev&revision=762937
http://svn.apache.org/viewvc?view=rev&revision=762929
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46982
Correct report DST offset in access logs
http://svn.apache.org/viewvc?rev=763166&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46933
Simplify StringManager using Java 5. Includes test case. Based on a patch by
Jens Kapitza
http://svn.apache.org/viewvc?rev=763183&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46958
Allow xml manager status to work irrespective of context path
http://svn.apache.org/viewvc?rev=763193&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46967
@@ -198,12 +198,13 @@
Patch provided by sebb@a.o
http://svn.apache.org/viewvc?rev=763298&view=rev
+1: markt
+ 0: remm (zzz)
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46991
Update counters before request is re-cycled
http://svn.apache.org/viewvc?rev=763302&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46509
@@ -216,13 +217,14 @@
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46562
Close the reader in the SSI servlet when we are done
http://svn.apache.org/viewvc?rev=763599&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=46909
Only include ';' in type attribute if there is a parameter
http://svn.apache.org/viewvc?rev=763611&view=rev
+1: markt
+ 0: remm (zzz)
-1:
* https://issues.apache.org/bugzilla/show_bug.cgi?id=46984
@@ -235,14 +237,14 @@
ArrayIndexOutOfBoundsException when using
org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true
Patch provided by Konstantin Kolinko
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=42579
Handle both relative and absolute search results
Patch provided by Brandon DuRette
http://svn.apache.org/viewvc?rev=763706&view=rev
- +1: markt
+ +1: markt, remm
-1:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=42390
@@ -250,7 +252,7 @@
"AT_BEGIN" scope
Patch provided by Konstantin Kolinko
http://svn.apache.org/viewvc?rev=763717&view=rev
- +1: markt
+ +1: markt, remm (risky ...)
-1:
* 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:
* Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=37929
Invalidated session causes pageContext methods to fail
http://svn.apache.org/viewvc?rev=765662&view=rev
- +1: markt
+ +1: markt, remm
-1:
* 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 )
+ - how would the DefaultServlet match the ETag header sent in If conditions with this hack ?
+ - 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)
+ I would be +0 for Connector configuration to strip the ETag (since it would be useless, that's the easiest solution),
+ -1 for all other options since it has an impact and fixes an edge case
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Mark Thomas <ma...@apache.org>.
Remy Maucherat wrote:
> On Fri, 2009-04-17 at 09:38 +0100, Mark Thomas wrote:
>> Can you remember what didn't work with Transfer-Encoding?
>
> I don't remember, it was years ago. I simply used the encoding name
> specified in T-E to add the compression input filter (for input) rather
> than using the compression custom hack. I could not get browsers to do
> anything at the time, so I switched to content-encoding (which is the
> same thing from a user perspective, but it worked).
>
> The problem number 2 with T-E is that it is point to point. So the proxy
> has to decompress the entity, T-E cannot be cached as is, it's like
> chunking. So it is less efficient. However, T-E is really the right
> thing to do at the connector level, using content-encoding should be up
> to the application (and random compression filters). Too bad it did not
> work ...
Worth checking the current state to see if it has changed then.
>>> I don't understand why giving an option to not send an ETag would not
>>> also be a solution. At least, if it does not, I do not understand how
>>> proxies are not broken.
>> To quote Roy from bug 39727:
>> "removing etags for the entire configured scope allows clients to use
>> the last-modified timestamp for range requests, which would be just as
>> bad as not changing ETag"
>
> Still, we would comply with the spec, and it becomes the proxy
> responsibility. My point is to demonstrate the specification is broken.
> It is then up to the proxies impls to do the right thing, or do a lawyer
> approach to the problem. If they do, I suggest we can do the same thing,
> and adding an option to drop ETags is perfectly acceptable.
>
>>> I also think proxies should be smarter, and assume serving of both a
>>> compressed and an uncompressed version, obviously using the same ETag
>>> (and send the right version depending on whether or not the client has
>>> compression). Otherwise, there's no way things can be efficient.
>> It appears that some caches do already do this although behaviour is far
>> from consistent among caches. Unfortunately this is outside the spec so
>> there is no guarantee of what the behaviour may be.
>
> Maybe so, but it is an efficient solution.
I'm currently thinking along the following lines:
See if T-E support is any better now that it was a few years ago when
you looked at it. (An initial Google has been inconclusive - I need to
do some actual testing).
For TC7, *if* T-E support is better do something along the lines of:
- Use T-E for compression by default
- Depending on browser support for T-E provide options to
- use T-E even if clients don't send the right request headers
- fall back to using C-E
- Provide options for:
- using C-E by default
- including/not including a vary header
- modifying/removing the ETag
If T-E support in browsers is poor, just provide the additional
configuration options for C-E.
For TC6 don't make the T-E changes but maybe backport some/all of the
C-E configuration options so folks can tweak things to work a little
better for the edge cases with their favourite proxy cache.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Remy Maucherat <re...@apache.org>.
On Fri, 2009-04-17 at 09:38 +0100, Mark Thomas wrote:
> Remy Maucherat wrote:
> > On Thu, 2009-04-16 at 23:09 +0100, Mark Thomas wrote:
> >> 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.
> >
> > If you look at the Coyote code, you can probably guess I originally
> > thought about compression using transfer-encoding (prepareRequest is
> > rather obvious about that), and it did not work. Content-encoding did,
> > though.
>
> Can you remember what didn't work with Transfer-Encoding?
I don't remember, it was years ago. I simply used the encoding name
specified in T-E to add the compression input filter (for input) rather
than using the compression custom hack. I could not get browsers to do
anything at the time, so I switched to content-encoding (which is the
same thing from a user perspective, but it worked).
The problem number 2 with T-E is that it is point to point. So the proxy
has to decompress the entity, T-E cannot be cached as is, it's like
chunking. So it is less efficient. However, T-E is really the right
thing to do at the connector level, using content-encoding should be up
to the application (and random compression filters). Too bad it did not
work ...
> > I don't understand why giving an option to not send an ETag would not
> > also be a solution. At least, if it does not, I do not understand how
> > proxies are not broken.
>
> To quote Roy from bug 39727:
> "removing etags for the entire configured scope allows clients to use
> the last-modified timestamp for range requests, which would be just as
> bad as not changing ETag"
Still, we would comply with the spec, and it becomes the proxy
responsibility. My point is to demonstrate the specification is broken.
It is then up to the proxies impls to do the right thing, or do a lawyer
approach to the problem. If they do, I suggest we can do the same thing,
and adding an option to drop ETags is perfectly acceptable.
> > I also think proxies should be smarter, and assume serving of both a
> > compressed and an uncompressed version, obviously using the same ETag
> > (and send the right version depending on whether or not the client has
> > compression). Otherwise, there's no way things can be efficient.
>
> It appears that some caches do already do this although behaviour is far
> from consistent among caches. Unfortunately this is outside the spec so
> there is no guarantee of what the behaviour may be.
Maybe so, but it is an efficient solution.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Mark Thomas <ma...@apache.org>.
Remy Maucherat wrote:
> On Thu, 2009-04-16 at 23:09 +0100, Mark Thomas wrote:
>> 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.
>
> If you look at the Coyote code, you can probably guess I originally
> thought about compression using transfer-encoding (prepareRequest is
> rather obvious about that), and it did not work. Content-encoding did,
> though.
Can you remember what didn't work with Transfer-Encoding?
> I don't understand why giving an option to not send an ETag would not
> also be a solution. At least, if it does not, I do not understand how
> proxies are not broken.
To quote Roy from bug 39727:
"removing etags for the entire configured scope allows clients to use
the last-modified timestamp for range requests, which would be just as
bad as not changing ETag"
> I also think proxies should be smarter, and assume serving of both a
> compressed and an uncompressed version, obviously using the same ETag
> (and send the right version depending on whether or not the client has
> compression). Otherwise, there's no way things can be efficient.
It appears that some caches do already do this although behaviour is far
from consistent among caches. Unfortunately this is outside the spec so
there is no guarantee of what the behaviour may be.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Remy Maucherat <re...@apache.org>.
On Thu, 2009-04-16 at 23:09 +0100, Mark Thomas wrote:
> 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.
If you look at the Coyote code, you can probably guess I originally
thought about compression using transfer-encoding (prepareRequest is
rather obvious about that), and it did not work. Content-encoding did,
though.
I don't understand why giving an option to not send an ETag would not
also be a solution. At least, if it does not, I do not understand how
proxies are not broken.
I also think proxies should be smarter, and assume serving of both a
compressed and an uncompressed version, obviously using the same ETag
(and send the right version depending on whether or not the client has
compression). Otherwise, there's no way things can be efficient.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: svn commit: r765764 - /tomcat/tc6.0.x/trunk/STATUS.txt
Posted by Mark Thomas <ma...@apache.org>.
remm@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org