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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
