You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Vjeran Marcinko <vj...@tis.hr> on 2004/11/16 07:15:19 UTC
HTTP1.1 persistent connections
Hi.
I'm using version 2.0.2. Can someone explain me how does HttpClient handle
(timeouted) HTTP1.1 persistent connections ?
Story goes like this : HttpClient makes HTTP request to some remote Tomcat
where server's response doesn't contain "Connection: close" header, thus
connection is stored in pool for later reuse, in other words, connection
keeps being established. As most of the HTTP servers, Tomcat has timeout on
connections (default 20 secs), and closes the connection afterwards since
let's assume it hasn't been used in the mean time. Connection goes into
FIN_WAIT_2 state on Tomcat side, and CLOSE_WAIT on client side since client
doesn't know connection has been closed (needless to say that both of these
states are dangerous). SO, what happens when client wants to perform another
HTTP request to this Tomcat, and reuse this connection. How does it realize
it has been closed by server ? Does it dispose it ?
And one more question, is there some way to force HttpClient to close
connection after each request, regardless of server's response (meaning
Connection header) ? I'm asking this because there are some stupid HTTP
servers out there that don't respond me with "Connection: close" that would
close it, although my HttpClient sends this same header in request.... :-(
Regards,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP1.1 persistent connections
Posted by Oleg Kalnichevski <ol...@apache.org>.
> Hi Oleg.
>
> Thanx for suggestion. Anyway, I think that HttpClient functionality is a bit
> insufficient about this. I was reading HTTP specs, and it seems that any
> HTTP *client* should close connection in these 2 cases :
> 1. When HTTP server returns "Connection: close" header
> 2. or when HTTP request sent by client itself contained "Connection: close"
> header notifying server that connection will be closed after the request. It
> is not said anywhere that server should return this same header in response,
> as like confirmation. They can, but they are not forced to, because they
> expect connection will be closed by client anyway.
>
> HttpClient is compliant about first one, but later is not implemented it
> seems.
>
Vjeran
Please file a bug report and attach excerpts from the relevant RFC(s).
We also happily accept patches, btw
Oleg
> Regards,
> Vjeran
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP1.1 persistent connections
Posted by Vjeran Marcinko <vj...@tis.hr>.
----- Original Message -----
From: "Oleg Kalnichevski" <ol...@apache.org>
To: <ht...@jakarta.apache.org>
Sent: Tuesday, November 16, 2004 10:27 AM
Subject: Re: HTTP1.1 persistent connections
> On Tue, 2004-11-16 at 07:15 +0100, Vjeran Marcinko wrote:
> > And one more question, is there some way to force HttpClient to close
> > connection after each request, regardless of server's response
> > (meaning
> > Connection header) ? I'm asking this because there are some stupid
> > HTTP
> > servers out there that don't respond me with "Connection: close" that
> > would
> > close it, although my HttpClient sends this same header in request....
> > :-(
> >
> >
> The best way of ensuring connection closure is to implement a custom
> connection manager which would force-close upon release
Hi Oleg.
Thanx for suggestion. Anyway, I think that HttpClient functionality is a bit
insufficient about this. I was reading HTTP specs, and it seems that any
HTTP *client* should close connection in these 2 cases :
1. When HTTP server returns "Connection: close" header
2. or when HTTP request sent by client itself contained "Connection: close"
header notifying server that connection will be closed after the request. It
is not said anywhere that server should return this same header in response,
as like confirmation. They can, but they are not forced to, because they
expect connection will be closed by client anyway.
HttpClient is compliant about first one, but later is not implemented it
seems.
Regards,
Vjeran
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: HTTP1.1 persistent connections
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Tue, 2004-11-16 at 07:15 +0100, Vjeran Marcinko wrote:
> Hi.
>
> I'm using version 2.0.2. Can someone explain me how does HttpClient
> handle
> (timeouted) HTTP1.1 persistent connections ?
> Story goes like this : HttpClient makes HTTP request to some remote
> Tomcat
> where server's response doesn't contain "Connection: close" header,
> thus
> connection is stored in pool for later reuse, in other words,
> connection
> keeps being established. As most of the HTTP servers, Tomcat has
> timeout on
> connections (default 20 secs), and closes the connection afterwards
> since
> let's assume it hasn't been used in the mean time. Connection goes
> into
> FIN_WAIT_2 state on Tomcat side, and CLOSE_WAIT on client side since
> client
> doesn't know connection has been closed (needless to say that both of
> these
> states are dangerous). SO, what happens when client wants to perform
> another
> HTTP request to this Tomcat, and reuse this connection. How does it
> realize
> it has been closed by server ? Does it dispose it ?
>
>
Vjeran,
This is an inherent Java problem as there's no reliable way (I/we know
of) to find out the state of an open socket save performing an I/O
operation on it.
Both HttpClient 2.0 and 3.0 will perform a so called 'stale' connection
check prior to reusing the connection to work the problem around. If the
connection is found to be stale connection it will be dropped and a new
connection will be established. In HttpClinent 3.0 one can also
implement a custom idle connections eviction mechanism
> And one more question, is there some way to force HttpClient to close
> connection after each request, regardless of server's response
> (meaning
> Connection header) ? I'm asking this because there are some stupid
> HTTP
> servers out there that don't respond me with "Connection: close" that
> would
> close it, although my HttpClient sends this same header in request....
> :-(
>
>
The best way of ensuring connection closure is to implement a custom
connection manager which would force-close upon release
http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/SimpleHttpConnectionManager.html#136
Cheers,
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org