Closed Bug 78176 Opened 24 years ago Closed 21 years ago

PAC: SOCKS return value is not version specific

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: benc, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: arch, helpwanted, relnote)

The orginial PAC description says the following about returning a directive for using a SOCKS server: http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html "SOCKS host:port The specified SOCKS server should be used. " This was a feature available in Netscape Navigator, which supported only SOCKS V4. The problem with this is that mozilla does not support SOCKS V4, and SOCKS V5 support in the client will not be fully interoperable: What should happen within a browser that supports only SOCKS V5? Should this fucntion be updated to explicitly return a SOCKS5 value, or is the modern interpretation assuming that the server supports both versions? At the worst, this may simply be unspecified, and a standards debate can now ensue... At the very least, this needs to be release noted.
Target Milestone: --- → mozilla1.0
qa to me. I'm exchanging mail with a previous implementor of PAC in Communicator. Hopefully they will be able to provide some sage advice.
QA Contact: tever → benc
-->PAC bugs to Jussi
Assignee: neeti → jpm
Keywords: arch
QA Contact: benc → pacqa
Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka
Assignee: jpm → serge
BenC: Any *sage* advice coming yet?
See my comments in bug 78119. This problem may resolve itself based on what happens there.
benc: I don't see how bug 78119 changes anything on the PAC front. PAC still needs a way to find out if a SOCKS proxy is v4 or v5 as the proxy will not be listed in the pref.
If we support only one version of SOCKS (which we do now), FindProxyforURL => SOCKS means it must be a SOCKS V5 connection attempt. We need to add a mechnamism like version checking before we can extend the FindProxyforURL functions and result directives (like addinga SOCKS5 result). In other words, there is no practical solution right now. Once SOCKS V4 support is added, then we need to figure out what version SOCKS connection to make. The current thinking is to implement a SOCKS version selector (all connections to SOCKS servers will be EITHER V4 or V5), so again, PAC will not be making a version decision, it will simply use whatever was set manually.
in light of bug 89928, a SOCKS version selector might not be foward compatible though.
Well SOCKS isn't forward compatibile with itself either. :) The point of that RFE was to break away from most of the proxy cruft we have built up. I should have added in that bug we need extensible connection types, like a way of adding SOCKS V6 support (yes, NEC has given thought to SOCKS futures...) and SSL encrypted proxy connections of all types (SOCKS in SSL, HTTP proxy in SSL, etc).
Suggestion: change to use the keywords "SOCKS4" and "SOCKS5". Deprecate "SOCKS", but default it to mean the same as SOCKS4 so PAC files from 4.x will work correctly. (4.x only works with SOCKS 4, so any PAC file coming from a 4.x environment will be pointing to a SOCKS 4 server.)
As a side note, nsProxyAutoConfig.js doesn't even appear to deal with plain SOCKS return values at the moment.
I'm working on this.
argh, missed RELNOTE train: what do we do here? go direct or go deaf? RELNOTE: "PAC files do not support SOCKS. PAC files that return "SOCKS" directives will be ignored in this version".
Keywords: relnote
We go direct, I believe. This will be easier after bug 89500 is checked in, I think, although its not dependant on it. We need to decide what to use for socks 5. SOCKS5 host:port sounds good to me....
Forget everything else I ever proposed above, I like bbaetz, comments. Hook up SOCKS => SOCKS v4 (it never worked before, so who cares about that?) In the future, extend PAC support of SOCKS directives w/ SOCKS5 (or add versioning to PAC and then do *anything* that would be consistent). I'm marking this as "RESOLVED/LATER".
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
I disagree that this should be RESOLVED. I think it is important to enterprise customers. I believe serge is working on it. I think we need to at least add a "SOCKS5" keyword, and I think adding "SOCKS4" is also important for usability. "SOCKS" should default to SOCKS4 for the reason I mentioned above.
Keywords: nsenterprise
reopening. LATER is obsolete, and its really a trivial fix. The only reason that it wasn't supported before was that we didn't have a socks4 proxy. Now we do.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Is this the bug # for SOCKS4 support in PAC?
No, that would be bug 65583.
Oh, sorry. Yes, this bug covers that.
Steve, there is no point in adding more words unless you update a PAC standard so that it still works with existing PAC files. If nobody is using SOCKS in their PAC files (I don't think there is an actual report of this), then I suppose we can hack away. If people are using this, they have PAC files that have resultant SOCKS directives. It isn't clear to me how you could add new SOCKS directives without possibly confusing older clients.
Good point: changing SOCKS to SOCKS4 would break existing 4.x installations. I'm not sure what adding a SOCKS5 keyword would do to them. Is PAC a standard, or a Netscape thing? Do we need to worry about other kinds of clients?
IE uses it as well (and so does ns4) We could easily add socks4 as a synonym for socks, though. socsk5 compatability isn't an issue because no other pac client supports it, AFAIK
Most customers (like the Sun comments in 53080) want one PAC file for their whole network, and presumably all clients. I suggest we do not extend the contents of PAC for now, especially since we still have not implemented everything up to 4xp. I spoke with Brendan about various PAC arch issues, and without putting words into his mouth, he thought that we should live with the existing structure and then define a whole new "PAC v2" rather than do our version of the "embrace and extend". If someone in eClient marketing wants to see if I'm wrong, it would be a good idea.
Blocks: 79893
Well, we need something. Plugins have a routine which they can call to find out the proxy settings for a given url, and they return it in the same format PAC does. If the user has a socks5 proxy, what should that function return? I really think that defining PACv2 is overkill. SOCKS5 won't do anything on browsers < ns6.0, so its not like a company with socks5 only proxies can use other browsers anyway.
I think we should let this lie for this release. Nobody is saying "we need SOCKS v4 and SOCKS v5 in the same PAC", or "we need SOCKS V5 in PAC." We can do the design work for the next milestone.
But we have to tell plugins something. And if we don't tell them the correct answer, then the quesiton is which lie to use. If we do use the correct answer, then whatever string we pick has to be what PAC will use.
If our goals are to a) get SOCKS version information somehow and b) not break other browsers PAC code, regardless of their ability to connect to a SOCKS5 proxy, then there's another alternative. We let PAC writers create another function that looks like this: function GetSOCKSVersion(proxy) { return "SOCKS5"; // or "SOCKS4", or even just a numerical version... } Then when we see "SOCKS" in the PAC return string, just call into the other function to select version. If GetSOCKSVersion is undefined, assume SOCKS4. If we pass them the name/address of the proxy (as returned by FindProxyForURL), they can support multiple SOCKS versions on different proxies from the same PAC. This will be transparent to browsers that don't explicitly support it, and still let us get the info we need. It feels like an enormous hack, though.
Blocks: 98821
So, can we come to a conclusion? brendan - benc said that you had thoughts on this. See my 2001-08-22 10:49 comment.
How about adding a socks version option in a dialogue so user can select which socks version they have? Programs like ICQ and napster uses that (they don't use the PAC, of course). The default value can be socks 4. This is a hack but will let clients behind a socks 4 firewall connect, at the very least. You don't want to change the PAC much, as sites generally allow users to choose either IE or netscape.
marking nsenterprise-; will be reevaluated for nsenterprise in future release.
Keywords: nsenterprise-
any decision on this? I'll add it to the patch in bug 105335 if SOCKS5/SOCKS4 is decided. Or is this really PAC v2?
Support for a PAC file that can do both versions is probably a PAC2 item, so for now, I don't care how we solve this (SOCKS V4 only, now that that works... -OR- support the selector switch), just as long as we document it.
No longer blocks: 98821
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 (you can query for this string to delete spam or retrieve the list of bugs I've moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
*** Bug 130799 has been marked as a duplicate of this bug. ***
So, um: Can we make a decision on this before 1.0? I still say that adding a type of "SOCKS5" would do. Its not like thats going to conflict with anything, and whilst that directive wouldn't work in ns4, socks v5 doesn't work in ns4 anyway, so no valid configuration would be broken.
You are proposing: SOCKS directive => SOCKS 4 SOCKS5 directive (new type) => SOCKS 5 If so that makes sense, all old PAC will work, new PACs that use SOCKS5 could be created too.
Correct
to default owner
Assignee: serge → new-network-bugs
Status: REOPENED → NEW
okay. the proposal makes sense to me. +helpwanted (now that we know the desired behavior).
Keywords: helpwanted
qa to me. Can I change the relnote to so say that "SOCKS == SOCKS V4"?
QA Contact: pacqa → benc
pac has new ownership...
QA Contact: benc → pacqa
neeti originally targeted this, so I think ownership should revert to her, not new-network-bugs... please retarget and or manually set ownership.
Assignee: new-network-bugs → neeti
Another option for SOCKS besides version is whether to resolve the destination host on the client or to let the proxy server do it. The actual implementation of this is covered by bug 134105. This is possible with SOCKS 5 and with an extension to SOCKS 4 (ie 4a). Initially, I'll just make this setting app-wide, but it seems plausible that someone might have a complex network setup where they will want more control. I just thought I'd leave this note so that any changes to the PAC format being considered can take this into account, as well. btw, my plan for handling this internally was to have an "extra" field of flags, which would have proxy type specific meanings. Perhaps the PAC file could simply do the same. For example: if (...) return "SOCKS foo.com:1080 0"; // resolve names on client if (...) return "SOCKS bar.com:1080 1"; // resolve names on server return "DIRECT"; As long as the port was specified, it would not break our current implementation.
removed jhooker from cc: list
I really don't think we should make a change unless we know that file format would work transparently in all environments. It is better, in my mind, to cram these desires into well-thought out ideas for a future PAC format. We should stay focused on the question raised in this bug, which I think we have answered.
moving neeti's futured bugs for triaging.
Assignee: neeti → new-network-bugs
future
Target Milestone: mozilla1.0.1 → Future
Can I pretty-please have a way to do SOCKS5? SOCKS4 has never been relevant to me, and I need firewall support.
SOCKS5 works, but not via autoproxy - you have to use manual cofig instead. Theres a adio button in the prefs pane for that
Yes; I need it from autoproxy (which is what this bug is, yes?) Since the guts are there for manual proxy, it seems like it should not be hard, and the prior bug discussion of using "SOCKS5" instead of "SOCKS" as the pac return type makes perfect sense to me...
I think the SOCKS directive will do what you want already: select SOCKS 5. SOCKS 4 was implemented in mozilla after SOCKS 5 and autoproxy, and I don't think any of the autoproxy behavior was ever changed to support it.
If my PAC file returns "SOCKS", the only legal socks-oid value, the connection attempted is SOCKSv4, not v5. The code examination I did bore that out, as did this bug, I thought. If someone knows how to make PAC files request SOCKSv5, I'd like to know how.
Steve: I think that SOCKS 4 was hooked into the SOCKS directive at some point for 4xp reasons.
I'm needing this feature and i have some spare time to begin to implement it. What is decided about the new SOCKS5 keyword? I propose the following extension to the SOCKS keyword: SOCKS host:port [v4|v5] this way if the version is not supplied the default Mozilla version is used, in order to get backward compatibility and we can extent it easier for "future?" socks versions (v6?). Maybe pac files writed using this extension will break another browsers, but if you are using a SOCKS5 server, the other browsers will not work anyway. Another posible extension to the PAC spec, is to define a function to retrieve browser capabilities, like a function called getProxyTypeCapabilities, this way scripts can check is this function is defined, if true test if SOCKS5 is supported
I'd prefer to keep the directive format to "TYPE host|IP:port". Although Darin added "SOCKS4" and "SOCKS5" to the IDL, I don't think anyone has found out what they do. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/netwerk/base/public/nsIProxyAutoConfig.idl 66 * proxy-type = "PROXY" | "SOCKS" | "SOCKS4" | "SOCKS5" This bug actually should be verified as having a certain behavior, and then a new bug should be opened on what you are proposing.
http://lxr.mozilla.org/mozilla/source/netwerk/base/src/nsProtocolProxyService.cpp#417 If I'm reading this right... SOCKS will use SOCKS4, which is a good, conservative reading of the PAC spec.
Assignee: new-network-bugs → darin
Keywords: verifyme
QA Contact: pacqa → benc
RESOLVED/fixed. Darin, can you verify my interpretation of the code?
Status: NEW → RESOLVED
Closed: 24 years ago → 21 years ago
Resolution: --- → FIXED
Yes, SOCKS uses SOCKS4. I thought this bug also encompassed the need to be able to somehow specify SOCKS5. To date I have not been able to use SOCKS proxying because SOCKSv5 has always been the only proxy I have available where I need proxying. Surely a whole lot of people have moved from v4 to v5?...and surely configurability is better?...
mass remove verifyme requests greater than 4 months old
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.