Re: [Fwd: Re: What about gzip compression ?]

Henri Gomez wrote: Remy ? Henri Gomez wrote: Take a look in jakarta-tomcat-connectors (ie: http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz) jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11 Thanks, found it in t

[Fwd: Re: What about gzip compression ?]

Remy ? --- Begin Message --- Henri Gomez wrote: Take a look in jakarta-tomcat-connectors (ie: http://apache.fastorama.com/dist/jakarta/tomcat-connectors/jk/source/jakarta-tomcat-connectors-jk-1.2.5-src.tar.gz) jakarta-tomcat-connectors\http11\src\java\org\apache\coyote\http11 Thanks, found it in

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

RE: Http Connector / Gzip

-Chad Johnson > > > > -Original Message- > > From: Henri Gomez [mailto:[EMAIL PROTECTED] > > Sent: Monday, October 06, 2003 11:15 AM > > To: Tomcat Developers List > > Subject: Re: Http Connector / Gzip > > > > > > Remy Maucherat a écrit

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : +0 if disabled by default; -1 otherwise. All this stuff is inefficient, as it uses Strings. Ie, we take the byte array we have for the header value, convert it to a String, and then regexp will likely convert it to something

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Could I commit my changes and start working on an optimizing version ? Yes, of course. There's no big rush to start optimizing this ;-) (it's really disabled by default, right ?) Yes, since the restrictedUserAgents and restrictedUserAgents are set t

Re: Http Connector / Gzip

Henri Gomez wrote: Could I commit my changes and start working on an optimizing version ? Yes, of course. There's no big rush to start optimizing this ;-) (it's really disabled by default, right ?) Remy - To unsubscribe, e-mai

Re: Http Connector / Gzip

Well I take my inspiration from what is done in some TC 4.1 Valves... I know ;-) Some problematic stuff went away, though (the various mappers), but some remain. This feature would really need to be seriously optimized, as ideally this would be enabled by default. We could do better as usua

Re: Http Connector / Gzip

Henri Gomez wrote: Remy Maucherat a écrit : +0 if disabled by default; -1 otherwise. All this stuff is inefficient, as it uses Strings. Ie, we take the byte array we have for the header value, convert it to a String, and then regexp will likely convert it to something else to work with it (lik

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims

Re: Http Connector / Gzip

Henri Gomez wrote: Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but ar

Re: Http Connector / Gzip

* List of restricted user agents. */ -protected String[] restrictedUserAgents = null; +protected RE[] restrictedUserAgents = null; /** @@ -281,9 +283,8 @@ /** * List of user agents to not use gzip with */ -protected String[] noCompressionUserAgen

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache

RE: Http Connector / Gzip

--- From: Peter Lin [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 11:29 AM To: Tomcat Developers List Subject: RE: Http Connector / Gzip interesting results. By any chance did you compare it to Perl regexp to see the difference? :) peter --- Chad Johnson <[EMAIL PROTECTED]>

Re: Http Connector / Gzip

Peter Lin wrote: interesting results. By any chance did you compare it to Perl regexp to see the difference? :) That would be interesting indeed :) Do you know what the HTTPd uses, BTW ? Remy - To unsubscribe, e-mail: [EMAIL PR

RE: Http Connector / Gzip

Original Message- > From: Henri Gomez [mailto:[EMAIL PROTECTED] > Sent: Monday, October 06, 2003 11:15 AM > To: Tomcat Developers List > Subject: Re: Http Connector / Gzip > > > Remy Maucherat a écrit : > > > Henri Gomez wrote: > > > >> Hi

RE: Http Connector / Gzip

Some regex benchmark's I ran across: http://tusker.org/regex/regex_benchmark.html -Chad Johnson -Original Message- From: Henri Gomez [mailto:[EMAIL PROTECTED] Sent: Monday, October 06, 2003 11:15 AM To: Tomcat Developers List Subject: Re: Http Connector / Gzip Remy Maucherat a

Re: Http Connector / Gzip

Remy Maucherat a écrit : Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache

Re: Http Connector / Gzip

Henri Gomez wrote: Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache HTTPD server Well, I th

Http Connector / Gzip

Hi to all, What about using regexp in HTTP 1.1 connector to include/exclude browser which could/couldn't use gzip compression ? May be it could be use also to drop to HTTP 1.0 browser which claims to be 1.1 compatible, but are not. CF: Apache HTTPD s

DO NOT REPLY [Bug 21933] - CompressionResponseStream creates Gzip before header

gzilla/show_bug.cgi?id=21933 CompressionResponseStream creates Gzip before header [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RE

DO NOT REPLY [Bug 21933] New: - CompressionResponseStream creates Gzip before header

gzilla/show_bug.cgi?id=21933 CompressionResponseStream creates Gzip before header Summary: CompressionResponseStream creates Gzip before header Product: Tomcat 4 Version: 4.1.24 Platform: All OS/Version: All Status: NEW Severity:

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type [EMAIL PROTECTED] changed: What|Removed |Added Version|4.1.22 |

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 10:49 --- Created an attachment (id=5491) New tested patch. - To unsubscribe, e-mail:

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type --- Additional Comments From [EMAIL PROTECTED] 2003-03-25 10:49 --- Created an attachment (id=5489) New tested patch. - To unsubscribe, e-mail:

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type [EMAIL PROTECTED] changed: What|Removed |Added Keywords||PatchAva

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type --- Additional Comments From [EMAIL PROTECTED] 2003-03-18 00:54 --- Created an attachment (id=5386) Remove the charset from the content type. --

DO NOT REPLY [Bug 18073] - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type --- Additional Comments From [EMAIL PROTECTED] 2003-03-18 00:53 --- Created an attachment (id=5385) Add method to extract the mime type from a content type. Everything before the

DO NOT REPLY [Bug 18073] New: - gzip compression checks for wrong content type

gzilla/show_bug.cgi?id=18073 gzip compression checks for wrong content type Summary: gzip compression checks for wrong content type Product: Tomcat 4 Version: 4.1.22 Platform: All OS/Version: All Status: NEW Severity:

Re: gzip-encoding in TC 4.1.x/5.x

Henri Gomez wrote: Actually, they are both equivalent. I'll see how we could make use ByteChunk with JDK code for now. I've already started experimenting. Thanks to send me a note when code will be available. I'll could add some code to mimic mod_deflate ie : - compress only

Re: gzip-encoding in TC 4.1.x/5.x

Actually, they are both equivalent. I'll see how we could make use ByteChunk with JDK code for now. I've already started experimenting. Thanks to send me a note when code will be available. I'll could add some code to mimic mod_deflate ie : - compress only certain type of mimes (ie only te

Re: gzip-encoding in TC 4.1.x/5.x

Henri Gomez wrote: As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just provide the interfaces. Well, the idea is to be efficient, so: - Have a ByteChunk compress(ByteChunk) method (assuming that giving it an empty chunk means it's the e

Re: gzip-encoding in TC 4.1.x/5.x

ing good will come out of saving $50. Also, if you have only one Tomcat srever, you could use a crossover cable. On production site, a 100 Mb switch + cabling and monitoring cost much more than 50 EUR :) As I tell you, I could try to look for or write a GZIP writer implementation using byte a

Re: gzip-encoding in TC 4.1.x/5.x

r a cluster. Nothing good will come out of saving $50. Also, if you have only one Tomcat srever, you could use a crossover cable. I don't see what you can do to improve Amy's filter performance, as it has to: - be thread safe - use inefficient methods from the servlet API (whic

Re: gzip-encoding in TC 4.1.x/5.x

Did this ZLIB Java implementation could be what you're looking Remy ? http://www.jcraft.com/jzlib/index.html -- To unsubscribe, e-mail: For additional commands, e-mail:

Re: gzip-encoding in TC 4.1.x/5.x

ad safe - use inefficient methods from the servlet API (which create garbage, etc) What could we do so ? - Create a GZIP implementation using byte array - Use it in HTTP 1.1 stack - Use it in JK2 As I tell you, I could try to look for or write a GZIP writer implementation using byte array, just

Re: gzip-encoding in TC 4.1.x/5.x

Henri Gomez wrote: I was planning to add the feature as filters in Coyote HTTP/1.1, but never did, because I wasn't able to find efficient compression code. I suppose something could be put together using the JDK compression IS and OS in the meantime

Re: gzip-encoding in TC 4.1.x/5.x

mpression done in java side, you'll have only 30+30 network use and you know that bandwidth today is more important for IT and ADMINs that CPU/RAM. May be a solution could be to bench and optimize the Amy works on gzip compression filter ? Of course compression may also be present in browser-

Re: gzip-encoding in TC 4.1.x/5.x

ked TCP/IP (ie ajp13 + network). I make some bench on large output streams and even if mod_deflate help by sending to browser smaller responses, it still has to handle the big response caming from tomcat. That's why it could be a real gain to have gzip compression also on the tomcat side, I thi

Re: gzip-encoding in TC 4.1.x/5.x

For JK 2, I think it's fair to say that you should rely on the native webserver capabilities (that's the whole point, I think). Great that you added the support (I thought it had been there from the start, actually). I didn't added support really, just corrected the way we set the content-type i

Re: gzip-encoding in TC 4.1.x/5.x

at. That's why it could be a real gain to have gzip compression also on the tomcat side, I think you'll see real gain with recent browser as soon as response is more than 10k. I hope someone could works on it at the coyote level to make it available for both HTTP 1.1 and JK2 upper layers.

Re: gzip-encoding in TC 4.1.x/5.x

Henri Gomez wrote: I spent some times playing with http compression, using Apache 2.0 mod_deflate together with mod_jk, and it works great (at least with jk 1.2.2). I wonder now if someone, may be Remy, has plan to add it in Catalina 1.x/2.x (or Coyote) to make it available for both HTTP 1.1 and

gzip-encoding in TC 4.1.x/5.x

who want to experiment JK+DEFLATE here is was to add in httpd.conf : --- ... LoadModule jk_module /modules/mod_jk.so LoadModule deflate_module /modules/mod_deflate.so ... # # MOD_DEFLATE # # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have

Re: whitespace jsp stripper, gzip encoding

utlined on the Jakarta web site. http://jakarta.apache.org/site/source.html That way, we can all take a look, and it's easy to integrate if accepted. > Also, I'd like to mod the jsp engine to be able to > gzip the output if the client accepts it. I think this > wouldn

whitespace jsp stripper, gzip encoding

ering what I should do to submit it to the main branch? Also, I'd like to mod the jsp engine to be able to gzip the output if the client accepts it. I think this wouldn't be difficult if I better understood the way the engine works. I expect the hardest part is to determine how to handle dif

gzip

Title: gzip Hi, Right now I can send gzipped output from servlet only. I would like to have this done in JSP too. Is it possible to create an appropriate type of  jspwriter depending on the encoding type of the request. I am willing to work on it. I may need some help in understanding