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)
-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...
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
-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.
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
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-
-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
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
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
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
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
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
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
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
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.
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
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
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,
-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
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
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
21 matches
Mail list logo
