Chris,
these are 2 completely different issues.
svgz's should be served with the correct encoding (gzip)
as required by the W3C SVG standard. ALWAYS.
http://www.w3.org/TR/SVG11/conform.html#ConformingSVGServers
That means, files with the extension .svgz will be served,
as they are, with the Content-Encoding header gzip.
This is performance-neutral.
"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)
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.
All the best,
DaveLaw
On 30/12/2013 16:12, Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 12/28/13, 3:20 PM, David Law wrote:
No Content-Encoding header is sent in the response. And that is
exactly the problem: DefaultServlet needs to be changed to serve up
svgz's with Content-Encoding gzip
Okay, so you would then need to use this:
If you want to serve pre-compressed content then you'll have to
do some work yourself (unless you are using Tomcat 8). There have
been a few discussions on the various lists over the past few
years. For example,
http://markmail.org/message/w2kpjqibrkxmxmup
http://markmail.org/thread/h5kyjofpkglpkfks
Tomcat 8.0.4-RC4+ should already support pre-compressed files:
https://issues.apache.org/bugzilla/show_bug.cgi?id=54095
I am aware of the changes made by Philippe Marschall (r1531115) &
Mark Thomas regarding gzip. This is quite useful but does not
address my Issue.
It should: your scenario is exactly the one targeted by the patch.
It could be used (as a workaround) if compressed SVG's had the
extension .svg.gz
What's wrong with .svgz? Tomcat's out-of-the-box MIME types include
mappings for .svg and .svgz, which appears to be appropriate.
http://www.w3.org/services/svg-server/
I've also read http://kaioa.com/node/45 but the use of
Content-Encoding appears to be a hack: the SVG reader should accept
both uncompressed and gzip-compressed streams. It does not seem
reasonable for Tomcat itself to include this specific hack.
I'm still not sure why Phillipe's solution does not give you what you
need: it adds pre-compressed file-serving capabilities, which is
exactly what you want. You said above that it doesn't meet your needs:
in what was is that solution lacking?
But they don't: W3C specifies the extension as .svgz We just need
Tomcat to serve up svgz's with Content-Encoding gzip. Something
like this: if (contentType.equals("image/svg+xml") &&
path.toLowerCase().endsWith(".svgz")) {
response.addHeader("Content-Encoding", "gzip"); }
See markt's reply for an example filter.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSwY1AAAoJEBzwKT+lPKRYqkAP/2xFxRpSsWZaJYGo4YYeaAld
ouRlfZdl8PKGZaDOufXJmsJtCXoQAV/nU40o9PSkF9aYE5v2AKW3c0AXod1PgE09
2ZbDTaPHBcXj24nH74HgsNe3LgROOWy1//lJSrK8HncHe2lQYfpzBPzJrv89DdxN
tKmqeR6s+JILGxWyx1EN95sD7DIQqGJ3XJbIYBzyRVVT7tDCDnV+TNdCxNWBO3qX
Jrmhnrntkl+yCY8b2ETu+18+fBmB+T88kf0Dta74qIAXbYezZom5xYcXit7ITBEA
1GyEgyvGzYbliRDXKiYn1a1LJV+C1vwBpZb86Tt7kkcd6a5H+6kYUjk9hK7QomdJ
v0yXCRKfuqUhagSz3eCOeZiYHyhfPtVDOlduRu3OzGOL+7lirZpcxPn2GxaGdRuW
XAoCHs1Wce+LhWsBOMkX/67ygZ2zpCqVgjZiRetZ5czx0Xyx+/S4mTpY6zN6Ieh6
SqeU/MjWNmzkJWJG45Q6WQhqZQJ508Z5EGi+ACjIv6kp6T08GpIKt4GzLqnQrXiU
Zrwr/saMIu2xxxMh+FnUIPWFLkl3YzvSrpVH9ovasmdR7ZJCbc72s5EyLvw8cjJs
7Sd9faxgT4ZFqeGgEmpV8fA4w47HLwLFFe5HD3D19DKpxs7PBiIJVIWd0n14uPKu
Kh3EgQVgNH8VxmvOu4fH
=WTmg
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
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
