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 17:54:53 GMT
On 05/01/2011 17:43, ilya goberman wrote:
> 
> Mark, 
> 1) TCP/IP overhead? Not sure why you got this involved.
Because of with the number of bytes in this use case the TCP overhead is
significant. It significantly alters the % overhead when comparing
chunked and non-chunked. It may or may not alter it enough for you to
change your view on the benefits of non-chunked.

> 2) I am astonished myself, but it is the fact. An example is Android browser: http://code.google.com/p/android/issues/detail?id=13044
Jeez. And I was considering getting an Android phone when my current
contract expires.

> 3) I already requested an enhancement and you rejected it.
I rejected your first set of questions since they were support questions
and I rejected your request to force a HTTP 1.0 response since there are
ways of doing that already.

As I said, an enhancement request to optionally use a non-chunked
response when keep-alive is disabled is - in my view - a reasonable one.

The whole point of directing you to the users list was to have this
discussion on the users list so it is in the user archives for future
reference. Bugzilla should be focussed on fixing specific issues and is
not intended for more general discussion.

Mark

> Thanks
> 
>> Date: Wed, 5 Jan 2011 16:38:20 +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 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
>>
>  		 	   		  


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


Mime
View raw message