Everything (docker images, sdk, etc.) is 3.0 preview 5.
Server Side Blazor breaks on App Service on Linux (Preview) for me due to the following errors in blazor.server.js:
WebSocket connection to 'ws://<redacted>.azurewebsites.net/_blazor?id=<redacted>' failed: Error during WebSocket handshake: Unexpected response code: 503
Error: Failed to start the transport 'WebSockets': null
The application works fine locally (windows or linux container) as well as on App Service (Windows).
I believe this issue is due to App Service on Linux not supporting the permessage-deflate WebSockets extension as documented here.
And it seems like blazor is requesting permessage-deflate according to the request headers (client side):
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: Upgrade
Pragma: no-cache
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Version: 13
Upgrade: websocket
I have not confirmed if this is really due to permessage-deflate, I will update this issue when I am done testing.
This may not be an issue with ASP.NET Core itself but I believe there needs to be some mitigation logic and/or documentation (ASP.NET Core side) since this deployment scenario is going to become popular sooner or later.
Thanks for contacting us, @prajaybasu.
In order to use AzureApp service with server-side Blazor, we strongly recommend to use Azure SignalR service, which should automatically take care of this issue.
@mkArtakMSFT what about standard web sockets on App Service i.e. if we aren't using Azure SignalR?
I had similar issues on Node. socket.io was failing on App services run on Linux on an azure cdn hosted domain.
Was able to mitigate this by using the Custom Domain and TLS/SSL settings to link my domain to the app service url instead of setting up an azure cdn on the app service.
Most helpful comment
@mkArtakMSFT what about standard web sockets on App Service i.e. if we aren't using Azure SignalR?