tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nishant Kumar <nishant.ku...@itellix.com>
Subject persistent connection
Date Wed, 24 Mar 2004 05:00:13 GMT
hi,
	i had a small query regarding persistant connection implementation in
tomcat.

the situation is as such..

i am having axis deployed within tomcat to answer my webservice calls.
there is a client which is using the same connection to execute many web
service call till it gets a "Connection:Close" header, after which it
stops using this connection. in the ideal situation there is no need for
tomcat to close the connection (this is what weblogic does) but may be
this is done to prevent DOS attack.

anyway that is not the problem. the problem is that when the response
has the Connection:Close header, it doesn't have either Content-Length
or Transfer-Encoding:chunked, which i think it should have. the .Net
server has the same. rfc2616 is ambiguous about it.

here is the point from rf2616

In order to remain persistent, all messages on the connection MUST have
a self-defined message length (i.e., one not defined by closure of the
connection), as described in section 4.4.

see within section 8.1
http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1

this may mean that if you are using persistant connection then you
should always have length header (content-length or chunked encoding).

this may also mean that till you wish to keep connection persistant you
should have length. by this one may not have the length header in the
response with connection close header as one no more intends to keep the
connection persistent.

the second one is the one which tomcat is using. wouldn't it be nice if
you have the length headers too with the connection close header. this
way the client doesn't have to do anything special for a response with
connection close header other than not using the connection again.

i am also attaching the sample response in the two case from tomcat. one
with connection close header and another without connection close
header. this has been captured using ngrep.

thanks,
nishant.
-- 
Nishant Kumar <nishant.kumar@itellix.com>
itellix

Mime
View raw message