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-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
