-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Fix IIS outofprocess to remove WebSocket compression handshake #58846
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
// WinHttp does not support any extensions being returned by the server, so we remove the request header to avoid the server | ||
// responding with any accepted extensions. | ||
pRequest->DeleteHeader("Sec-WebSocket-Extensions"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm assuming this is fine even if the header doesn't exist?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The doc comments don't discuss it, but looking at the code it seems to check for existence internally. Also, the non-compression websocket tests should cover that scenario.
/backport to release/9.0 |
Started backporting to release/9.0: https://github.com/dotnet/aspnetcore/actions/runs/11826616953 |
Fixes https://github.com/dotnet/AspNetCore-ManualTests/issues/2688
Blazor enabled websocket compression by default and it turns out our forwarder in IIS OutOfProcess doesn't support websocket compression. Both the WinHttp and websocket.dll layers (which we use) do not support the compression framing.
The WinHttp layer hard codes sending 0
Sec-WebSocket-Extensions
settings to websocket.dll but since we are just forwarding the client request which might contain a Sec-WebSocket-Extensions header, the server might then return aSec-WebSocket-Extensions
header in the response which will be rejected by websocket.dll due to it expecting 0 extensions from the earlier WinHttp call.So the fix is to just remove the
Sec-WebSocket-Extensions
header from the request (which is effectively what WinHttp did without actually modifying the headers) so the server won't potentially respond with anySec-WebSocket-Extensions
header in the response.Also, did a bunch of test work to move the websocket tests out of just IISExpress and to enable OutOfProcess testing as well.