OK, it is fair, thanks.
> Date: Wed, 5 Jan 2011 17:54:53 +0000 > From: ma...@apache.org > To: users@tomcat.apache.org > Subject: Re: How to disable chunked encoding for the Http11NioProtocol > connector. > > 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: ma...@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: ma...@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-unsubscr...@tomcat.apache.org > >>>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>>> > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
