tomcat-dev mailing list archives

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

On 10/15/13 7:15 AM, Konstantin Kolinko wrote:
> 2013/10/13 Mark Thomas <markt@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


Mime
View raw message