Add additional close statuses in ManagedWebSocket

[IDisposable]

Add ServiceRestart (1012), TryAgainLater (1013), and BadGateway (1014) to the list of WebSocketCloseStatus values and allow them to be used as valid WebSocket close statuses so we don't reject the close and discard the status description by adding them to the private IsValueCloseStatus method switch statement declaring them as valid true.

Fixes #82602

Description

The current implementation of ManagedWebSocket explicitly declares some WebSocketCloseStatus values as "acceptable" reasons to close the socket. For those, the information status description is extracted and made available. For all other values, the close status is rejected and the closing information is discarded.

This means that things like BadGateway (1014), or ServiceRestart (1012), or TryAgainLater (1013) will be declared invalid by ManagedWebSocket.IsValidCloseStatus and thus not handled cleanly even though they could happen after a web socket is completely setup. These codes are documented here as valid server-initiated close reasons.

Customer Impact

Lost information and ragged closing of a web socket when a server-side or proxy closes because of any of the previously rejected values:

• ServiceRestart = 1012 // indicates that the server / service is restarting.
• TryAgainLater = 1013 // indicates that a temporary server condition forced blocking the client's request.
• BadGateway = 1014 // indicates that the server acting as gateway received an invalid response

This codes are documented here and here as IANA registered and in the Mozilla docs

Regression

No

Testing

Added test cases for all three to new WebSocketCloseTests.cs file with no regressions in current tests.

Risk

This does not change the public enum of WebSocketCloseStatus as we don't want to invoke public review and the values are not mentioned in the RFC.

Package authoring signed off?

N/A

[ghost]

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

Issue Details

---

Add ServiceRestart (1012), TryAgainLater (1013), and BadGateway (1014) to the list of WebSocketCloseStatus values and allow them to be used as valid WebSocket close statuses so we don't reject the close and discard the status description by adding them to the private IsValueCloseStatus method switch statement declaring them as valid true.

Fixes Issue #82602

Description

The current implementation of ManagedWebSocket explicitly declares some WebSocketCloseStatus values as "acceptable" reasons to close the socket. For those, the information status description is extracted and made available. For all other values, the close status is rejected and the closing information is discarded.

This means that things like BadGateway (1014), or ServiceRestart (1012), or TryAgainLater (1013) will be declared invalid by ManagedWebSocket.IsValidCloseStatus and thus not handled cleanly even though they could happen after a web socket is completely setup. These codes are documented here as valid server-initiated close reasons.

Customer Impact

Lost information and ragged closing of a web socket when a server-side or proxy closes because of any of the previously rejected values:

• ServiceRestart = 1012 // indicates that the server / service is restarting.
• TryAgainLater = 1013 // indicates that a temporary server condition forced blocking the client's request.
• BadGateway = 1014 // indicates that the server acting as gateway received an invalid response

This codes are documented here and here as IANA registered and in the Mozilla docs

Regression

No

Testing

Added test cases for all three to new WebSocketCloseTests.cs file with no regressions in current tests.

Risk

This does not change the public enum of WebSocketCloseStatus as we don't want to invoke public review and the values are not mentioned in the RFC.

Package authoring signed off?

N/A

Author:	IDisposable
Assignees:	-
Labels:	area-System.Net, community-contribution
Milestone:	-

[IDisposable]

This replaces #83713

[IDisposable]

@wfurt and @CarnaViire I have redone this without the public enum change. Let me know if there's a better test (I don't know the WebSockets protocol at all, so I didn't build up native packets, sorry).

[wfurt]

LGTM. thanks @IDisposable

We could make the extra codes private static const inside of ManagedWebSocket.cs but I don't have strong feelings about it. The extra comment seems sufficient to me.

[IDisposable]

That's an interesting idea @wfurt. Could/would it be an internal enum or bundle of static const int values in an adjacent .cs file be more appropriate since we need the constants in both ManagedWebSocket and in the test? I've not been into the runtime code until very recently so not sure what the running practices are... I could craft it up both ways on a couple branches for comment if desired.

Looks like doing the internal would make the test unable to see the enum, so this is totally not worth-while.

[wfurt]

I would wait for feedback from others...

[IDisposable]

Thanks for all the feedback @MartyIX, @wfurt, and @CarnaViire.
I think this ready for another round of feedback or approval.
Thanks for teaching me how to fish!

(not sure if I need to do anything with that needs-author-action, which seems to be caused by me accepting @CarnaViire's suggestions)

[CarnaViire]

Could you please update your branch to the current main @IDisposable ? I saw build failures that seem to be caused by branch being out of date

[IDisposable]

I've addressed all the PR comments and rebased to current main, but it won't build on my machine anymore... doing a Full build now to see if things will work, but figured I could push up and let the CI try,

I get this when building the .SLN in the directory (worked before today):

Error	MSB4018	The "Microsoft.DotNet.ApiCompat.Task.ValidateAssembliesTask" task failed unexpectedly.
System.MissingMethodException: Method not found: 'Void Microsoft.CodeAnalysis.CSharp.CSharpCompilationOptions..ctor(Microsoft.CodeAnalysis.OutputKind, Boolean, System.String, System.String, System.String, System.Collections.Generic.IEnumerable`1<System.String>, Microsoft.CodeAnalysis.OptimizationLevel, Boolean, Boolean, System.String, System.String, System.Collections.Immutable.ImmutableArray`1<Byte>, System.Nullable`1<Boolean>, Microsoft.CodeAnalysis.Platform, Microsoft.CodeAnalysis.ReportDiagnostic, Int32, System.Collections.Generic.IEnumerable`1<System.Collections.Generic.KeyValuePair`2<System.String,Microsoft.CodeAnalysis.ReportDiagnostic>>, Boolean, Boolean, Microsoft.CodeAnalysis.XmlReferenceResolver, Microsoft.CodeAnalysis.SourceReferenceResolver, Microsoft.CodeAnalysis.MetadataReferenceResolver, Microsoft.CodeAnalysis.AssemblyIdentityComparer, Microsoft.CodeAnalysis.StrongNameProvider, Boolean, Microsoft.CodeAnalysis.MetadataImportOptions, Microsoft.CodeAnalysis.NullableContextOptions)'.
   at Microsoft.DotNet.ApiSymbolExtensions.AssemblySymbolLoader..ctor(Boolean resolveAssemblyReferences)
   at Microsoft.DotNet.ApiSymbolExtensions.AssemblySymbolLoaderFactory.Create(Boolean shouldResolveReferences) in /_/src/Microsoft.DotNet.ApiSymbolExtensions/AssemblySymbolLoaderFactory.cs:line 12
   at Microsoft.DotNet.ApiCompatibility.Runner.ApiCompatRunner.CreateAssemblySymbols(IReadOnlyList`1 metadataInformation, ApiCompatRunnerOptions options, Boolean& resolvedExternallyProvidedAssemblyReferences) in /_/src/ApiCompat/Microsoft.DotNet.ApiCompatibility/Runner/ApiCompatRunner.cs:line 123
   at Microsoft.DotNet.ApiCompatibility.Runner.ApiCompatRunner.ExecuteWorkItems() in /_/src/ApiCompat/Microsoft.DotNet.ApiCompatibility/Runner/ApiCompatRunner.cs:line 49
   at Microsoft.DotNet.ApiCompat.ValidateAssemblies.Run(Func`2 logFactory, Boolean generateSuppressionFile, String[] suppressionFiles, String suppressionOutputFile, String noWarn, Boolean respectInternals, Boolean enableRuleAttributesMustMatch, String[] excludeAttributesFiles, Boolean enableRuleCannotChangeParameterName, String[] leftAssemblies, String[] rightAssemblies, Boolean enableStrictMode, String[][] leftAssembliesReferences, String[][] rightAssembliesReferences, Boolean createWorkItemPerAssembly, ValueTuple`2[] leftAssembliesTransformationPatterns, ValueTuple`2[] rightAssembliesTransformationPatterns) in /_/src/ApiCompat/Microsoft.DotNet.ApiCompat.Shared/ValidateAssemblies.cs:line 90
   at Microsoft.DotNet.ApiCompat.Task.ValidateAssembliesTask.ExecuteCore() in /_/src/ApiCompat/Microsoft.DotNet.ApiCompat.Task/ValidateAssembliesTask.cs:line 127
   at Microsoft.NET.Build.Tasks.TaskBase.Execute() in /_/src/Tasks/Common/TaskBase.cs:line 52
   at Microsoft.DotNet.ApiCompat.Task.ValidateAssembliesTask.Execute() in /_/src/ApiCompat/Microsoft.DotNet.ApiCompat.Task/ValidateAssembliesTask.cs:line 117
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()	System.Net.WebSockets (src\System.Net.WebSockets)	C:\Users\idisp\.nuget\packages\microsoft.dotnet.apicompat.task\8.0.100-preview.2.23107.1\build\Microsoft.DotNet.ApiCompat.ValidateAssemblies.Common.targets	16	

[CarnaViire]

doing a Full build now to see if things will work

Yeah, when you rebase, it's better to rebuild everything from scratch (git clean -xdf and then .\build.cmd clr+libs -rc release), otherwise the old binaries might not be compatible.

[CarnaViire]

LGTM, thanks!

[CarnaViire]

I see that CLA check is stuck (it is a known issue).
I'm going to close and then reopen the PR to see if it helps.

UPD: it helped, but the tests will be re-run.

[CarnaViire]

Test failure is unrelated #83655

[chenxinyanc]

Thanks for the fix! Just curious, will this change get backported to .NET 6 or do I need to switch to .NET 8 to consume the fix?

[CarnaViire]

The chance of a backport is extremely low, unless there's a significant business impact. Given that currently there's only one hit, I assume you would need to switch to .NET 8 @chenxinyanc

[IDisposable]

If, by chance, we do need a backport, I would love to learn the process to do that as well.