there's nothing to debate: the standard says svgz's need
Content-Encoding: gzip
so thats what we have to do.

At this rate, we'll never get the Internet finished by Easter...

Happy New Year,

On 31/12/2013 15:23, Christopher Schultz wrote:
Hash: SHA256


On 12/31/13, 2:52 AM, David Law wrote:
these are 2 completely different issues.

svgz's should be served with the correct encoding (gzip) as
required by the W3C SVG standard.  ALWAYS. That
means, files with the extension .svgz will be served, as they are,
with the Content-Encoding header gzip. This is
The "correct" encoding is debatable: one can argue that web servers
shouldn't be adding the Content-Encoding:gzip to resources that the
server itself did not gzip. If web servers were to take .gz files from
the disk and set Content-Encoding:gzip, then the client would
decompress the data upon receipt instead of storing the compressed
bytes sent by the server originally. That has the effect of mutating
the original resource form the perspective of the client.

In this case, the SVG standard is asking "SVG servers" (presumably
distinct from "web servers") to behave differently than originally
expected. I think there's some wiggle-room here and its not as
black-and-white as you propose.

"The Patch" is something completely different: it serves a file
with a particular extension, say *.XXX, from *.XXX.gz, if present.
SOMETIMES (depending on the Servlet gzip-parameter). This will add
a certain overhead, server-side, for EVERY FILE served. (because
"if present" implies a resources lookup)
True, but irrelevant. This is no different from serving any file from
a web server.

svgz's have the extension .svgz, not .svg.gz or .svgz.gz or
anything else for that matter, so "The Patch" will not have any
effect, and should not, for that matter.
The extension is not terribly relevant, other than its what you chose
to check for. In order to serve .svgz files in the way you want, a
simple Filter can be used -- and markt already gave you the code to do so.

Your original message said "Any chance of getting this [feature] at
long last?" You make it seem like Tomcat is refusing to implement some
crucial capability hat only the container can provide. This is not
true for two reasons: first, it is not necessary for Tomcat to
implement this - it can be done trivially by the web application;
second, there is already a component in Tomcat that can be used to do
this (bug 54095) with a bit of a tweak -- looking for filenames other
than "*.gz".

In your case, it probably makes sense to simply use Mark's Filter
until the Tomcat committers decide what to do about this case. Perhaps
an "example Filter" is the best thing to do here since it's a fairly
specific use case and definitely would result in surprising behavior
to many people if used by default. It's also clear there is room for
improvement to Philippe's initial patch.

- -chris
Version: GnuPG v1
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

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

Reply via email to