Expose WebSocketMessageFlags in ClientWebSocket

[greenEkatherine]

In #31088 compression support in WebSocket was introduced. There was added WebSocketMessageFlags.DisableCompression flag which is needed to turn off compression i.e. when sending data containing secrets -- it helps to avoid CRIME/BREACH attacks.

However, this flag was added only in WebSocket and not in ClientWebSocket which is supposed to manage messages. We need to expose DisableCompression flag in SendAsync methods as well as it is done for EndOfMessage flag.

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

In #31088 compression support in WebSocket was introduced. There was added WebSocketMessageFlags.DisableCompression flag which is needed to turn off compression i.e. when sending data containing secrets -- it helps to avoid CRIME/BREACH attacks.

However, this flag was added only in WebSocket and not in ClientWebSocket which is supposed to manage messages. We need to expose DisableCompression flag in SendAsync methods as well as it is done for EndOfMessage flag.

Author:	greenEkatherine
Assignees:	-
Labels:	area-System.Net
Milestone:	-

[stephentoub]

I've not quite followed the proposal. ClientWebSocket derives from WebSocket, inheriting all the APIs added there, and its implementation wraps ManagedWebSocket that implements the compression. What is the specific API that would be added to ClientWebSocket?

[greenEkatherine]

@stephentoub we should add SendAsync method that handles DisableCompression flag. Currently we handle only EndOfMessage flag in both ClientWebSocket

runtime/src/libraries/System.Net.WebSockets.Client/src/System/Net/WebSockets/ClientWebSocket.cs

Lines 145 to 149 in 64b3ee4

	public override Task SendAsync(ArraySegment<byte> buffer, WebSocketMessageType messageType, bool endOfMessage, CancellationToken cancellationToken) =>
	ConnectedWebSocket.SendAsync(buffer, messageType, endOfMessage, cancellationToken);
	public override ValueTask SendAsync(ReadOnlyMemory<byte> buffer, WebSocketMessageType messageType, bool endOfMessage, CancellationToken cancellationToken) =>
	ConnectedWebSocket.SendAsync(buffer, messageType, endOfMessage, cancellationToken);

and parent WebSocket

runtime/src/libraries/System.Net.WebSockets/src/System/Net/WebSockets/WebSocket.cs

Lines 56 to 64 in 64b3ee4

	public virtual ValueTask SendAsync(ReadOnlyMemory<byte> buffer, WebSocketMessageType messageType, bool endOfMessage, CancellationToken cancellationToken) =>
	MemoryMarshal.TryGetArray(buffer, out ArraySegment<byte> arraySegment) ?
	new ValueTask(SendAsync(arraySegment, messageType, endOfMessage, cancellationToken)) :
	SendWithArrayPoolAsync(buffer, messageType, endOfMessage, cancellationToken);
	public virtual ValueTask SendAsync(ReadOnlyMemory<byte> buffer, WebSocketMessageType messageType, WebSocketMessageFlags messageFlags, CancellationToken cancellationToken = default)
	{
	return SendAsync(buffer, messageType, messageFlags.HasFlag(WebSocketMessageFlags.EndOfMessage), cancellationToken);
	}

[stephentoub]

Thanks. This isn't about missing API, then, it's a bug. ClientWebSocket should be overriding public virtual ValueTask SendAsync(ReadOnlyMemory<byte> buffer, WebSocketMessageType messageType, WebSocketMessageFlags messageFlags, CancellationToken cancellationToken = default) to forward it to the wrapped ManagedWebSocket's corresponding overload.

[MihaZupan]

Triage: We should fix this in 8.0, looks like we're missing test coverage as well.

[CarnaViire]

Reopening for backport

[karelz]

Fixed in 8.0 (main) in PR #79412, and in 7.0.3 in PR #79547, and in 6.0.14 in PR #79549.