Hi Chris,
On 28/12/2013 19:34, Christopher Schultz wrote:
What type of data do you have on the disk?
Its all standard stuff. As specified by W3C, compressed SVG's
are just SVG's (which are just XML) compressed with gzip, with
a Mime-Type of "image/svg+xml", and extension ".svgz"
What content-type?
"image/svg+xml"
What content-type and content-encoding are sent to the browser?
Content-Type: image/svg+xml
Content-Encoding: not present
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
Tomcat's DefaultServlet should serve any file using gzip (with an
appropriate content-encoding) that matches the configured mime types
and isn't smaller than a certain size. All of these can be configured
with the compression, compressableMimeType, and compressionMinSize
attributes on your <Connector>.
I'm just using the xhtml <img src="/images/image.svgz"/> tag in a Facelet
Note that use of sendFile precludes
the use of gzip compression, so if you are using sendFile you aren't
going to get that kind of encoding.
I am not using sendFile.
- From a stock Tomcat install, to get .svg files served using
content-encoding:gzip, you'd need to modify your <Connector> to have
the following attributes:
compression="on"
compressableMimeType="...., image/svg+xml"
compressionMinSize="[big enough to exceed your file size"
sendFile="false" (if appropriate)
If the file is already compressed, then Tomcat will not re-compress
it, and won't use the content-encoding:gzip header because it's not
appropriate: the server is serving compressed content, not merely
compressing the content for transfer.
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 could be used (as a workaround) if compressed SVG's had the extension
.svg.gz
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");
}
All the best,
DaveLaw
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSvxmeAAoJEBzwKT+lPKRYHGoP/2AOOw9SDDdrh7SKEfQcjPF5
PYS+dzttdVA+0Gn5Kgm/i7VVzsqAiZ+OHFmN/pMqkDAyqFOKwDADzQ+hS2akp1yw
bbL6lFVkWX1TwiDBRh23JIV5ljCZRioVBDJtj+novk0ITBHAC73RdA4uJ1MpLsVX
wtXHBPamRjc2m5H1r5UBI/ZqUgM3Oa6WB8MUTgXddcZZJkaTkHUHzvmSJmkfe/zy
kgzGy1vFUw7jeEejEMLMcT6MZ3/Y1+T2IMOu6P90KojJa9jxSynb1gEEgT5t5aRX
e/i5VJlCunIHS8YX3B/LOhdSK0dfOgV4mjVl+v/YpWBi3YALpuNiBMX4PygUDaxW
uRO21Sz+3KP9oNvSuTmc+dZj3wShiVN2Cjve2pqHmI/7O6PWZmfwODDgoS7TpaFV
Cfmkpp6fhCRCjr4ckV5/v1RELQF4xIL8NnMbRIfvlwsBbIGP4XMf7OQsyjpXsYKQ
gHrkJv/U2yePrzExLcPVoHEoxFWQ9I0VMHpJSLdX+PZQQx38wx7aNg/P7X6Sq7oe
nRO0x/L7nKGarjB3ldXoPMoKEywym0X9lr0vDbPs7tT67igNXrcfKrMH+arMfabm
SukIDDGkq6fjOtfLAq9VHGvvk6i3VBjY3m+WExQ/TvTrHWfKoep2em+ExtUxSRMn
v6WvKDaLa9w5n+NjCNXU
=9hiN
-----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
