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
