I'd like to re-open my initial chunking problem briefly here, and maybe move it
to apache/modules-dev if it ends up not applying here anymore.
If you all remember, I was having the problem of not being able to get my
request response NOT-chunked from my webapps via apache->mod_jk->tomcat.
So our dev team has added a content-length header to our webapp response.
The results below show that chunking was still taking place under normal
circumstances. The only way to get the content length passed through was to
turn gzip/deflate off, which for me isn't an option since if I turn it off,
then the header doesn't get passed to my CDN which means it doesn't go to
end-users which means my bandwidth usage skyrockets.
It seems that's Rainer might be right with regards to his former response below
in that gzip could be suppressing the content length header because of
streaming.
Here would be my question:
If that's true, why wouldn't it do the same for static files? If both a static
file's data and a dynamic webapp's data size is known through the
content-length, what would make one different than the other to cause the gzip
module to behave this way? Assuming that's the cause.
If you guys are confident this no longer relates to tomcat, I'll move my
problem over to the apache lists.
I appreciate your help, if you have any other ideas.
-Tony
1. With gzip on, http/1.1, the response was still coming back chunked, no
content length header (note: compressed bytes is 536)
Date Wed, 15 Jul 2009 16:09:38 GMT
Server Apache
Last-Modified Wed, 15 Jul 2009 16:09:38 GMT
Cache-Control max-age=300, must-revalidate
Expires Wed, 15 Jul 2009 16:14:38 GMT
Vary Accept-Encoding
Content-Encoding gzip
Connection close
Transfer-Encoding chunked
Content-Type text/javascript
Content-Language en
2. With gzip on, http/1.0, the response was not coming back with a chunked
header, but also not coming back with a content-length header (note: compressed
bytes is 536)
Date Wed, 15 Jul 2009 16:09:38 GMT
Server Apache
Last-Modified Wed, 15 Jul 2009 16:09:38 GMT
Cache-Control max-age=300, must-revalidate
Expires Wed, 15 Jul 2009 16:14:38 GMT
Vary Accept-Encoding
Content-Encoding gzip
Connection close
Content-Type text/javascript
Content-Language en
3. With gzip off, http/1.1, the response is not coming back chunked and has a
content length header
Date Wed, 15 Jul 2009 15:59:19 GMT
Server Apache
Last-Modified Wed, 15 Jul 2009 15:59:19 GMT
Content-Length 3444
Cache-Control max-age=300, must-revalidate
Expires Wed, 15 Jul 2009 16:04:19 GMT
Connection close
Content-Type text/javascript
Content-Language en
4. With gzip off, http/1.0, the response is not coming back chunked and has a
content length header
Date Wed, 15 Jul 2009 15:59:19 GMT
Server Apache
Last-Modified Wed, 15 Jul 2009 15:59:19 GMT
Content-Length 3444
Cache-Control max-age=300, must-revalidate
Expires Wed, 15 Jul 2009 16:04:19 GMT
Connection close
Content-Type text/javascript
Content-Language en
-Tony
---------------------------
Manager, IT Operations
Format Dynamics, Inc.
303-573-1800x27
[email protected]
http://www.formatdynamics.com
> -----Original Message-----
> From: Rainer Jung [mailto:[email protected]]
> Sent: Friday, June 12, 2009 3:44 AM
> To: Tomcat Users List
> Subject: Re: chunked encoding
>
> On 12.06.2009 10:43, Markus Schönhaber wrote:
> > Anthony J. Biacco:
> >
> >> Hence the idea about downgrading to http 1.0. But that doesn't get
> me
> >> the content length header still (which in itself is strange),
> >
> > No, it's not strange at all. If the length of the response body is
> not
> > known when the response headers are sent, you obviously can't add a
> > Content-Length header. That has nothing to do with the HTTP version
> used.
>
> ... true, but an HTTP/1.0 client can also just read until the
> connection
> is closed. That's another way of handling content of unknown length.
>
> BTW: IIRC, the OP mentioned mod_deflate compression. It comes last in
> the response handling. I'm not totally sure, how mod_deflate changes
> the
> headers (whether content-length is for the uncompressed or compressed
> size), but I expect mod_deflate to also change content of fixed length
> to chunked encoding, because in general (not small content) it does not
> know the final length in advance. mod_deflate streams, i.e. it doesn't
> first read the full response and then compresses.
>
> Regards,
>
> Rainer
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
