tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Compressed SVG support (*.svgz) in Tomcat
Date Sun, 29 Dec 2013 23:18:44 GMT
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
> - 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

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 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message