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
