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.
> > Biacco<abia...@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?
> 

Reply via email to