Last Comment Bug 713023 - Websockets: don't prefer SOCKS to HTTP proxy until bug 449251 is fixed
: Websockets: don't prefer SOCKS to HTTP proxy until bug 449251 is fixed
Product: Core
Classification: Components
Component: Networking: WebSockets (show other bugs)
: 11 Branch
: x86_64 Linux
-- normal with 2 votes (vote)
: mozilla16
Assigned To: Jason Duell [:jduell] (needinfo me)
: Patrick McManus [:mcmanus]
Depends on: 449251
  Show dependency treegraph
Reported: 2011-12-22 10:37 PST by Patrick McManus [:mcmanus]
Modified: 2012-07-27 13:39 PDT (History)
11 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

v1: turn off RESOLVE_PREFER_SOCKS_PROXY (1.17 KB, patch)
2012-06-20 19:39 PDT, Jason Duell [:jduell] (needinfo me)
mcmanus: review+
cbiesinger: review+
akeybl: approval‑mozilla‑aurora+
akeybl: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description User image Patrick McManus [:mcmanus] 2011-12-22 10:37:13 PST
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:
...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 User image Janusz Dziemidowicz 2012-03-21 23:03:24 PDT
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 (largest Polish social network), but currently it can be only done with Chrome, Firefox must remain blacklisted due to this issue.
One can visit 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 User image Jason Duell [:jduell] (needinfo me) 2012-06-12 14:54:33 PDT

Can you tell me if both wss:// and ws:// links are broken for you, or just ws://?
Comment 3 User image Janusz Dziemidowicz 2012-06-12 15:39:09 PDT
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 User image Jason Duell [:jduell] (needinfo me) 2012-06-12 23:57:09 PDT
Thanks Janusz!  I'm working on bug 713026 now, and will get to this as soon as that one's fixed.
Comment 5 User image Jason Duell [:jduell] (needinfo me) 2012-06-14 19:14:40 PDT
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 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 User image Jason Duell [:jduell] (needinfo me) 2012-06-19 21:18:12 PDT
When my fix lands for bug 449251 this will be fixed, so dupe-ing

*** This bug has been marked as a duplicate of bug 449251 ***
Comment 7 User image Jason Duell [:jduell] (needinfo me) 2012-06-20 19:32:32 PDT
reopening for intermediate fix since bug 449251 is going to be too complicated to land on aurora/beta.
Comment 8 User image Jason Duell [:jduell] (needinfo me) 2012-06-20 19:39:43 PDT
Created attachment 635169 [details] [diff] [review]

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 User image Jason Duell [:jduell] (needinfo me) 2012-06-22 11:09:31 PDT
Comment on attachment 635169 [details] [diff] [review]

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 User image Ryan VanderMeulen [:RyanVM] 2012-06-23 05:46:30 PDT
Comment 11 User image Alex Keybl [:akeybl] 2012-06-24 12:12:40 PDT
Comment on attachment 635169 [details] [diff] [review]

[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 13 User image Ioana (away) 2012-07-27 06:49:34 PDT
Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 (20120724191344)

Without a proxy set, 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 User image Jason Duell [:jduell] (needinfo me) 2012-07-27 13:39:31 PDT
Ioana, Thanks!  The ports besides 80/443 were probably not allowed to CONNECT by your proxy, so that sounds fine.

Note You need to log in before you can comment on or make changes to this bug.