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.
Agreed. This is somewhat related. I think your analysis of how the proxying works is correct. When using a proxy I think there is little choice but to trust it.
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.
Yes. It seems that this is exactly what is happening. There may be a way to fix this given the current architecture, but moving this functionality outside of the method would be much cleaner.
Mike
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
