From Bugzilla Helper: User-Agent: Mozilla/4.75 [en] (X11; U; Linux 2.2.14 i686) BuildID: 2000082015 I am behind a Socks 4 firewall. If I set the "Socks proxy" to my Socks 4 server (which works fine with Netscape Communicator, rtelnet, etc.), Mozilla can't connect to sites outside the firewall. The status bar reports, "Document: Done (xxx secs)" and the page is completely blank. Reproducible: Always Steps to Reproduce: Open the Preferences dialog, expand the "Advanced" tab, select "Proxies", select "Manual proxy configuration", enter socks 4 server address in "SOCKS Host", enter "1080" for port. Click "OK". Type a URL that is accessible only via the Socks server. Actual Results: A blank page is displayed and Mozilla reports "Document: Done". Expected Results: The requested page should be displayed. Using tcpdump reveals that Mozilla is not trying to connect to the socks server at all, but rather to connect directly: 10:44:15.394580 maguro.almaden.ibm.com.1983 > www2.Stanford.EDU.www: S 3310948038:3310948038(0) win 32120 <mss 1460,sackOK,timestamp 517514263[|tcp]> (DF) 10:44:18.392885 maguro.almaden.ibm.com.1983 > www2.Stanford.EDU.www: S 3310948038:3310948038(0) win 32120 <mss 1460,sackOK,timestamp 517514563[|tcp]> (DF) 10:44:18.393770 cisco.almaden.ibm.com > maguro.almaden.ibm.com: icmp: host www2.Stanford.EDU unreachable - admin prohibited filter Mozilla reports on the terminal: Entry at index 0 is http://www.stanford.edu/ Document: Done (3.066 secs) Error loading URL http://www.stanford.edu/ Sites inside the firewall work OK; after all, Mozilla is contacting them directly. Quitting and restarting Mozilla doesn't help, and the proxy config settings in ~/.mozilla/default/prefs.js look ok.

Just some info:

Steven Ihde, are you still seeing this in current builds?

I just tested build 2000110108 on Linux. It does now connect to the Socks server instead of directly to the site, but it seems to support only Socks5, not Socks4. With the Socks4 server at my site this resulted in Mozilla hanging for a long time. (I set up a Socks5 server and pointed Mozilla at that and it did work!) From looking at bug 16103 it appears there are no plans to support Socks4 -- is this correct? I believe Socks4 is still much more common. This will undoubtedly cause a lot of confusion and more bug reports -- perhaps the configuration dialog should be changed to say "SOCKS5 Host" instead of "SOCKS Host".

Changed name and verified. This seems like a simple thing to do and will cut down on our incoming bugs. View Steven's comments for possible quick change that will save us a lot of headache down the line.

Bad error in UI description. Low effort, low risk, high return -> mozilla0.9.

Is it time to declare the end to SOCKS V4? Here's my best case for doing so: 1- Communicator never supported SOCKS V5 (to my knowledge) 2- SOCKS V4 is not specified in an RFC. 3- SOCKS V5 is reverse compatible for SOCKS V4. To add SOCKS V4 support, someone has to go back to the Communicator code or start fresh. 4- Most "SOCKS servers" seem to support SOCKS V4 and V5. (I will research this further). 5- Ideally, we need to clean up our story with networking protocols and clearly indicate what we are going to support and what we are going to leave behind. We also need to focus on implementing highly used protocols first.

changed summary

These problems have affected my usage of the product and need to be fixed as a Netscape priority.

Benjamin, how did this prevent you from doing any work? This is not dogfood. I'm converting it to catfood because most of the users who understand socks at all will be affected by this. Gagan, any chance of a quick fix? Could we move this bug to someone who can help since it's only a UI change?

I think this was a dogfood2 (pre-catfood) nomination. nscatfood sounds good.

There is no quick socks4 implementation if thats what you are asking for! Yes at this stage fixing the UI to correctly reflect that we only can handle socks5 seems to be the right thing to do. over to ben

nav triage team: Sounds easy enough, marking nsbeta1+ and adding relnote keyword

helping to reduce ben's nsbeta1+ and nsbeta1 bugs.

moving the milestone to where it belongs, in the milestone field.

Since Communicator had preferences for SOCKS V4, and we now support SOCKS V5, shouldn't this pref change also change the value in prefs.js? There seem to be two ways to implement this: Migrate the curent user_pref "network.proxy.socks" into two values: user_pref "network.proxy.socks4" user_pref "network.proxy.socks5" -OR- Create a new pref just for SOCKS V5 (and leave the old one implicit for V4) user_pref "network.proxy.socks5" By writing SOCKS V5 prefs into the existing entry from Communicator, we go deaf to the SOCKS server if it doesn't support both versions. (the original problem here). Unless someone wants to EOL SOCKS V4, I think we should leave some legacy value behind, someday we might support that value again. Based on this decision, I can write a test case and post it here.

Need reviews. I don't know if I am supposed to touch the l10n directories... Ben: can you split the desire to change split the pref into socks4/5 into a new bug?

Joe, Bug 78119 was sent to prefs-back end.

Use a lowercase v (and no need to make the l10n changes) and r=blake.

The capital "V" is the the proper spelling from what I gather on the NEC site. Personally, I do not care, we already do this wrong in the AIM and the NIM modules ("SOCKS 4" "SOCKS 5"). http://www.socks.nec.com/socksfaq.html

NEC's site is at least inconsistent (it uses both in alternation). However, I suspect there's a rhyme and reason to it...

OK, time to get this sr= and checked in or admit we don't really care...

it's marketings call. I'm just trying to put the info on the table...

To clarify, the caps I don't care. Fixing the version info, I do care. We really have to check this in because there are two standards (V4 and V5) and they do not interoperate. This isn't like HTTP 0.9, 1.0, and 1.1 working seamlessly. Frankly, this protocol was poorly designed and we need to live with it. When we released Communicator 4 (V4) and Netscape Proxy Server (V5) they could not communicate with each other. I got an earful from Sony, Citibank and the like. Does someone in eClient care that can sr=? http://www.packetgram.com/pktg/proxy/socksversion.html

sr=hewitt

r=timeless

nav triage: this would have been nice to have, but its not a netscape beta stopper at this point. moving to mozilla0.9.2.

I'm really confused here. Vishy, this bug has nsbeta1+, it was targeted at 0.9.1 and it has a patch with review and super review. This is a minimal risk, 1 line, wording (exempt from super review) fix that goes to standards compliance and accuracy of information. There is no such thing as SOCKS (that's like saying use MAIL instead of use IMAP mail) and leaving it like this is lying to the user.

checked in.

verified win2k 2001061905

I need to check all plats...

Sure.

cleared old keywords, + testcase (visual check of Prefs dialog in functional test) VERIFIED: Mozilla 0.9.2 all plats.

.