Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (nike.apache.org: domain of goberman@msn.com designates
 65.54.190.77 as permitted sender)
Message-ID: <BAY146-w450340B63DE75711820373DA090@phx.gbl>
Content-Type: multipart/alternative;
	boundary="_4fc29b2c-b3a6-42bf-979d-dc17abd06db1_"
From: ilya goberman <goberman@msn.com>
To: <users@tomcat.apache.org>
Subject: RE: How to disable chunked encoding for the Http11NioProtocol
 connector.
Date: Wed, 5 Jan 2011 15:29:11 -0600
Importance: Normal
In-Reply-To: <4D24B06D.1000804@apache.org>
References: 
 <BAY146-w2175E055462753D2ADB513DA090@phx.gbl>,<4D240C3A.9070806@apache.org>
 <BAY146-w63FF5F3AF0188ABAF4C719DA090@phx.gbl>,<4D249E7C.7090403@apache.org>
 <BAY146-w56259A79A6942C59EE6BC3DA090@phx.gbl>,<4D24B06D.1000804@apache.org>
MIME-Version: 1.0

--_4fc29b2c-b3a6-42bf-979d-dc17abd06db1_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I was thinking more about it. What if Tomcat disables chunked encoding if r=
esponse contains "Connection: close" header.
So in order to disable the encoding the Tomcat application will have to set=
 just one response header.

I think it is a reasonable enhancement to do. If "Connection: close" is not=
 set=2C keep alive functionality is preserved.
Any objections?

> Date: Wed=2C 5 Jan 2011 17:54:53 +0000
> From: markt@apache.org
> To: users@tomcat.apache.org
> Subject: Re: How to disable chunked encoding for the Http11NioProtocol co=
nnector.
>=20
> On 05/01/2011 17:43=2C ilya goberman wrote:
> >=20
> > Mark=2C=20
> > 1) TCP/IP overhead? Not sure why you got this involved.
> Because of with the number of bytes in this use case the TCP overhead is
> significant. It significantly alters the % overhead when comparing
> chunked and non-chunked. It may or may not alter it enough for you to
> change your view on the benefits of non-chunked.
>=20
> > 2) I am astonished myself=2C but it is the fact. An example is Android =
browser: http://code.google.com/p/android/issues/detail?id=3D13044
> Jeez. And I was considering getting an Android phone when my current
> contract expires.
>=20
> > 3) I already requested an enhancement and you rejected it.
> I rejected your first set of questions since they were support questions
> and I rejected your request to force a HTTP 1.0 response since there are
> ways of doing that already.
>=20
> As I said=2C an enhancement request to optionally use a non-chunked
> response when keep-alive is disabled is - in my view - a reasonable one.
>=20
> The whole point of directing you to the users list was to have this
> discussion on the users list so it is in the user archives for future
> reference. Bugzilla should be focussed on fixing specific issues and is
> not intended for more general discussion.
>=20
> Mark
>=20
> > Thanks
> >=20
> >> Date: Wed=2C 5 Jan 2011 16:38:20 +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 15:29=2C ilya goberman wrote:
> >>>
> >>> Mark=2C overhead of chunked encoding can be significant. My typical m=
essage is about 50 bytes and chunked encoding takes 6 bytes per message: ab=
out 12%. I use JSON protocol that is already compressed (the way JSON can b=
e 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 pe=
rfectly valid from HTTP perspective. The end of response is detected by ter=
minating connection on the server side.=20
> >>
> >> 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=2C it will score some poi=
nts for Tomcat if this is addressed by adding a configuration option.
> >>
> >> Sure=2C feel free to request an enhancement to optionally restore the
> >> non-chunked approach when keep-alive is disabled. I'm not sure how muc=
h
> >> interest there will be in implementing it though.
> >>
> >> Mark
> >>
> >>> Thanks
> >>>
> >>>> Date: Wed=2C 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 Http11NioProtoc=
ol connector.
> >>>>
> >>>> On 05/01/2011 05:04=2C ilya goberman wrote:
> >>>>>
> >>>>> Hi=2C
> >>>>> 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 ba=
ndwidth.
> >>>>
> >>>> How significant is the overhead with chunking in your case? I'd expe=
ct
> >>>> it to be pretty small unless only a few bytes are sent at a time (an=
d
> >>>> even then there is the overhead for the packet).
> >>>>
> >>>> Is there any mileage in using compression to reduce bandwidth instea=
d?
> >>>> Issues with flushing compressed output streams [1] were fixed last y=
ear.
> >>>>
> >>>>> The response will have header "Connection: close" with "Content-Len=
gth" 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 se=
e are:
> >>>> - sending an HTTP 1.0 request
> >>>> - declaring a content length
> >>>>
> >>>> It used to be possible to control this by disabling keep-alive but t=
hat
> >>>> was changed back in April last year [2]=2C[3] as a result a discussi=
on on
> >>>> the dev list [4]. If your Tomcat version is old enough=2C you may st=
ill be
> >>>> able to use the disable keep-alive trick.
> >>>>
> >>>> My own view was then=2C and is now=2C that the extra bytes with chun=
king are
> >>>> a price worth paying for the client to be able to determine if the
> >>>> request is complete. That said=2C an option on the connector to reve=
rt to
> >>>> non-chunked responses when keep-alive is disabled for use cases wher=
e
> >>>> 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=3D48738
> >>>> [2] http://svn.apache.org/viewvc?rev=3D931709&view=3Drev
> >>>> [3] http://svn.apache.org/viewvc?rev=3D932913&view=3Drev
> >>>> [4] http://markmail.org/message/pim62zhlw4cii7ve
> >>>>
> >>>> --------------------------------------------------------------------=
-
> >>>> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> >>>> For additional commands=2C e-mail: users-help@tomcat.apache.org
> >>>>
> >>>  		 	   		 =20
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands=2C e-mail: users-help@tomcat.apache.org
> >>
> >  		 	   		 =20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe=2C e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands=2C e-mail: users-help@tomcat.apache.org
>=20
 		 	   		  =

--_4fc29b2c-b3a6-42bf-979d-dc17abd06db1_--