Community
Participate
Working Groups
Created attachment 126007 [details] Screenshots When behind a proxy that needs authentication a pserver connection to a cvs repository fails with the exception as shown in the attachment. ProxyHTTP: java.net.unknownhostexception: http
Could you verify the problem still exists with one of the recent I-builds? Please try for example I20090217-2200 from http://download.eclipse.org/eclipse/downloads since proxy support went through serious changes during current development cycle.
This gives exactly the same error with the I20090217-2200 build. Kr David
As a note I can say that it does work in version 3.4.0
David, thanks for the information. I'll try to investigate the problem during 3.5M6.
David, what kind of proxy do you have problem connecting to? And what authentication scheme does the proxy server uses (basic, digest, NTLM)?
Hi, We have a standard HTTP proxy over port 8080 with basic authentication. Kr David
Got it, please provide you proxy configuration. This can be found at Window > Preferences > General > Network Connections. I assume that you configured Eclipse not to use proxy with SOCKS as you wish to connect to CVS directly. Right? I'm mainly interested whether Native provider is used and what settings it manages to get from the OS. Does any entry shows in error log when message box with error is shown?
Created attachment 127327 [details] Proxy settings As requested the Eclipse proxy settings
Also the error log is empty, the only thing I get is the popup as provided in the attachment. Kr David
As a workaround please disable entry for SSL proxy. This entry is used when connecting to CVS and SOCKS proxy isn't set. Please see bug 181320 for related discussion. I'm still investigating how to properly address the problem.
Hi, Indeed I don't get that popup anymore when removing the SSL proxy. But, now I get a timeout on the connection, it seems that it is not going through the proxy now. Kr David
(In reply to comment #11) > Hi, > > Indeed I don't get that popup anymore when removing the SSL proxy. > But, now I get a timeout on the connection, it seems that it is not going > through the proxy now. > > Kr > David > Given your settings, do you want to access a CVS sever directly or through a proxy? Since you have HTTP proxy in your environment and you didn't entered settings for SOCKS proxy I assume you want a direct CVS connection. What happens now is that during establishment of pserver connection HTTPS proxy setting is used (but only when SOCKS setting is empty). That's why if you clear HTTPS setting the connection is made directly.
Hi, OK I understand, but a direct connection is not possible, it would need to go over the proxy, also for CVS. In eclipse 3.4.0 this was working (probably because it used the SSL proxy). I've no clue on what to fill in in the socks proxy. If I use the same one as http I obviously get the same popup with the error. What I currently don't understand is that it works in Eclipse 3.4.0 and not in 3.4.1 using the same settings. Kr David
Could you contact your IT department and ask for exact settings for SOCKS proxy server? Then please enter them in SOCKS field and check if it works. I'm sorry to bother you but I don't have access to SOCKS proxy sever with authentication at the moment.
Hi, Apparently we don't have a socks proxy over here :( Kr David
So, using Eclipse 3.4 it's possible to access CVS using pserver via HTTP proxy. And using Eclipse 3.4.1 it fails. Or has your environment changed? AFAIK HTTP proxy uses HTTP headers to forward traffic so it should be impossible for the server to forward sockets connections. Could you ask IT department how you can access a CVS server in your network configuration? Not sure what the actual problem in your case is.
Yes, When using eclipse 3.4 if works, using 3.4.1 is fails. No configuration changed, I've both Eclipse versions on my machine, so it is easy to compare :) My colleague next to me, can also mimic the same behavior, but he switched back to version 3.4 because of that problem. In our network configuration all outbound connections are blocked, unless you go via the proxy which has websense installed. Kr David
David, I configured FreeProxy to require credentials for SOCKS proxy and instructed Eclipse to provide them. Everything works fine in 3.4 and 3.4.1 as well. Could you go to "C:\Documents and Settings\<user_name>\.eclipse\org.eclipse.equinox.security" and delete the file in it (you can clear whole .eclipse folder)? It will erase all the credentials. Then please launch a fresh installation of 3.4.1 on a fresh workspace and provide your credentials in Eclipse preferences page. I'd like to make sure that 3.4.1 is broken, not some entry in the file that is shared across configurations.
Hi, This gives exactly the same behavior. Note that we don't have a SOCKS proxy, and that we never filled in a value for it. Is there anything else I can verify? Kr David
(In reply to comment #19) > <text deleted/> > Note that we don't have a SOCKS proxy, and that we never filled in a value for > it. > Is there anything else I can verify? > <text deleted/> First of all thanks for your help so far. I'm sorry to bother you but it's impossible to reproduce the problem in my environment. I have no problem using FreeProxy configured for SOCKS and authentication. I also have no problem making direct connections to the CVS server. I'm a little bit confused about your environment. How can you don't have SOCKS proxy while all not proxied connections are blocked? In such case it would't be possible to reach the CVS in any case, right? I'll take a look at all bugs that were fixed from 3.4 to 3.4.1 in the proxy related code. Maybe this will help a bit. And to be honest, the best way to find the cause would be using a packet analyzer (like WireShark, it's GPL) or to debug the code in your environment. If you're willing to help I can send you a separate note with some directions. Also, not filling the value for SOCKS proxy doesn't cause SOCKS connections to be direct. As stated in bug 181320 if SOCKS entry is empty there is a fall back that causes HTTPS entry to be used.
Hi, Let me say that I'm confused too :) We never entered any value for the socks proxy, since we don't have that. We only added the proxy with authentication in the HTTP and SSL boxes. In 3.4 we can connect to CVS using these values (so no SOCKS value entered) In 3.4.1 we get the popup with the error. I've no clue how 3.4 is able to connect to that CVS server. It probably uses the SSL server for that. Now in 3.4.1 that seems to give an error. Maybe the URL of the proxy gets wrongly parsed and isn't stripping off the http:// part of the URL? I'm ready to help you out, so you can always send me directions :) Kr David
Created attachment 128021 [details] Modified org.eclipse.team.cvs.core from Eclipse 3.4 This is a modified version of org.eclipse.team.cvs.core that adds changes made by bug 232982 on the top of Eclipse 3.4. This attachment is to narrow the problem in David's environment.
Thanks to a few debugging sessions with David (via email :-) we found the cause of the problem. Actually two different behaviours were observed using the same versions of Eclipse. It was configuration that caused the problem. To summarize, prefixing SSL proxy with HTTP (in this case "http://autoproxy.axa.be") causes CVS connections to fail. According to this I found three potential resolutions of the problem: a. disable the fall back to use SSL proxy entry in case SOCKS proxy is not specified (see bug 181320); b. validate entries to be entered without type (David's suggestion); c. leave the thing as it is (probably generating defect from users). I'd go for the option a because with the fall back it is impossible Eclipse to use SSL proxy but make SOCKS connections directly. I can imagine a case where such configuration would be necessary (remote debugging in the internal network, access to internal CVS servers and so on). However such a change would break clients migrating to newer versions. They would have to specify SOCKS proxy setting explicitly. If we find this a stopper, I'd go for option b. What do other think? CCing Atsuhiko and setting target milestone to 3.5 M7.
(In reply to comment #23) > <text deleted/> > I'd go for the option a because with the fall back it is impossible Eclipse to > use SSL proxy but make SOCKS connections directly. I can imagine a case where > such configuration would be necessary (remote debugging in the internal > network, access to internal CVS servers and so on). However such a change would > break clients migrating to newer versions. They would have to specify SOCKS > proxy setting explicitly. > <text deleted/> In such case a migration patch could be provided. When switching to Eclipse 3.5 we could rewrite SSL proxy to SOCKS proxy field to make it visible for user. At the same time an internal flag sslProxyMigratedToSocks could be set to avoid such rewrites in the future. That keeps clients working and makes them informed:)
Created attachment 128362 [details] Patch_v01 And the winner is ... option b from comment 23 :-) I decided to go for validation and leave the fall back policy for now since removing it wouldn't actually resolve this bug. It would just make such problems easier to discover. Szymon, please have a look if you got a minute.
Patch_v01 released to HEAD.
