-----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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
