tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <ma...@apache.org>
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
side. 

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
encoding.

> 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.

Mark

> Thanks
> 
>> Date: Wed, 5 Jan 2011 06:14:18 +0000
>> From: markt@apache.org
>> To: users@tomcat.apache.org
>> 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
omitted.
>>> 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] http://issues.apache.org/bugzilla/show_bug.cgi?id=48738
>> [2] http://svn.apache.org/viewvc?rev=931709&view=rev
>> [3] http://svn.apache.org/viewvc?rev=932913&view=rev
>> [4] http://markmail.org/message/pim62zhlw4cii7ve
>>
>> ---------------------------------------------------------------------
>> 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