How are you configuring the proxy? (PAC file / Auto Detect / Single proxy / Proxy-per scheme / Bypass list).

Take a look at chrome://net-internals/#proxy

Proxy is configured manually at the Network level in the Device Management / Admin page as shown in the attached screenshot.


chrome://net-internals/#proxy shows:

Proxy server for FTP: 192.168.0.11:8888
Proxy server for HTTP: 192.168.0.11:8888
Proxy server for HTTPS: 192.168.0.11:8888
Proxy server for everything else: socks4://192.168.0.11:8888
Bypass list: 
  <local>

Cheers!

Deleted: Screen Shot 2018-09-25 at 5.40.38 PM.png 76.0 KB

	Screen Shot 2018-09-25 at 5.40.38 PM.png 76.0 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Thanks for the data!

That looks like a problem with the Chrome OS proxy settings UI.

You are expecting that the proxy http://192.168.0.11:8888 will be used, however because it is being configured on a per-scheme basis it is actually going to use socks4://192.168.0.11:8888.

And since you are running an HTTP proxy and not a SOCKS proxy, those connections fail.

I don't have a Chrome Book with me to test at this moment, however try fiddling with how the per-scheme settings are specified.

In particular, can you delete the text fields under the "SOCKS" row?

Should we be treating wss as https for the purposes of choosing a proxy?  Suppose a change like that could cause HTTPS-MitM-ing proxies to fall over.

Or more likely, clear all the 192.168.0.11 entries underneath the "Use this proxy server for all protocols".

The UI should hopefully let you enter it in just the one field and then check the box.

(The problem is http:// and https:// URLs are going to the HTTP proxy you have configured, however ws:// and wss:// are going to the fallback proxy)

It is messy.

PAC sees the URL as ws:// and wss://, and hence can select different proxies based on that scheme. I believe this is how it mostly works across browsers.

However, when using --use-winhttp-proxy-resolver ws:// and wss:// URLs get translated as you note, mainly because WinHTTP barfs on the unknown scheme and hence can't make forward progress.

The system proxy settings UI doesn't offer a way to map ws:// and wss://. Some testing would need to be done to see how they interpret it (on non-ChromeOS platforms), since the expectation is that Chrome would behave similarly.

The easy answer for Chrome OS's UI would be to simply add mappings for ws:// and wss://.

The UI doesn't allow empty fields. I tried clearing the SOCKS field and clearing all fields except the HTTP proxy host. Got the same error on both.

Deleted: Screen Shot 2018-09-25 at 6.32.06 PM.png 42.9 KB

	Screen Shot 2018-09-25 at 6.32.06 PM.png 42.9 KB View Download

Deleted: Screen Shot 2018-09-25 at 6.32.46 PM.png 46.5 KB

	Screen Shot 2018-09-25 at 6.32.46 PM.png 46.5 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@stevenjb@chromium.org could you take a look? This user is unable to set a single HTTP proxy server (that applies to all URLs, including ws:// and wss://)

@mmenke: I will file separate issues for investigating possible ws:// --> http:// style translations.

Additional info: The WebSocket RFC 6455 has this note:

       NOTE: Implementations that do not expose explicit UI for
       selecting a proxy for WebSocket connections separate from other
       proxies are encouraged to use a SOCKS5 [RFC1928] proxy for
       WebSocket connections, if available, or failing that, to prefer
       the proxy configured for HTTPS connections over the proxy
       configured for HTTP connections.

This is implemented here: https://cs.chromium.org/chromium/src/net/proxy_resolution/proxy_config.cc?type=cs&g=0&l=182

In my experience, the manual proxy configuration UI is terrible on all platforms, and I tend to use a proxy.pac when I want to do anything more complex than configure the same proxy for all protocols. However, with Chrome OS we have the opportunity to do something better.

Just a heads up. I changed the settings on the management UI to use a pac file with these contents:

function FindProxyForURL(url, host)
{
    return "PROXY 192.168.0.11:8888; DIRECT";
}


Then tested the WebSockets connection on the device and it worked. 

Cheers!

Another issue I notice with the Chrome OS UI is it is defaulting "SOCKS" to mean SOCKSv4. Can we make this be understood as SOCKSv5?