Konstantin, On 10/15/13 7:15 AM, Konstantin Kolinko wrote: > 2013/10/13 Mark Thomas <ma...@apache.org>: >> On 13/10/2013 14:11, Konstantin Kolinko wrote: >> >> <snip/> >> >>>> URL: http://svn.apache.org/r1531115 >>>> Log: >>>> Fix https://issues.apache.org/bugzilla/show_bug.cgi?id=54095 >>>> Add support to the Default Servlet for serving gzipped versions of static >>>> resources directly from disk as an alternative to Tomcat compressing them >>>> on each request. Patch by Philippe Marschall. >> >> <snip/> >> >>> General: >>> I think this feature should be opt-in, like the listings feature of >>> DefaultServlet, being off by default. >> >> I disagree since: >> - this is only in 8.0.x and we haven't had a stable release yet. >> - the user has to create the gzip'd version which is unlikely to exist >> be default before this feature does anything >> >> I agree if it is ever back-ported to earlier versions it needs to be >> disabled by default. >> > > My concern is that this feature is not stated by Specification, and by > default I think people should not expect this behaviour from "default" > servlet. Thus I think it should be an opt-in feature. > > > The files may already exist there for some other reasons. E.g. if an > application uses a framework that implements this feature by itself > independently of Tomcat. > >>> (2) Additional access path for ".gz" files, which might be not covered >>> by security constraints >>> > > E.g. if "foo.gz" is protected by a constraint and should not be served > directly, it can now be accessed by asking for "foo". It only works > if "foo" exists as well, so unlikely it causes anything, but this is > an additional access path. > >>> (3) Interoperability with filters that may preprocess or postprocess >>> the response, >>> including ISE handling in the following lines of DefaultServlet: >>> >>> [[[ >>> try { >>> ostream = response.getOutputStream(); >>> } catch (IllegalStateException e) { >>> ... >>> writer = response.getWriter(); >>> ]]] >> >> I've disabled the fall back for (3). >> > > I'd be better to fallback to serving the original resource instead of > failing. I agree that it is a rare case, though. > >> > > There is also a list of options for DefaultServlet just above its > definition in conf/web.xml. It has not been updated. > >> > > Looking at how Apache HTTPD deals with this content negotiation feature, > > First, > this feature is present by default (mod_negation is compiled in), but > is turned off. To enable it you have to enable it with "Options > MultiViews" directive on specific directory. Note that using "Options > All" does not enable this feature, you have to enable it explicitly. > [1][4] > > Second, > Apache HTTPD goes to some length to prevent unwanted caching of these > responses by proxies. > > "To prevent this, httpd normally marks all responses that are returned > after content negotiation as non-cacheable by HTTP/1.0 clients" [1] > It is configurable with directive "CacheNegotiatedDocs". > > For HTTP/1.1 clients it sends a "Vary" header, such as "Vary: > Accept-Encoding". [1][3]. > > [1] http://httpd.apache.org/docs/current/content-negotiation.html > [2] http://httpd.apache.org/docs/current/mod/mod_negotiation.html > [3] http://httpd.apache.org/docs/current/mod/mod_deflate.html > [4] http://httpd.apache.org/docs/current/mod/core.html#options
It's also worth pointing out that what has been implemented for Tomcat is a serious pain in the neck to do in httpd. Basically, to get it to work as expected in httpd, you need several animal sacrifices and a fair amount of arcane words to get it done. At this point, I have the animal part done but my pronunciation must be off because I still don't have it working properly. That said, making it easy to do in Tomcat - while nice - is also a bit dangerous given the previous arguments. I agree with the decision to disable this by default... just wanted to add a "me too" voice in case you wanted some more input, Mark. Thanks, -chris
signature.asc
Description: OpenPGP digital signature