713023 - Websockets: don't prefer SOCKS to HTTP proxy until bug 449251 is fixed

Status: RESOLVED FIXED

(Core :: Networking: WebSockets, defect)

Description

[Patrick McManus [:mcmanus]]

rfc 6455 says that a proxy of unspecified type ought to be SOCKS.

but SOCKS proxies are less common than HTTP proxies and the generic windows proxy server config (which firefox will inherit) is probably identifying http proxies - leading to problems with websockets when it is enabled.

we should assume http unless socks is explicitly specified.


" When Firefox 9 adopts the user's system default proxy settings, it appears that it will assume that this:
        [picture]
 
...means that the specified proxy server is willing to be used as a SOCKS proxy. In practice, that’s very rarely the case, and IE/WinINET will not make that assumption. This prevents Firefox WebSockets from being proxied correctly because Firefox attempts to make a SOCKS connection to the specified proxy (some version of the spec suggested preferring SOCKS over other proxy types) and Firefox’s request will hang as the HTTP proxy has no idea what to make of the SOCKS handshake."

Comment 1

[Janusz Dziemidowicz]

I'd like to point out that this bug practically makes WebSocket unusable on Firefox (probably along with #713026). There is no way to determine proxy from JavaScript and HTTP proxy (at least squid 2.x and 3.x) will simply time out when treated as a SOCKS proxy.
I wanted to use WebSocket for XMPP traffic on nk.pl (largest Polish social network), but currently it can be only done with Chrome, Firefox must remain blacklisted due to this issue.
One can visit http://websocketstest.com/ to quickly verify this behavior. When proxy is configured in Firefox, no WebSocket connection will work and it will be reported only after a lengthy timeout.

Comment 2

[Jason Duell]

Janusz,

Can you tell me if both wss:// and ws:// links are broken for you, or just ws://?

Comment 3

[Janusz Dziemidowicz]

I've made a quick retest with Firefox 13 (with squid 3.1.20):
- HTTP proxy configured and "use this proxy server for all protocols" ticked - both ws:// and wss:// don't work as Firefox tries to use SOCKS for both
- HTTP proxy configured, box unticked, no SOCKS proxy - ws:// does not work due to #713026 (Firefox does not use CONNECT and squid does not support WebSocket), wss:// does work (CONNECT is properly used)

Comment 4

[Jason Duell]

Thanks Janusz!  I'm working on bug 713026 now, and will get to this as soon as that one's fixed.

Comment 5

[Jason Duell]

So the root of the problem is that the "set all protocols to use the HTTP proxy" option is broken, and shouldn't be setting the SOCKS settings (see bug 449251).  If I can resolve that soon this bug will be moot (with my fixes for 449251 and bug 713026, all the tests at http://websocketstest.com/ work fine.)

An intermediate option would be to no longer set nsIProtocolProxyService::RESOLVE_PREFER_SOCKS_PROXY on web sockets channels.  This would mess up people who have both HTTP and SOCKS proxies set (web sockets would use the HTTP proxy, contrary to what the spec suggests).  But I suspect this is a smaller population than users who check "use the HTTP proxy for all protocols", who are currently blocked by this bug from using web sockets at all.

Comment 6

[Jason Duell]

When my fix lands for bug 449251 this will be fixed, so dupe-ing

Comment 7

[Jason Duell]

reopening for intermediate fix since bug 449251 is going to be too complicated to land on aurora/beta.

Comment 8

[Jason Duell]

Attachment: v1: turn off RESOLVE_PREFER_SOCKS_PROXY

So this just turns off RESOLVE_PREFER_SOCKS_PROXY for now.  Simple, bulletproof fix that means that users who've got "Use HTTP proxy for all protocols" set will now have working websockets.   The downside is minor: RFC 6455 says useragents are "encouraged" to prefer SOCKS to HTTP proxies, and we won't be doing that for now.   This means that if there are actually folks out there who've manually set both an HTTP proxy and a SOCKS proxy, websockets will prefer HTTP for now.  I suspect that population is either non-existent or tiny, since right now setting both HTTP/SOCKS proxies means that SOCKS never gets used for anything but websockets: I doubt anyone is relying on that behavior.

Comment 9

[Jason Duell]

Comment on attachment 635169 [details] [diff] [review]
v1: turn off RESOLVE_PREFER_SOCKS_PROXY

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e4885e82c29

This patch is a very simple workaround to enable Websockets for users who have "use HTTP proxy for all protocols set" (see bug 449251 for details on root problem).

Risk:  virtually none.  We're just removing a flag, which will cause websockets to prefer HTTP proxies to SOCKS proxies.  The HTTP proxy pathway is much better tested anyway.  The only downside is the (probably nonexistent) population that might somehow be relying on using SOCKS only for websockets and HTTP proxy for everything else.

[Approval Request Comment]
User impact if declined:  Websockets don't work for some users.
String or UUID changes made by this patch: none

My apologies to the drivers for trying to get my fix for 449251 into aurora/beta: this is a much simpler and risk free solution, and I should have gone with it first.

Comment 10

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8e4885e82c29

Comment 11

[Alex Keybl [:akeybl]]

Comment on attachment 635169 [details] [diff] [review]
v1: turn off RESOLVE_PREFER_SOCKS_PROXY

[Triage Comment]
We believe this carries no risk, and we have heard of external user complaints, so approving for Aurora 15 and Beta 14.

Comment 12

[Jason Duell]

https://hg.mozilla.org/releases/mozilla-aurora/rev/07c03ce3989c

https://hg.mozilla.org/releases/mozilla-beta/rev/5d843241a8b3

Comment 13

[Ioana (away)]

Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 (20120724191344)

Without a proxy set, http://websocketstest.com/ shows that everything works fine.

After setting a proxy, websockets for port 90, 443 and 8080 are disconnected. Port 443 SSL websockets stay connected though. The results are the same both when using the proxy server for all the protocols and when only using it for HTTP.

In builds without the fix, when the HTTP protocol is used for all the protocols, port 443 SSL websockets don't work either. If this fix was supposed to fix more, please reopen the bug.

Comment 14

[Jason Duell]

Ioana, Thanks!  The ports besides 80/443 were probably not allowed to CONNECT by your proxy, so that sounds fine.