New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 8 users

Issue metadata

Status: Fixed
Owner:
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
link

Issue 426736: WebSocket connections not using configured system HTTPS Proxy in MacOS

Reported by gustav...@gmail.com, Oct 24 2014

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:36.0) Gecko/20100101 Firefox/36.0

Example URL:
http://www.websocket.org/echo.html

Steps to reproduce the problem:
1. Configure the HTTPS Proxy in the System Preferences of MacOS
2. Try to establish a WebSocket connection

What is the expected behavior?
The connection goes through the configured HTTPS Proxy

What went wrong?
The connection is established directly to the destination WebSockets server and if that direct connection is blocked in a firewall the connection will fail.

Did this work before? N/A 

Chrome version: 38.0.2125.104  Channel: stable
OS Version: OS X 10.9
Flash Version: Shockwave Flash 15.0 r0
 

Comment 1 by mmenke@chromium.org, Oct 24 2014

Labels: -Cr-Internals-Network Cr-Internals-Network-Proxy Cr-Blink-WebSockets

Comment 2 by cbentzel@chromium.org, Oct 24 2014

Quick question: Do http requests also go through the proxy? Want to make sure this is a websocket-specific issue instead of a general proxy issue.

Comment 3 by gustav...@gmail.com, Oct 24 2014

HTTP requests are going through the proxy and working fine

Comment 4 by cbentzel@chromium.org, Oct 25 2014

Cc: tyoshino@chromium.org
A net-internals trace may help here then. 

http://dev.chromium.org/for-testers/providing-network-details

Thanks for the prompt responses!

Comment 5 by tyoshino@chromium.org, Oct 27 2014

Owner: ricea@chromium.org
Adam, please take a look.

Comment 6 by ricea@chromium.org, Oct 27 2014

Labels: OS-Linux
Status: Assigned
It's completely broken. Manually configured HTTP and HTTPS proxies are ignored for WebSockets. Confirmed on Linux KDE, but I expect other platforms manual configuration is also broken.

I tested proxy support manually, so it may be a regression, but it depends how I tested it. The --proxy-server command-line option does work, for some reason.

PAC-configured proxies and SOCKS proxies do work.

This seems urgent, so I will try to get a quick fix done and then worry about our lack of automated tests afterwards.

Comment 7 by ricea@chromium.org, Oct 28 2014

Labels: -OS-Mac -OS-Linux OS-All
Confirmed on Chrome OS and Windows. I have a fix in progress at crrev.com/678003002

Comment 8 by gustav...@gmail.com, Oct 29 2014

1) Is there any type of proxy support for WebSockets in Windows that is not broken?  I'm asking because we have some users that have reported it working under Windows (they could be wrong or be a very specific setup).

2) Can you let us know when the patch is available for testing in Canary?

Comment 9 by ricea@chromium.org, Oct 29 2014

gustavogb, fortunately the impact is small on Windows because the "use same proxy for all protocols" checkbox, which is on by default, causes Chrome to bypass the protocol mapping which has the problem.

Automatic proxy detection should work on all platforms, although there is a small change in behaviour: previously if the proxy.pac or wpad.dat file failed to return a proxy for the real URL "ws://example.com/path", Chrome would try again with the fake URL "https://example.com/path". I expect that configurations relying on this behaviour are extremely rare, but if they exist, they will stop working.

I can't give an ETA for a fix, but hopefully soon.

Comment 10 by bugdroid1@chromium.org, Oct 30 2014

Project Member
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bec9560de247f82410abe2ed1741bccdb9ee7dc5

commit bec9560de247f82410abe2ed1741bccdb9ee7dc5
Author: ricea <ricea@chromium.org>
Date: Thu Oct 30 05:05:07 2014

Correct manual proxy selection for WebSockets.

When an HTTPS and/or HTTP proxy was manually configured, WebSocket
connections were mistakenly going direct to the origin server.

According to RFC6455, WebSocket connections should prefer SOCKS proxies,
then HTTPS, then HTTP proxies in that order. Fix the behaviour when
proxies are manually selected to match.

BUG= 426736 
TEST=net_unittests, manual

Review URL: https://codereview.chromium.org/678003002

Cr-Commit-Position: refs/heads/master@{#302037}

[modify] https://chromium.googlesource.com/chromium/src.git/+/bec9560de247f82410abe2ed1741bccdb9ee7dc5/net/proxy/proxy_config.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/bec9560de247f82410abe2ed1741bccdb9ee7dc5/net/proxy/proxy_config.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/bec9560de247f82410abe2ed1741bccdb9ee7dc5/net/proxy/proxy_config_unittest.cc

Comment 11 by ricea@chromium.org, Oct 31 2014

Status: Fixed
The patch is available for testing in Canary version 40.0.2205.0.

A workaround that can be used with the stable version is to write a proxy.pac file that is equivalent to the manual configuration that you would like to use, and then configure Chrome to use that. For example:

function FindProxyForURL(url, host) {
  if (url.substring(0,5) == "http:" || url.substring(0,4) == "ftp:") {
    return "PROXY caching-proxy:3128";
  } else {
    return "PROXY https-proxy:8080";
  }
}

Comment 12 by amineer@chromium.org, Nov 7 2014

Labels: Merge-Approved
merge approved for m39 branch 2171

Comment 13 by bugdroid1@chromium.org, Nov 8 2014

Project Member
Labels: -Merge-Approved merge-merged-2171
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/07620c32441e264cf108943282536d8b41fca248

commit 07620c32441e264cf108943282536d8b41fca248
Author: Adam Rice <ricea@chromium.org>
Date: Sat Nov 08 11:10:21 2014

Correct manual proxy selection for WebSockets.

When an HTTPS and/or HTTP proxy was manually configured, WebSocket
connections were mistakenly going direct to the origin server.

According to RFC6455, WebSocket connections should prefer SOCKS proxies,
then HTTPS, then HTTP proxies in that order. Fix the behaviour when
proxies are manually selected to match.

BUG= 426736 
TEST=net_unittests, manual
R=eroman@chromium.org

Review URL: https://codereview.chromium.org/710623002

Cr-Commit-Position: refs/branch-heads/2171@{#380}
Cr-Branched-From: 267aeeb8d85c8503a7fd12bd14654b8ea78d3974-refs/heads/master@{#297060}

[modify] https://chromium.googlesource.com/chromium/src.git/+/07620c32441e264cf108943282536d8b41fca248/net/proxy/proxy_config.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/07620c32441e264cf108943282536d8b41fca248/net/proxy/proxy_config.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/07620c32441e264cf108943282536d8b41fca248/net/proxy/proxy_config_unittest.cc

Comment 14 by ricea@chromium.org, Nov 13 2014

The fix is now available on the beta channel for Mac, Windows and Linux from version 39.0.2171.62 onwards.

Comment 15 by tkent@chromium.org, Nov 26 2015

Labels: -Cr-Blink-WebSockets Cr-Blink-Network-WebSockets

Sign in to add a comment