tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony J. Biacco" <abia...@formatdynamics.com>
Subject Re: chunked encoding
Date Wed, 15 Jul 2009 17:02:58 GMT
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
abiacco@formatdynamics.com
http://www.formatdynamics.com

> -----Original Message-----
> From: Rainer Jung [mailto:rainer.jung@kippdata.de]
> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message