André,
regarding the "Content-Transfer-Encoding" header mentioned in:
http://www.w3.org/TR/SVGTiny12/mimereg.html
Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME):
http://tools.ietf.org/html/rfc2045
RFC 2616 (HTTP/1.1) states, here "19.4.5 No Content-Transfer-Encoding":
"HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045."
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Also, under RFC 2616 (HTTP/1.1) 19.4.4 & 19.4.6 respectively,
Content-Encoding & Transfer-Encoding are introduced.
Transfer-Encoding & Content-Transfer-Encoding are intended
for use in transmission only, so the data will arrive intact.
An example of such would be Base64:
http://en.wikipedia.org/wiki/Base64
I think we were right to choose Content-Encoding.
All the best,
DaveLaw
On 30/12/2013 01:28, David Law wrote:
Hi André,
thats exactly what the JIRA Request is about:
https://java.net/jira/browse/SERVLET_SPEC-86
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?
Regards,
DaveLaw
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 :
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
