Quinta dos Três Rios
Hi Dave, nice to speak to you just now. The place I mentioned in Portugal is: Quinta dos Três Rios http://www.minola.co.uk/ ...a treasure trove. :-) Hope we'll be able to bump into you soon. All the best, Dave
Who the f*** is Stephen?
Hi Alex, hope you're thriving. I got a LinkedIn invitation from a Stephen Everson who (I think...) I've never heard of. I see he's one of your connections. Any idea who he is why he would be contacting me? Dave - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 7.0.50 released
Thanks for that. :-) You might like to correct this Typo under Tomcat 7.0.50 / Catalina: Streamline handling of WebSocket messages whe... to when or where for example. All the best, DaveLaw On 12/01/2014 11:15, Violeta Georgieva wrote: The Apache Tomcat team announces the immediate availability of Apache Tomcat 7.0.50. Apache Tomcat is an open source software implementation of the Java Servlet, JavaServer Pages and Java Expression Language technologies. This release contains a number of bug fixes and improvements compared to version 7.0.47. Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-7.0-doc/changelog.html Note: This version has 4 zip binaries: a generic one and three bundled with Tomcat native binaries for Windows operating systems running on different CPU architectures. Note: Use of the JSR-356 Java WebSocket 1.0 implementation requires Java 7. Note: If you use the APR/native AJP or HTTP connector you *must* upgrade to version 1.1.29 or later of the APR/native library. Downloads: http://tomcat.apache.org/download-70.cgi Migration guides from Apache Tomcat 5.5.x and 6.0.x: http://tomcat.apache.org/migration.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
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-Encodinggzip/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-Encodinggzip/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-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
Re: Compressed SVG support (*.svgz) in Tomcat
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-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
Re: Compressed SVG support (*.svgz) in Tomcat
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-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
Re: Compressed SVG support (*.svgz) in Tomcat
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
Re: Compressed SVG support (*.svgz) in Tomcat
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
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-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
Re: Compressed SVG support (*.svgz) in Tomcat
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-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
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Compressed SVG support (*.svgz) in Tomcat
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
Re: Compressed SVG support (*.svgz) in Tomcat
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 extensionsvgz/extension mime-typeimage/svg+xml/mime-type encodinggzip/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-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