RE: mod_deflate feature needed
I don't understand why standard mod_deflate functionality won't work. If you violate the specs and muck with content-length, it's not going to work right in a browser, anyhow. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -Original Message- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Wednesday, July 15, 2009 6:40 PM To: modules-dev@httpd.apache.org Subject: mod_deflate feature needed I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. I'd be willing to pay someone here a nominal free to do it privately, if one so wishes to do it. Thanx, -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com
RE: mod_deflate feature needed
We're not violating the specs, we're following them. The HTTP spec states that you should send out a content-length header with the correct trasnfer length, and mod_deflate in this case is not doing that. -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -Original Message- From: Houser, Rick [mailto:houser.r...@aoins.com] Sent: Thursday, July 16, 2009 7:01 AM To: modules-dev@httpd.apache.org Subject: RE: mod_deflate feature needed I don't understand why standard mod_deflate functionality won't work. If you violate the specs and muck with content-length, it's not going to work right in a browser, anyhow. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -Original Message- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Wednesday, July 15, 2009 6:40 PM To: modules-dev@httpd.apache.org Subject: mod_deflate feature needed I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. I'd be willing to pay someone here a nominal free to do it privately, if one so wishes to do it. Thanx, -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com
Re: mod_deflate feature needed
On Thu, Jul 16, 2009 at 00:39, Anthony J. Biaccoabia...@formatdynamics.com wrote: I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. I'd be willing to pay someone here a nominal free to do it privately, if one so wishes to do it. Have you tried placing the JkMount directive inside a Location and using just one argument for JkMount? LocationMatch /examples/* JkMount ajp13_worker SetOutputFilter DEFLATE /LocationMatch In my case it works, I get a compressed response. Here are the relevant response headers: HTTP/1.1 200 OK Date: Thu, 16 Jul 2009 16:28:19 GMT Server: Apache/2.2.11 (Debian) mod_jk/1.2.26 mod_perl/2.0.4 Perl/v5.10.0 Accept-Ranges: bytes ETag: W/1127-1245356448000 Last-Modified: Thu, 18 Jun 2009 20:20:48 GMT Vary: Accept-Encoding Content-Encoding: gzip Transfer-Encoding: chunked Content-Type: text/html As the transfer is chunked, there's no Content-Length but the response is still compressed. Are you constrained not to use chunked transfer? Sorin -- A: Because it reverses the logical flow of conversation. Q: Why is top-posting frowned upon? A: Top-posting. Q: What is the most annoying thing in e-mail?
Fwd: mod_deflate feature needed
Looks like this got lost in the ether ... Begin forwarded message: On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote: I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. That's the wrong approach. Think modular! The right approach is to insert another filter after mod_deflate to do your buffering (and of course note its effect on performance and potential role in a DoS attack). The existing content_length filter would make a startingpoint. Or, better, fix your client to support HTTP, without the need for a Content-Length header. -- Nick Kew
RE: mod_deflate feature needed
I'm not familiar with the CDN acronym. I could be mistaken, but I'm fairly certain that HTTP 1.1 required support for chunked transfer (which implies Content-Length would NOT be required for anything HTTP 1.1 compliant). Additionally, I thought the content-length referenced the contents of the file without taking the content-encoding into account. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -Original Message- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Thursday, July 16, 2009 12:42 PM To: modules-dev@httpd.apache.org Subject: RE: mod_deflate feature needed I can get the compressed content, that's not a problem. My thing is, I'm trying to cache said response at my CDN. The CDN requires a content-length header (among other things) to do this. And with the chunked encoding I'm not getting one (fyi, I'm not doing chunked from tomcat, I'm actually sending the content-length). -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -Original Message- From: Sorin Manolache [mailto:sor...@gmail.com] Sent: Thursday, July 16, 2009 10:37 AM To: modules-dev@httpd.apache.org Subject: Re: mod_deflate feature needed On Thu, Jul 16, 2009 at 00:39, Anthony J. Biaccoabia...@formatdynamics.com wrote: I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. I'd be willing to pay someone here a nominal free to do it privately, if one so wishes to do it. Have you tried placing the JkMount directive inside a Location and using just one argument for JkMount? LocationMatch /examples/* JkMount ajp13_worker SetOutputFilter DEFLATE /LocationMatch In my case it works, I get a compressed response. Here are the relevant response headers: HTTP/1.1 200 OK Date: Thu, 16 Jul 2009 16:28:19 GMT Server: Apache/2.2.11 (Debian) mod_jk/1.2.26 mod_perl/2.0.4 Perl/v5.10.0 Accept-Ranges: bytes ETag: W/1127-1245356448000 Last-Modified: Thu, 18 Jun 2009 20:20:48 GMT Vary: Accept-Encoding Content-Encoding: gzip Transfer-Encoding: chunked Content-Type: text/html As the transfer is chunked, there's no Content-Length but the response is still compressed. Are you constrained not to use chunked transfer? Sorin -- A: Because it reverses the logical flow of conversation. Q: Why is top-posting frowned upon? A: Top-posting. Q: What is the most annoying thing in e-mail?
RE: mod_deflate feature needed
On Thu, 2009-07-16 at 10:20 -0600, Anthony J. Biacco wrote: We're not violating the specs, we're following them. The HTTP spec states that you should send out a content-length header with the correct trasnfer length, and mod_deflate in this case is not doing that. -Tony No it doesn't; it says that 'Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4' Rule 2 of section 4.4 clearly indicates that you must not set it if you are transferring data using the chunked transfer encoding (in fact, any transfer encoding other than 'identity'). It is sub optimal in most use cases to buffer the entire response and gzip encode it, so mod_deflate does the sane thing and so transfers it in chunks. Cheers Tom
RE: mod_deflate feature needed
Sorry, CDN is Content Delivery Network. Akamai, Limelight, etc.. While the CDN supports chunked transfer fine for actually delivering data, to utilize its caching services (which is the whole point of the CDN obviously) it wants the content-length header from my servers. It's stupid, yes, but getting them to change their software to not require this seems very unlikely. The spec seems to state transfer length, not content length. To me that means the size of the actual encoded stream, which would be the compressed size in a gzip state or the uncompressed size in the non-gzip state. -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -Original Message- From: Houser, Rick [mailto:houser.r...@aoins.com] Sent: Thursday, July 16, 2009 10:48 AM To: modules-dev@httpd.apache.org Subject: RE: mod_deflate feature needed I'm not familiar with the CDN acronym. I could be mistaken, but I'm fairly certain that HTTP 1.1 required support for chunked transfer (which implies Content-Length would NOT be required for anything HTTP 1.1 compliant). Additionally, I thought the content-length referenced the contents of the file without taking the content-encoding into account. Thanks, Rick Houser Auto-Owners Insurance Systems Support (517)703-2580 -Original Message- From: Anthony J. Biacco [mailto:abia...@formatdynamics.com] Sent: Thursday, July 16, 2009 12:42 PM To: modules-dev@httpd.apache.org Subject: RE: mod_deflate feature needed I can get the compressed content, that's not a problem. My thing is, I'm trying to cache said response at my CDN. The CDN requires a content-length header (among other things) to do this. And with the chunked encoding I'm not getting one (fyi, I'm not doing chunked from tomcat, I'm actually sending the content-length). -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -Original Message- From: Sorin Manolache [mailto:sor...@gmail.com] Sent: Thursday, July 16, 2009 10:37 AM To: modules-dev@httpd.apache.org Subject: Re: mod_deflate feature needed On Thu, Jul 16, 2009 at 00:39, Anthony J. Biaccoabia...@formatdynamics.com wrote: I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. I'd be willing to pay someone here a nominal free to do it privately, if one so wishes to do it. Have you tried placing the JkMount directive inside a Location and using just one argument for JkMount? LocationMatch /examples/* JkMount ajp13_worker SetOutputFilter DEFLATE /LocationMatch In my case it works, I get a compressed response. Here are the relevant response headers: HTTP/1.1 200 OK Date: Thu, 16 Jul 2009 16:28:19 GMT Server: Apache/2.2.11 (Debian) mod_jk/1.2.26 mod_perl/2.0.4 Perl/v5.10.0 Accept-Ranges: bytes ETag: W/1127-1245356448000 Last-Modified: Thu, 18 Jun 2009 20:20:48 GMT Vary: Accept-Encoding Content-Encoding: gzip Transfer-Encoding: chunked Content-Type: text/html As the transfer is chunked, there's no Content-Length but the response is still compressed. Are you constrained not to use chunked transfer? Sorin -- A: Because it reverses the logical flow of conversation. Q: Why is top-posting frowned upon? A: Top-posting. Q: What is the most annoying thing in e-mail?
RE: mod_deflate feature needed
Yep, I think it got lost nick. I'd go along with the filter idea after deflate if it does what I need. Are you referring to mod_filter based directives such as FilterProvider/FilterProtocol? The client/partner/vendor isn't requiring it to support HTTP, but to support their services. -Tony --- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com -Original Message- From: Nick Kew [mailto:n...@apache.org] Sent: Thursday, July 16, 2009 10:46 AM To: modules-dev@httpd.apache.org Subject: Fwd: mod_deflate feature needed Looks like this got lost in the ether ... Begin forwarded message: On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote: I'm trying to use mod_deflate to compress data coming out of tomcat through mod_jk and need the proper content-length header set for the COMPRESSED data, but can't do this because the data is streamed and sent after the headers are set, therefore we don't know the compressed content-length until after the fact. I'd either like to request a option to enable such a feature where I can have the compressed data buffered, the headers set, and then the data sent. That's the wrong approach. Think modular! The right approach is to insert another filter after mod_deflate to do your buffering (and of course note its effect on performance and potential role in a DoS attack). The existing content_length filter would make a startingpoint. Or, better, fix your client to support HTTP, without the need for a Content-Length header. -- Nick Kew
