You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by David Law <to...@apconsult.de> on 2013/12/28 18:06:44 UTC
Compressed SVG support (*.svgz) in Tomcat
Hi,
Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly.
The response should have a Content-Encoding header, value 'gzip'.
Any chance of getting this at long last?
(a change to org.apache.catalina.servlets.DefaultServlet, I presume)
Version: 7.0.47
All the best,
DaveLaw
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
Chris,
thanks for that. :-)
I'm starting a new project today, so I'll have
to wait til weekend to try out the Rule.
Marks Filter was nearly right: just needed to move the
chain.doFilter(request, response); // (invokes
DefaultServlet.serveResource(...))
AFTER
((HttpServletResponse) response).addHeader("Content-Encoding", "gzip");
Apart from that there's another workaround: I got a change
through in 2011 to PrimeFaces to allow setting Content-Encoding
for StreamedContent, so with a suitable BackingBean for
p:graphicImage it works since PrimeFaces v3.4.3.
All the Best,
DaveLaw
On 01/01/2014 19:36, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> avid,
>
> On 12/31/13, 10:43 AM, David Law wrote:
>> 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...
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55945
>
> It just occurred to me that you could also use urlrewrite[1] to do
> this. If you configure the Filter to match only .svgz files, then I
> think you only need this configuration:
>
> <rule>
> <set type="response-header" name="Content-Encoding">gzip</set>
> </rule>
>
> If you want to map the filter to more than that, then you'll want to
> predicate the rule using <from>:
>
> <rule matchtype="wildcard">
> <from>*.svgz</from>
> <set type="response-header" name="Content-Encoding">gzip</set>
> </rule>
>
> I haven't tested any of this. It will probably require some tweaking.
>
> I was going to add an enhancement request to Bugzilla for a Filter
> like the one Mark wrote, but I figured that urlrewrite could do it,
> too. Perhaps such a filter would still be a good example.
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=55946
>
> - -chris
>
> [1] http://www.tuckey.org/urlrewrite/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSxGAWAAoJEBzwKT+lPKRYYhEQAI4/5XoPs05NXaxViPMTn+en
> UuLyjnzfbCS85Szr+PaoAFze2f8UwOpRpBYk+Xy9Gms6Zs/Nr+STDiDZ2MxiPw6K
> LoKPxQJIh4Lt54kD6OuqdO1dr5Umf1Bs2cQ2k2o2ntK1BwV7hw+UOSVSLGEq4biM
> ByG2YCttB4dR5elL2ykjjgxpiqlCbeYS5iWQTtAoKX78jM0Ti7nuLwn51oYCrAgS
> VNz73VXm8NFM1y5sxbmUsqmm28HrXWjk0B5kaqeT7xRwCxkuvNf7eHvfCu/qIE/c
> 2EiEbMaEij2kk9Geldo+Tn6pmXM6gVAOeqTQwylqhOe34mWd8iLsp3QF5erc+XgQ
> ktcQoNfPcnUulFmIm+EAg4HUyvLwE0RIXj/yRAs3CbvUupgxeyxO/yLcdukaKh+O
> 7cT5JKPBFm0uoUjZW0OcDfkvND2r4PvcRrSeauH6yUMuDsAocDQbUTD+n89NPbVh
> iVvQsxNLY1x2Eu5cJ1niMpR6HRtGjyusZVQyBW5M4q1p9im100eTIW3MXcviB4xr
> c3uOo/D73Xci5h+MjfFY8KAgjsw2KMCgIGuzVYU5c3CHG5hVk4OPAFXMtIP/NE83
> ORE4PJbdTad/oQaPd4I5r2ugcPZno4GFIB67IOxgy3MZgsoX9Y81B0vU8AsK1fj9
> G8XTtkNXOibqh2rX/06T
> =54if
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
avid,
On 12/31/13, 10:43 AM, David Law wrote:
> 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...
https://issues.apache.org/bugzilla/show_bug.cgi?id=55945
It just occurred to me that you could also use urlrewrite[1] to do
this. If you configure the Filter to match only .svgz files, then I
think you only need this configuration:
<rule>
<set type="response-header" name="Content-Encoding">gzip</set>
</rule>
If you want to map the filter to more than that, then you'll want to
predicate the rule using <from>:
<rule matchtype="wildcard">
<from>*.svgz</from>
<set type="response-header" name="Content-Encoding">gzip</set>
</rule>
I haven't tested any of this. It will probably require some tweaking.
I was going to add an enhancement request to Bugzilla for a Filter
like the one Mark wrote, but I figured that urlrewrite could do it,
too. Perhaps such a filter would still be a good example.
https://issues.apache.org/bugzilla/show_bug.cgi?id=55946
- -chris
[1] http://www.tuckey.org/urlrewrite/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSxGAWAAoJEBzwKT+lPKRYYhEQAI4/5XoPs05NXaxViPMTn+en
UuLyjnzfbCS85Szr+PaoAFze2f8UwOpRpBYk+Xy9Gms6Zs/Nr+STDiDZ2MxiPw6K
LoKPxQJIh4Lt54kD6OuqdO1dr5Umf1Bs2cQ2k2o2ntK1BwV7hw+UOSVSLGEq4biM
ByG2YCttB4dR5elL2ykjjgxpiqlCbeYS5iWQTtAoKX78jM0Ti7nuLwn51oYCrAgS
VNz73VXm8NFM1y5sxbmUsqmm28HrXWjk0B5kaqeT7xRwCxkuvNf7eHvfCu/qIE/c
2EiEbMaEij2kk9Geldo+Tn6pmXM6gVAOeqTQwylqhOe34mWd8iLsp3QF5erc+XgQ
ktcQoNfPcnUulFmIm+EAg4HUyvLwE0RIXj/yRAs3CbvUupgxeyxO/yLcdukaKh+O
7cT5JKPBFm0uoUjZW0OcDfkvND2r4PvcRrSeauH6yUMuDsAocDQbUTD+n89NPbVh
iVvQsxNLY1x2Eu5cJ1niMpR6HRtGjyusZVQyBW5M4q1p9im100eTIW3MXcviB4xr
c3uOo/D73Xci5h+MjfFY8KAgjsw2KMCgIGuzVYU5c3CHG5hVk4OPAFXMtIP/NE83
ORE4PJbdTad/oQaPd4I5r2ugcPZno4GFIB67IOxgy3MZgsoX9Y81B0vU8AsK1fj9
G8XTtkNXOibqh2rX/06T
=54if
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
Chris,
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,
DaveLaw
On 31/12/2013 15:23, Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> David,
>
> 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.
>> 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 "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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF
> 6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt
> b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02
> oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui
> C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO
> ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6
> WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG
> VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc
> OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc
> yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml
> C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS
> FGKrbQ7zojR3wVHhGGlH
> =WjKV
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
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.
> 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 "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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJSwtNPAAoJEBzwKT+lPKRYkkUP/0GMkM0KoOV+y9iXqOC6k9QF
6mAi9jANwOzlXSxJgcxg/iTPn1pxd7XSc1Iqhyzt5pb6gO57LK4LUhGu3RxyJMEt
b5sJqTNNdkaTs4r7B9R0RdGykAlLNrGDa1Nf21d5IQKVgvp5/1W0ONYnhF0VfS02
oLcix/fePy79Yw0O+lvjuBWu5cl+5V3c9JzrH2XBsWYngGocZBVWYhFHc0eUBtui
C9G8ilTC7o820rBq79y5pqigZQzT2CPSPdbcPxZ7lD0V7Fc6G8KcrJy0S82/36qO
ApXnr+1IaNOn8Mxs/FhUFjeX0uS3ZvR6Iuc53aQ840fZbKgPfuRriOO7meK+7wm6
WgnmTzt4G2D58pxmpZ8UyYngUoIJNwaluVBY8XCD+CiffQZTliTY7kbgf+GBXpdG
VRnA3eTqHQAd/cWjho5qFq67uG7wE8B+r9Mx30WkKqERYEWM7b+GK4c5wK3jZ7Xc
OP5tcNkx8u+2yy7toIPQ5roOvwEP7iBnIWiT51WTPA9s/2jBccyfLPX4T1kgEWuc
yJNrPOtBDLu5nVhsy6kQkHzHGFCW8Yx0NQeKCDMu3OsIViSEjuZTq6/mGXUqg5ml
C/O3z0cPX4TQKKhVZA7merBp6aMCiYv8cxitxnVeyqxGgok1Ck+ITaMP6W3OYjCS
FGKrbQ7zojR3wVHhGGlH
=WjKV
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
Hi Jan,
yes, that's the problem & plain-text SVG's are so bloated.
Opera does a stateful inspection of the stream to see
if its compressed or not, but the Spec states they must
be marked as gzip-Encoded in the Response Header, so we
can't really fault Firefox & co for adhering to that Spec.
The Internet Forums are full of entries from people
looking for a solution, so I hopethe JIRA <https://java.net/jira/browse/SERVLET_SPEC-86> Mark created
will meet with approval.
All the best,
DaveLaw
On 29/12/2013 11:18, Jan Tosovsky wrote:
> On 2013-12-28 David Law wrote:
>> 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"
> Btw, I've stopped using compressed SVG variant for web recently as
> 1. stored on local disk couldn't be displayed in some browsers (works in Chrome, but not in FF or IE) - my files were intended for downloading by users hence this was a serious limitation.
> 2. all my web content is transferred to the client gzipped anyway so there is no gain in the 'content length'.
> 3. no additional settings was required
>
> Jan
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
RE: Compressed SVG support (*.svgz) in Tomcat
Posted by Jan Tosovsky <j....@email.cz>.
On 2013-12-28 David Law wrote:
> 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"
Btw, I've stopped using compressed SVG variant for web recently as
1. stored on local disk couldn't be displayed in some browsers (works in Chrome, but not in FF or IE) - my files were intended for downloading by users hence this was a serious limitation.
2. all my web content is transferred to the client gzipped anyway so there is no gain in the 'content length'.
3. no additional settings was required
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
David Law wrote:
> Hi André,
>
> no. I think Chris was semantically correct with
> "[big enough to exceed your file size]"
>
> Unfortunately, his answer had nothing to do with my posting.
>
> Mark Thomas hit the nail on the head though:
> http://tomcat.markmail.org/message/zptxhevgzkpr7if2
>
You are right, that was hasty of me.
Chris was in fact talking about an alternative : having the files stored /not/ compressed,
and let Tomcat do the compression.
And I mixed it all up further, thinking of Tomcat only compressing the non-compressed
files (supposedly larger), and leaving the compressed ones (supposedly smaller) alone.
Neither of which matched your request.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
Hi André,
no. I think Chris was semantically correct with
"[big enough to exceed your file size]"
Unfortunately, his answer had nothing to do with my posting.
Mark Thomas hit the nail on the head though:
http://tomcat.markmail.org/message/zptxhevgzkpr7if2
All the best,
DaveLaw
On 29/12/2013 14:10, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>> David,
>>
>> On 12/28/13, 12:06 PM, David Law wrote:
>>> Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly.
>>> The response should have a Content-Encoding header, value 'gzip'.
>>>
>>> Any chance of getting this at long last? (a change to
>>> org.apache.catalina.servlets.DefaultServlet, I presume)
>>>
>>> Version: 7.0.47
>>
>> What type of data do you have on the disk? What content-type? What
>> content-type and content-encoding are sent to the browser?
>>
>> 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>. 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.
>>
>> - 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"
>
> I believe that this should be instead : [small enough to *not* exceed
> you file size].
> No ?
>
>> sendFile="false" (if appropriate)
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> David,
>
> On 12/28/13, 12:06 PM, David Law wrote:
>> Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly.
>> The response should have a Content-Encoding header, value 'gzip'.
>>
>> Any chance of getting this at long last? (a change to
>> org.apache.catalina.servlets.DefaultServlet, I presume)
>>
>> Version: 7.0.47
>
> What type of data do you have on the disk? What content-type? What
> content-type and content-encoding are sent to the browser?
>
> 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>. 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.
>
> - 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"
I believe that this should be instead : [small enough to *not* exceed you file size].
No ?
> sendFile="false" (if appropriate)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
David,
On 12/28/13, 12:06 PM, David Law wrote:
> Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly.
> The response should have a Content-Encoding header, value 'gzip'.
>
> Any chance of getting this at long last? (a change to
> org.apache.catalina.servlets.DefaultServlet, I presume)
>
> Version: 7.0.47
What type of data do you have on the disk? What content-type? What
content-type and content-encoding are sent to the browser?
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>. 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.
- 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
- -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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
David Law wrote:
> 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.
>
I agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by André Warnier <aw...@ice-sa.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
On 29/12/2013 17:17, David Law wrote:
> Mark,
>
> many, many thanks for your prompt action. :-)
>
> I will add my thoughts to your JIRA
> <https://java.net/jira/browse/SERVLET_SPEC-86>.
>
> I guess the matter is now out of our hands
> & we have to hope the Servlet guys @ java.net
> are open to our proposal. I hope it won't take years,
> as I have a feeling the adoption of SVG is threatened
> by the lack of support for svgz's: there are an awful
> lot of people trawling the internet for an answer.
>
> Would it be too much trouble to detail
> how such a Filter-Definition might look?
> (I really am quite new to all this, being
> more at home with a mainframe)
A quick, dirty and totally untested Filter implementation:
http://people.apache.org/~markt/dev/SvgzFilter.java
Handling the Accept-Encoding header is left as an exercise for the reader.
Mark
>
> There is another workaround: we got a change
> <http://code.google.com/p/primefaces/issues/detail?id=4264> to
> PrimeFaces through in 2012 which was released
> with 3.5 & retrospectively 3.4.3, so it is possible to
> write a backing-bean to serve svgz's via p:graphicImage.
>
> Thanks again,
> DaveLaw
>
> On 29/12/2013 10:06, 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.
>>
>> Mark
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
Mark,
many, many thanks for your prompt action. :-)
I will add my thoughts to your JIRA
<https://java.net/jira/browse/SERVLET_SPEC-86>.
I guess the matter is now out of our hands
& we have to hope the Servlet guys @ java.net
are open to our proposal. I hope it won't take years,
as I have a feeling the adoption of SVG is threatened
by the lack of support for svgz's: there are an awful
lot of people trawling the internet for an answer.
Would it be too much trouble to detail
how such a Filter-Definition might look?
(I really am quite new to all this, being
more at home with a mainframe)
There is another workaround: we got a change
<http://code.google.com/p/primefaces/issues/detail?id=4264> to
PrimeFaces through in 2012 which was released
with 3.5 & retrospectively 3.4.3, so it is possible to
write a backing-bean to serve svgz's via p:graphicImage.
Thanks again,
DaveLaw
On 29/12/2013 10:06, 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.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by Mark Thomas <ma...@apache.org>.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
Posted by David Law <to...@apconsult.de>.
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 believe a generic solution to be best though, long-term. Something like:
<mime-mapping>
<extension>svgz</extension>
<mime-type>image/svg+xml</mime-type>
<encoding>gzip</encoding>
</mime-mapping>
...with a new Tag, for example: "encoding"
All the best,
DaveLaw
On 28/12/2013 18:06, David Law wrote:
> Hi,
>
> Tomcat doesn't seem to serve compressed SVG's (*.svgz) correctly.
> The response should have a Content-Encoding header, value 'gzip'.
>
> Any chance of getting this at long last?
> (a change to org.apache.catalina.servlets.DefaultServlet, I presume)
>
> Version: 7.0.47
>
> All the best,
> DaveLaw
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org