tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: How to disable chunked encoding for the Http11NioProtocol connector.
Date Wed, 05 Jan 2011 16:38:20 GMT
On 05/01/2011 15:29, ilya goberman wrote:
> Mark, overhead of chunked encoding can be significant. My typical message is about 50
bytes and chunked encoding takes 6 bytes per message: about 12%. I use JSON protocol that
is already compressed (the way JSON can be compressed).

You are ignoring the TCP/IP overhead. That is around 40 bytes per
packet. More if you take account of the ACK.

> Using  "Connection: close" with "Content-Length" header omitted is perfectly valid from
HTTP perspective. The end of response is detected by terminating connection on the server

I am well aware of that. I am also well aware that a client that
declares itself HTTP 1.1 capable must support chunked encoding. I am
frankly astonished that a client is so broken it can't handle chunked

> In fact some browsers have problems detecting connection termination (and host of other
issues) related to the chunked encoding.

Which browsers?

> While I understand it is not a Tomcat issue, it will score some points for Tomcat if
this is addressed by adding a configuration option.

Sure, feel free to request an enhancement to optionally restore the
non-chunked approach when keep-alive is disabled. I'm not sure how much
interest there will be in implementing it though.


> Thanks
>> Date: Wed, 5 Jan 2011 06:14:18 +0000
>> From:
>> To:
>> Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector.
>> On 05/01/2011 05:04, ilya goberman wrote:
>>> Hi,
>>> I use NIO HTTP Tomcat connector org.apache.coyote.Http11NioProtocol to implement
Comet streaming to browsers and mobile devices.
>>> I would like to disable HTTP response chunked encoding to reduce bandwidth.
>> How significant is the overhead with chunking in your case? I'd expect
>> it to be pretty small unless only a few bytes are sent at a time (and
>> even then there is the overhead for the packet).
>> Is there any mileage in using compression to reduce bandwidth instead?
>> Issues with flushing compressed output streams [1] were fixed last year.
>>> The response will have header "Connection: close" with "Content-Length" header
>>> Is there a way to do it besides having client send HTTP 1.0 request (that is
not possible in the majority of cases)?
>> Having looked at the relevant source code the only two ways I can see are:
>> - sending an HTTP 1.0 request
>> - declaring a content length
>> It used to be possible to control this by disabling keep-alive but that
>> was changed back in April last year [2],[3] as a result a discussion on
>> the dev list [4]. If your Tomcat version is old enough, you may still be
>> able to use the disable keep-alive trick.
>> My own view was then, and is now, that the extra bytes with chunking are
>> a price worth paying for the client to be able to determine if the
>> request is complete. That said, an option on the connector to revert to
>> non-chunked responses when keep-alive is disabled for use cases where
>> reducing bandwidth is more important than knowing if the response is
>> complete seems reasonable to me.
>> Mark
>> [1]
>> [2]
>> [3]
>> [4]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message