tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya goberman <gober...@msn.com>
Subject RE: How to disable chunked encoding for the Http11NioProtocol connector.
Date Thu, 06 Jan 2011 21:17:22 GMT

OK. All I wanted to say is that disabling keepAlive across the board is not necessary. If
keepAlive can be applies to a single response (and to be honest I am not sure it is possible),
it is fine.

I was under impressing that the only way to disable keep alive is globally via: maxKeepAliveRequests="1"
in server.xml

> Date: Thu, 6 Jan 2011 16:08:36 -0500
> From: chris@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: How to disable chunked encoding for the Http11NioProtocol connector.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ilya,
> 
> On 1/6/2011 12:27 PM, ilya goberman wrote:
> > I think what was suggested before is to control this behavior by
> > setting "keepAlive" setting. I would not think this is the right
> > way.
> 
> Er, what's the difference between using "keepAlive setting" and
> "Connection: close"? AFAIK, they are the same thing.
> 
> > I would still want to preserve "keepAlive" functionality for all
> > other requests except "long running comet response".
> 
> Of course. So, you have the client set "Connection: close" (which
> disables keep-alive) and then the configuration Mark proposed causes
> chunked encoding to be avoided.
> 
> > So if it is
> > request for a web page, using keepAlive is fine. Now in order to
> > disable chunked encoding for a particular response, I would propose
> > that a developer would set "Connection:close" header.
> 
> On the server side or from the client side? I'm not sure if Mark was
> thinking client or server. I suppose server would be safer, since the
> server can make the decision and not have to ensure that clients are
> compliant.
> 
> > Using
> > connection "close" implies that closing the connection indicates the
> > end of response and chunked encoding is not necessary in this case.
> 
> So... everyone is happy, then, right? Are we arguing semantics, then?
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAk0mL1QACgkQ9CaO5/Lv0PBxKwCgqjbxMKY5WKqdVLR8Ay9TpA+h
> ojwAmwdQKzXFqiumBd8j40zEgym9NOeR
> =2fnQ
> -----END PGP SIGNATURE-----
> 
> ---------------------------------------------------------------------
> 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