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 :
quote
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, ...
unquote
(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
