Runtime: ClientWebSocket not using system proxy settings on Windows

[davidsh]

This appears to be a bug in HttpSystemProxy class used in SocketsHttpHandler. The problem might not be isolated to just ClientWebSocket. But the parser in ParseProxyConfig doesn't seem to be able to handle simple "host:port" strings that are in IE settings.

https://github.com/dotnet/corefx/blob/3ea1a8cf78073491f9532e36a738a7b8be44829a/src/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpSystemProxy.cs#L214

Repro Code:
```c#
//using System;
//using System.IO;
//using System.Net;
//using System.Net.Http;
//using System.Net.WebSockets;
//using System.Threading;

var uri = new Uri("wss://corefx-net.cloudapp.net/websocket/echowebsocket.ashx");
var socket = new ClientWebSocket();
socket.ConnectAsync(uri, CancellationToken.None).GetAwaiter().GetResult();
```

IE Settings example:

I debugged this to the ParseProxyConfig() method. It is getting a value of "localhost:3128". But ends up returning null URIs. So, the proxy is ignored.

[davidsh]

cc: @wfurt

[wfurt]

reopening for 2.1 servicing:

Description
When using control panel or IE to configure HTTP proxy, 2.1 HttpClient cannot parse them correctly.

Customer Impact
On Windows, after upgrading to 2.1, HTTP Proxy configuration no longer recognizes control panel / IE proxy settings.

Regression?
Yes. This is a regression from 2.0

Risk
Low. In HttpProxy if the URL does not have a protocol prefix, it is treated as http. For example "localhost:1234" is treated as "http://localhost:1234/".

[Pilchie]

Thanks for the follow-up. Is this something that we should consider adding to a manual walkthrough script for vendors until we can get better automated coverage here?

[danmosemsft]

No doubt that's one of the options to look at.

[vivmishra]

Approved.

[joshfree]

@wfurt can you please add the 2.1 PR to this issue and close it once you’ve merged the PR? Checkin needs to be completed before Tuesday to make 2.1.4

[wfurt]

It is dotnet/corefx#31367 @joshfree . marked as no-merge

[davidsh]

It is dotnet/corefx#31367 @joshfree . marked as no-merge

@wfurt it was marked as "no-merge" at the time to prevent it from being merged since the branch wasn't ready for 2.1.4 fixes. But @joshfree is now saying it can be merged.

I will remove the "no-merge" flag.

[wfurt]

thanks for clarification @davidsh .

[joshfree]

Thanks all!

[wfurt]

dotnet/corefx#31367 merged

[CIPop]

@wfurt @davidsh @karelz a few servicing questions:

1. is this going to be available in .NET Core 2.1? If yes, is it sufficient to upgrade to the latest SDK?
2. What are the instructions for 3rd parties that did dotnet publish to get the new fix?

/cc @tameraw, @abhipsamisra

[karelz]

It will be part of 2.1.5 release (cc @danmosemsft for confirmation - it was merged on 2018/8/9 into release/2.1 branch - see commit on the PR)

For self-contained apps, you have to republish with 2.1.5.
For apps relying on shared-framework being installed, you need to upgrade to 2.1.5 on the server.
Does it help?