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