Add WebSockets compressions support

[aspnet-hello]

From @vanillajonathan on Monday, September 19, 2016 2:26:50 PM

The WebSocket class does not have support for extensions. Which is part of the rfc6455 standard:
https://tools.ietf.org/html/rfc6455#section-9

It should read the Sec-WebSocket-Extensions HTTP header from the client.

The WebSocket class does not expose a Extensions property.

Copied from original issue: aspnet/HttpAbstractions#711

[aspnet-hello]

From @vanillajonathan on Monday, September 19, 2016 2:30:48 PM

Depends on upstream support in System.Net.WebSockets.

Depends on issue dotnet/corefx#11874.

[aspnet-hello]

From @Tratcher on Monday, September 19, 2016 8:10:27 PM

Did you have any specific extensions you want to use?

[aspnet-hello]

From @vanillajonathan on Tuesday, September 20, 2016 1:36:44 AM

No, this exposes to the server the extension(s) that the client requests.
Then the server have to negotiate with the client and send back which extensions it supports.

Then any extension has to be implemented by the client and the server on top of this which only exposes the requested extension.

[aspnet-hello]

From @Tratcher on Tuesday, September 20, 2016 2:38:29 PM

Note this hasn't been done yet because there has been little interest expressed for any websocket extensions. We're unlikely to add the the property if we don't think it will actually get used.

[0x53A]

Just wanted to say that I am interested in having websocket compression support.

I assume that compression - just like other performance related stuff - is not something people actively express their interest in, until their app becomes too slow.

This would probably a big win for signal-r and a lot of other libraries using websockets.

[Tratcher]

Fyi the runtime prerequisites are tracked by dotnet/runtime#20004

[Tratcher]

A new WebSocket compression API was approved in Runtime for 6.0: dotnet/runtime#31088 (comment)

We'll need to react to this. Bumping out of backlog but keeping it as blocked.

[ghost]

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[Tratcher]

dotnet/runtime#49304 has merged with new compression support. We should pick up a new runtime with the changes shortly.