Hi André,

thats exactly what the JIRA Request is about:

We want a generic solution & not just something specific to *.svgz

Regarding the "Content-Transfer-Encoding header",
I'm afraid that's beyond me.
Maybe Mark has an opinion on that?


On 30/12/2013 00:18, André Warnier wrote:
Mark Thomas wrote:
On 28/12/2013 21:36, David Law wrote:
I just tried this in DefaultServlet:

if (contentType.equals("image/svg+xml")
&&  path.toLowerCase().endsWith(".svgz")) {
    response.addHeader("Content-Encoding", "gzip");

"Quick & dirty", but Works fine as proof-of-concept.
We just need a DefaultServlet expert to do the "slow & clean" stuff.

I'd suggest simply using a filter mapped to *.svgz for now.

I believe a generic solution to be best though, long-term. Something like:

That would be my preference but would require a change from the Servlet
EG. I'm not sure if adding a element to <mime-mapping> or adding a new
<encoding-mapping> element is the best solution. I created
https://java.net/jira/browse/SERVLET_SPEC-86 - feel free to add comments.

As a comment, I would like to add that the adding of a "Content-Encoding" header for certain data files served by Tomcat may be interesting for more types than just *.svgz files. For example, in document-management or archive applications, it is interesting to store various types of documents on the server in an already-compressed format and serve them that way, yet have the client receive the information necessary to automatically uncompress the response content to handle the original format correctly, without having to use a specific servlet filter or document-retrieval servlet to do so. The discussion about .svgz is equally applicable to all kinds of *.xxx.gz files for instance, where xxx may be PDF, MS-Office, plain text or whatever could be stored pre-compressed on the server. (Applications of the "store once, retrieve many times" model).

As another side-comment, there seems to exist an ambiguity/error in the following document : http://www.w3.org/TR/SVGTiny12/mimereg.html
In section "Security considerations", it says :


SVG documents may be transmitted in compressed form using gzip compression. For systems which employ MIME-like mechanisms, such as HTTP, this is indicated by the *Content-Transfer-Encoding header*; for systems which do not, ...

(emphasis mine)

but the HTTP specification in RFC 2616 does not have a "Content-Transfer-Encoding" header. It has "Content-Encoding" and "Transfer-Encoding", as two distinct headers with distinct meanings.

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to