Mailing-List: contact commons-httpclient-dev-help@jakarta.apache.org;
 run by ezmlm
Message-ID: <3E5E24F3.90405@tibco.com>
Date: Thu, 27 Feb 2003 09:47:15 -0500
From: Eric Johnson <eric@tibco.com>
Organization: TIBCO Extensibility
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.2.1) Gecko/20021130
MIME-Version: 1.0
To: Commons HttpClient Project <commons-httpclient-dev@jakarta.apache.org>
Subject: Re: Question about HttpConnection
References: <D6E9B389-49F2-11D7-8A4C-00306557E112@u.washington.edu>
In-Reply-To: <D6E9B389-49F2-11D7-8A4C-00306557E112@u.washington.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Mike,

I think this relates directly to the posting today by Jani Mattsson.  As 
best I understand it, when using HTTPS to connect via a proxy server, 
the connection to the proxy server itself is not encrypted (the CONNECT 
method goes to the proxy server unencrypted).  Only once the connection 
has been established with the proxy server does encryption get thrown 
on.  From that point on, the proxy server doesn't need to see the 
contents of the connection, merely pass the bytes through on an open 
socket.  (Although it occurs to me that proxy servers could launch 
"man-in-the-middle" attacks on the exchange, so HTTPS via a proxy server 
is no more secure than the extent to which you trust your proxy server). 
 Someone who understands proxies better than I might be able to provide 
more info.

Thus, Jani's problem arises, wherein, should a retry become necessary, 
and the connection has been closed by the remote server or the proxy, 
then HttpMethodBase does not do the right thing to reopen the 
connection.  Yet one more reason to move the retry logic - and perhaps 
we cannot afford to wait until after 2.0 final for this one.

-Eric

Michael Becke wrote:

> I found something in HttpConnection that I'm curious about.  I think I 
> may have actually written it, but I am not sure why.  The following 
> code is from HttpConnection.open():
>
>             final ProtocolSocketFactory socketFactory =
>                 (isSecure()
>                     && !isProxied()
>                         ? protocolInUse.getSocketFactory()
>                         : new DefaultProtocolSocketFactory());
>
> Essentially, on open, the connection is only using the protocol socket 
> factory for non-proxied secure connections.  It seems like it should 
> be using the protocol factory for all connections except when proxied 
> and SSL.  Does this sound correct?
>
> Mike
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 
> commons-httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: 
> commons-httpclient-dev-help@jakarta.apache.org
>