regarding the "Content-Transfer-Encoding" header mentioned in:

Content-Transfer-Encoding (CTE) is specified in RFC 2045 (MIME):

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."

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:

I think we were right to choose Content-Encoding.

All the best,

On 30/12/2013 01:28, David Law wrote:
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 - 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 meanings.

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

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

Reply via email to