Issue Details (XML | Word | Printable)

Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: markt_asf
Votes: 1
Watchers: 1

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

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

Participants: DaveLaw and markt_asf

 Description  « Hide

This arose from this discussion on the Tomcat users mailing list:

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

2. Extend <mime-mapping> along these lines:

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:
____<encoding>gzip</encoding> <!-- optional -->
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.