I see your point. But most clients will keep the application open for hours, so bandwidth saving may be more important than keep-alive. I think disabling chunked encoding is appropriate for the "long running" connections.
Unfortunately, some browsers/ mobile devices have bugs associated with chunked encoding, so disabling it is the only way for these to work properly. > Date: Wed, 5 Jan 2011 17:01:57 +0100 > From: ronald-mailingl...@base.nl > To: users@tomcat.apache.org > Subject: RE: How to disable chunked encoding for the Http11NioProtocol > connector. > > What is the overhead of ending a tcp connection and creating a new one? > Because you are removing the benefits of keep-alive here. > Compare that with sending 6 extra bytes in a IP-packet that you are sending > anyway. > > Ronald. > > > Op woensdag, 5 januari 2011 16:29 schreef ilya goberman <gober...@msn.com>: > > > > > > > > > > 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). > > > > 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. > > > > In fact some browsers have problems detecting connection termination (and > > host of other issues) related to the chunked encoding. > > 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. > > 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 > > > > > > > > > > > > > >
