Issue Details (XML | Word | Printable)

Key: SERVLET_SPEC-86
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: markt_asf
Votes: 1
Watchers: 1
Operations

If you were logged in you would be able to see more operations.
servlet-spec

Support the specification of a content-encoding header for a resource based on file extension

Created: 29/Dec/13 09:06 AM   Updated: 30/Dec/13 09:45 AM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Time Tracking:
Not Specified

Tags:
Participants: DaveLaw and markt_asf


 Description  « Hide

This arose from this discussion on the Tomcat users mailing list:
http://tomcat.markmail.org/thread/6x7izjf7ltphhh7r

Compressed SVG files (*.svgz) require that the server sets the Content-Encoding header so that the user agent correctly renders the response.

I would like to see the Servlet specification extended to allow applications to specify a Content-Encoding header for resources with a given file extension.

Any setting of the Content-Encoding on the response would have to be mindful of any Accept-Encoding header sent by the user agent and the requirements of RFC 2616 section 14.3.

This is very like the <mime-mapping> element currently used to configure Content-Type.

I see two possible options:

1. Add support for something along these lines
<encoding-mapping>
<extension>svgz</extension>
<encoding>gzip</encoding>
</encoding-mapping>

2. Extend <mime-mapping> along these lines:
<mime-mapping>
<extension>svgz</extension>
<mime-type>image/svg+xml</mime-type>
<encoding>gzip</encoding>
</mime-mapping>

The second solution seems simpler but <mime-mapping> element would no longer be limited to MIME type mapping. The first solution is probably a better option.



DaveLaw added a comment - 30/Dec/13 09:44 AM - edited

I believe "The second solution" is better:
<mime-mapping>
____<extension>svgz</extension>
____<mime-type>image/svg+xml</mime-type>
____<encoding>gzip</encoding> <!-- optional -->
</mime-mapping>
:
Unless there are overwhelming reasons to do so, it doesn't make sense
to maintain two separate lists, both with the same "primary key" (<extension>),
it would just make things (even) more confusing.
Of course, the <encoding> attribute should be optional.
And of course, it could perhaps be called, for example, <content-encoding>
:
I hope this can be resolved quickly, as I see the whole future of SVG Graphics
threatened by the patchwork implementation we've seen to date, particularly as
"plain-text" SVG's are so bloated, making compression very important.