Closed
Bug 78119
Opened 24 years ago
Closed 23 years ago
SOCKS - "network.proxy.socks" needs to be version specific.
Categories
(Core :: Networking, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: benc, Assigned: smeredith)
References
()
Details
(Keywords: arch)
networking feature needs help, from bug 50679
Communicator 4 supported SOCKS V4, which was described in the prefs UI as
"Socks". The preference was saved to:
user_pref "network.proxy.socks"
mozilla/NS6.x supports SOCKS V5. The two protocol versions do not have
handshake rules or reverse compatability, so we are completely incompatible
with SOCKS V4 proxy servers (bug 65583).
The prefs UI is going to be updated to reflect the new version "probably the
string "SOCKS V5", but we also need to decide if we are going to change the
prefs 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.
NOTE: NIM doesn't have this problem because it uses a prefs structure that
won't work here (a pair of hostname+port values + a protocol type selector
[SOCKS4 SOCKS5 HTTPS]).
Updated•24 years ago
|
QA Contact: sairuh → benc
isn't the owner of pref the owner of the code that handles proxy support?
Comment 3•24 years ago
|
||
Gagan?
Comment 4•23 years ago
|
||
This is not a preferences-backend bug. Addition or modification of preferences
is up to the module owner(s) using them.
Assignee: bnesse → neeti
Component: Preferences: Backend → Networking
QA Contact: benc → tever
This is a standards implementation and design question.
Can we get a decision by nsbeta1 so this will be working in Netscape 6.5? m0.9.3
is too far away.
Keywords: nsbeta1
Comment 7•23 years ago
|
||
We will need to support both SOCKS V4 and V5 for enterprise customers. We
should at least get this fix in before 6.1 ships, and we will address other
SOCKS V4/V5 support / completeness issues as soon as possible in future
releases. We should implement benc's suggestion using two values, one for each
version.
I don't care which proposal we use, as long as we don't RTM with the current
situation. I think we all want to avoid having connectivity problems with
NS6/eClient and Microsoft servers (which are SOCKS 4 only) if possible.
The prefs UI was fixed already.
Assignee | ||
Comment 9•23 years ago
|
||
If we migrate the curent user_pref "network.proxy.socks" into two values:
user_pref "network.proxy.socks4"
user_pref "network.proxy.socks5"
What do we do with the value of the existing "network.proxy.socks" if it exists?
Do we assume it is a socks 5 value entered via the Mozilla preferences or a
socks 4 value migrated from a version 4.x installation?
Comment 10•23 years ago
|
||
if there is an existing "network.proxy.socks" I think we would be right more
times than not if we assumed it was for Socks V4 prefs and moved them over to
"network.proxy.socks4". Does the prefs UI allow viewing and setting of V4 and
V5 prefs separately?
Assignee | ||
Comment 11•23 years ago
|
||
In the current version, you can only set SOCKS v5 prefs.
Possible answer to my previous question that just occurred to me: copy the
user_pref "network.proxy.socks" to BOTH "network.proxy.socks4"
and "network.proxy.socks5". That seems like the best solution.
All this assumes that we will support SOCKS v4 in the future.
Reporter | ||
Comment 12•23 years ago
|
||
For compatability, there is a good case for leaving "socks" for v4, and then
read-migrating into a "socks5" for v5.
Now that I have stared at this bug for a while, its strikes me as needlessly
literal to create a "socks4" pref that we don't support.
We got into this problem because the SOCKS documentation was non-existent.
Probably a brief paragraph or two (which I can provide), can undo most of the
damage.
Assignee | ||
Comment 13•23 years ago
|
||
Why not leave it at "network.proxy.socks" and add a preference which specifies
v4 or v5?
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•23 years ago
|
||
I am taking ownership of this.
Assignee: neeti → smeredith
Status: ASSIGNED → NEW
Reporter | ||
Comment 15•23 years ago
|
||
That sounds good to me. For manual, we only allow specification of one
hostname/IP for SOCKS, and it is also consistent with our SOCKS implementations
in AIM and NIM.
For PAC, it solves the problem in bug 78176.
In the long run, we might need to actually support the two protocols explicity &
simulatenously, but that would be best implemented via PAC or would require a
wholesale manual config re-write.
Assignee | ||
Comment 16•23 years ago
|
||
I will make this change as part of 65583. There is no point in doing it until then.
Keywords: nsenterprise
Assignee | ||
Comment 17•23 years ago
|
||
Fixed by fix for 65583.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•