DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28151>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28151 Proxy tunneling/auth with CONNECT for non-HTTP protocols ------- Additional Comments From [EMAIL PROTECTED] 2004-04-05 16:14 ------- Mike B, Thanks for the clarifications. One question - you mentioned you must use port 443 in order to get http client to use SSL automatically. Is this, more precisely, that if you use 443 as your dst port, HttpClient will use the Protocol's SecureProtocolSocketFactory to add SSL to the underlying Socket created with the DefaultProtocolSocketFactory? If so, then I can use port 443 without actually running SSL provided I specifiy my own No-op SecureProtocolSocketFactory. The reason this is important to me is that my goal is to tunnel jxta through web proxies with hopefully not requiring any admin port opening etc., and many proxies only allow CONNECT to go to 443 or 8443. However, if the above holds, it looks like if I use 443 with a No-op SPSF I still can't avoid the DefaultProtocolSocketFactory. Perhaps HttpConnection could create the initial socket for SSL via the SecureProtocolSocketFactory's non-wrapping create methods (since they do not appear to be used otherwise) - but may break old httpclient using code unless you watched for null and even then some may just throw. Alternatively, if the DefaultProtocolSocketFactory could allow pluggable implementations, then no one's existing code would break. The motivation for this is that jxta for example tries to create Sockets with a timeout whereas the use of the DefaultSocketFactory for 'secure' connections does not. Thx, /Mike --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
