tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya goberman <>
Subject RE: How to disable chunked encoding for the Http11NioProtocol connector.
Date Wed, 05 Jan 2011 15:29:30 GMT

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.

> Date: Wed, 5 Jan 2011 06:14:18 +0000
> From:
> To:
> 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]
> [2]
> [3]
> [4]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message