tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Serving gz files in DefaultServlet (Re: r1531115, BZ 54095)
Date Tue, 15 Oct 2013 16:43:18 GMT

On 10/15/13 7:15 AM, Konstantin Kolinko wrote:
> 2013/10/13 Mark Thomas <>:
>> On 13/10/2013 14:11, Konstantin Kolinko wrote:
>> <snip/>
>>>> URL:
>>>> Log:
>>>> Fix
>>>> 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]
> [2]
> [3]
> [4]

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.


View raw message