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
