tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ronald Klop <ronald-mailingl...@base.nl>
Subject RE: How to disable chunked encoding for the Http11NioProtocol connector.
Date Wed, 05 Jan 2011 16:01:57 GMT
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 <goberman@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: markt@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
> > 
>                       
> 
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message