commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject RE: How to make HttpClient NOT send "Proxy-Connection: Keep-Alive"?
Date Thu, 07 Sep 2006 15:25:04 GMT
On Wed, 2006-09-06 at 06:32 -0700, Karr, David wrote:
> Ok, how do I diagnose that, and is there anything I can do about it? 
> 

David,

Actually, SSL session caching is meant to be a good thing, as it reduces
the overhead of re-opening SSL connections. Why would you want to
disable it?

Oleg

> > -----Original Message-----
> > From: Oleg Kalnichevski [mailto:olegk@apache.org] 
> > Sent: Wednesday, September 06, 2006 2:51 AM
> > To: Jakarta Commons Users List
> > Subject: RE: How to make HttpClient NOT send 
> > "Proxy-Connection: Keep-Alive"?
> > 
> > On Tue, 2006-09-05 at 14:21 -0700, Karr, David wrote:
> > > Sigh.
> > > 
> > > Adding the "Connection: close" header didn't help.  In 
> > fact, I don't 
> > > even see it in Ethereal.  I don't get that.
> > > 
> > > Adding a derived HttpConnectionManager didn't help.  I derived from 
> > > SimpleHttpConnectionManager, just adding a 
> > releaseConnection() method 
> > > that closes the connection.  I added a print statement to 
> > the method 
> > > to make sure it got there.
> > > 
> > > There must be something else that causes the first 
> > connection on the 
> > > thread to be slower than the 2nd-Nth connections.
> > > 
> > 
> > I suspect that something is likely to be SSL session caching.
> > 
> > Oleg
> > 
> > > > -----Original Message-----
> > > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > > Sent: Tuesday, September 05, 2006 11:25 AM
> > > > To: Jakarta Commons Users List
> > > > Subject: RE: How to make HttpClient NOT send
> > > > "Proxy-Connection: Keep-Alive"?
> > > > 
> > > > On Tue, 2006-09-05 at 11:02 -0700, Karr, David wrote:
> > > > > Acknowledged.
> > > > > 
> > > > ....
> > > > > So, is there any way I can convince HttpClient to make the
> > > > connection
> > > > > go away between each test case (between each pair of requests, 
> > > > > that is)?  I figured getting it to not send the "Keep-Alive"
> > > > header would
> > > > > do it, but apparently you're saying that that is necessary
> > > > for SSL to work.
> > > > > 
> > > > 
> > > > This is a whole different story. In order to disable connection 
> > > > persistence you can (1) add "Connection: close" to each 
> > request or 
> > > > (2) implement a custom connection manager (or extend an existing 
> > > > one) and close connections upon their release in the 
> > > > HttpConnectionManager#releaseConnection method
> > > > 
> > > > Hope this helps,
> > > > 
> > > > Oleg
> > > > 
> > > > 
> > > > > > -----Original Message-----
> > > > > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > > > > Sent: Tuesday, September 05, 2006 10:27 AM
> > > > > > To: Jakarta Commons Users List
> > > > > > Subject: RE: How to make HttpClient NOT send
> > > > > > "Proxy-Connection: Keep-Alive"?
> > > > > > 
> > > > > > On Tue, 2006-09-05 at 10:09 -0700, Karr, David wrote:
> > > > > > > Well, the URL I'm going to is using https, but I'm not
> > > > > > doing anything
> > > > > > > specific with SSL in the HttpClient connection.
> > > > > > > 
> > > > > > 
> > > > > > That pretty much explains why you are seeing 
> > "Proxy-Connection:
> > > > > > Keep-Alive" headers with the traffic analyzer. These 
> > headers are 
> > > > > > sent with the HTTP CONNECT method because if the
> > > > connection is not
> > > > > > kept alive you would not be able to tunnel secure connections

> > > > > > through the proxy
> > > > > > 
> > > > > > Hope this helps somewhat.
> > > > > > 
> > > > > > Oleg
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > > > -----Original Message-----
> > > > > > > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > > > > > > Sent: Tuesday, September 05, 2006 9:27 AM
> > > > > > > > To: Jakarta Commons Users List
> > > > > > > > Subject: RE: How to make HttpClient NOT send
> > > > > > > > "Proxy-Connection: Keep-Alive"?
> > > > > > > > 
> > > > > > > > On Tue, 2006-09-05 at 09:12 -0700, Karr, David wrote:
> > > > > > > > > I'm confused.  This seemed like it would work.
 I added 
> > > > > > > > > two subclasses, one called "GetMethodNoKeepAlive",
and
> > > > the other
> > > > > > > > > "PostMethodNoKeepAlive".  I created instances
of those
> > > > > > instead of
> > > > > > > > > "GetMethod" and "PostMethod".  Each of the subclasses
> > > > > > has an empty
> > > > > > > > > "addProxyConnectionHeader" method, except for
a print
> > > > > > > > statement saying
> > > > > > > > > it got there.  I monitored the execution in
> > > > Ethereal.  When it
> > > > > > > > > executed, I saw the print statements execute,
but my 
> > > > > > > > > timing
> > > > > > > > behavior
> > > > > > > > > made it look like it made no difference.  In
my
> > > > > > Ethereal results,
> > > > > > > > > I still see the
> > > > > > > > > "Proxy-Connection: Keep-Alive" when it connects
to the
> > > > > > > > external host.
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > David,
> > > > > > > > 
> > > > > > > > Are you using SSL tunneling by any chance? 
> > > > > > > > 
> > > > > > > > Oleg
> > > > > > > > 
> > > > > > > > > I even tried overriding the 
> > "shouldCloseConnection" method
> > > > > > > > to return
> > > > > > > > > true, in both classes.  Still no effect.
> > > > > > > > > 
> > > > > > > > > > -----Original Message-----
> > > > > > > > > > From: Oleg Kalnichevski [mailto:olegk@apache.org]
> > > > > > > > > > Sent: Tuesday, September 05, 2006 5:00 AM
> > > > > > > > > > To: Jakarta Commons Users List
> > > > > > > > > > Cc: Karr, David
> > > > > > > > > > Subject: Re: How to make HttpClient NOT
send
> > > > > > > > > > "Proxy-Connection: Keep-Alive"?
> > > > > > > > > > 
> > > > > > > > > > On Wed, 2006-08-30 at 15:04 -0700, Karr,
David wrote:
> > > > > > > > > > > This may seem strange, but is it possible
to make
> > > > > > > > > > HttpClient NOT send
> > > > > > > > > > > the "Proxy-Connection: Keep-Alive"
header?
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > David,
> > > > > > > > > > 
> > > > > > > > > > There's no elegant solution to this problem.
The
> > > > only way to
> > > > > > > > > > work the problem around is to subclass method
> > > > classes (such
> > > > > > > > > > as
> > > > > > > > GetMethod,
> > > > > > > > > > PostMethod, and so on) and override the

> > > > > > > > > > HttpMethodBase#addProxyConnectionHeader
method
> > > > > > > > > > 
> > > > > > > > > > Oleg
> > > > > > > > > > 
> > > > > > > > > > > I'm trying to write a test tool to
load test an 
> > > > > > > > > > > outside web
> > > > > > > > > > service,
> > > > > > > > > > > but doing it in a way that is somewhat

> > consistent with
> > > > > > > > an internal
> > > > > > > > > > > application that will be calling that
outside web
> > > > > > service.  My
> > > > > > > > > > > test tool can send the message multiple
times so we 
> > > > > > > > > > > can generate
> > > > > > > > > > statistics
> > > > > > > > > > > on the roundtrip time.  What I first
noticed is that
> > > > > > > > when I send N
> > > > > > > > > > > messages on a thread, the 2nd-Nth message
is faster
> > > > > > > > than the first
> > > > > > > > > > > one.  After examining the protocol
behavior in
> > > > > > > > Ethereal, I noticed
> > > > > > > > > > > that HttpClient appears to be sending
a
> > > > "Proxy-Connection:
> > > > > > > > > > Keep-Alive" 
> > > > > > > > > > > header.  If I modified my test code
to add a
> > > > manual delay
> > > > > > > > > > > (9-10
> > > > > > > > > > > seconds) between each message send,
then the 2nd-Nth
> > > > > > > > > > message timings
> > > > > > > > > > > were about the same as the first one.
> > > > > > > > > > > 
> > > > > > > > > > > I'd prefer not to have that manual
delay between
> > > > > > each message.  
> > > > > > > > > > > For the sake of getting consistent
results, is
> > > > > > there any way
> > > > > > > > > > > to disable the sending of the "Proxy-Connection:
> > > > > > > > Keep-Alive" header?
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > > > > > -
> > > > > > > > > > > To unsubscribe, e-mail: 
> > > > > > > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > > > > > > For additional commands, e-mail: 
> > > > > > > > > > commons-user-help@jakarta.apache.org
> > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > > > > > - To unsubscribe, e-mail: 
> > > > > > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > > > > > For additional commands, e-mail: 
> > > > > > > > > > commons-user-help@jakarta.apache.org
> > > > > > > > > > 
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > > > -
> > > > > > > > > To unsubscribe, e-mail: 
> > > > > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > > > > For additional commands, e-mail: 
> > > > > > > > commons-user-help@jakarta.apache.org
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > > > - To unsubscribe, e-mail: 
> > > > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > > > For additional commands, e-mail: 
> > > > > > > > commons-user-help@jakarta.apache.org
> > > > > > > > 
> > > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > -
> > > > > > > To unsubscribe, e-mail: 
> > > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > > For additional commands, e-mail: 
> > > > > > commons-user-help@jakarta.apache.org
> > > > > > > 
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > > > - To unsubscribe, e-mail: 
> > > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > > For additional commands, e-mail: 
> > > > > > commons-user-help@jakarta.apache.org
> > > > > > 
> > > > > > 
> > > > > 
> > > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > -
> > > > > To unsubscribe, e-mail: 
> > > > > commons-user-unsubscribe@jakarta.apache.org
> > > > > For additional commands, e-mail: 
> > > > commons-user-help@jakarta.apache.org
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > --------------------------------------------------------------------
> > > > - To unsubscribe, e-mail: 
> > > > commons-user-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail: 
> > > > commons-user-help@jakarta.apache.org
> > > > 
> > > > 
> > > 
> > > 
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> > commons-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: commons-user-help@jakarta.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-user-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message