Quinta dos Três Rios

2015-04-17 Thread David Law

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?

2014-05-31 Thread David Law

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

2014-01-12 Thread David Law

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

2014-01-02 Thread David Law

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

2013-12-31 Thread David Law

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

2013-12-31 Thread David Law

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

2013-12-30 Thread David Law

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

2013-12-29 Thread David Law

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

2013-12-29 Thread David Law

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

2013-12-29 Thread David Law

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

2013-12-29 Thread David Law

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

2013-12-28 Thread David Law

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

2013-12-28 Thread David Law

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

2013-12-28 Thread David Law

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