Revert Enforce WebSockets Transport for Blazor #36656
Conversation
ghost
added
the
There was a problem hiding this comment.
Changes look good.
@BrennanConroy we're undoing the limitation we added to Blazor Server to only use WebSockets, but changes to SignalR client that added details to the error are left as is.
TanayParikh
added
the
Servicing-consider
|
"Hi TanayParikh. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge. To learn more about how to prepare a servicing PR click here. |
|
/backport to main |
|
Started backporting to main: https://github.com/dotnet/aspnetcore/actions/runs/1246774749 |
|
@Pilchie requesting approval to get this in for RC2. |
|
Approved by me, but needs approval from Tactics for RC2. |
|
Thanks Kevin. This has now been approved by tactics for RC2 (offline). @dotnet/aspnet-build could this please be merged. |
dougbu
deleted the
taparik/revertEnforceWebSocketsTransportsInBlazor
branch
mkArtakMSFT
added
Servicing-approved
|
Have you considered using Server-Sent Events (SSE) as a fallback with a higher priority than long polling? Like long polling, it's plain HTTP so it gets through most proxies. Unlike long polling, it's a properly defined protocol with a spec. |
|
Hi @Daniel15. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Hi @Daniel15. SSE is limited to supporting More details are available here. |
* [release/6.0-rc2] Update dependencies from dotnet/efcore (#36635) [release/6.0-rc2] Update dependencies from dotnet/efcore * [release/6.0-rc2] Handle JsonExceptions in RequestDelegateFactory (#36627) * Handle JsonExceptions like InvalidDataExceptions in RequestDelegateFactory * Don't catch InvalidDataExceptions when reading JSON * [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore (#36651) [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore * Avoid using invalid content type for ValidationProblemDetails (#36618) Co-authored-by: Safia Abdalla <[email protected]> * Update dependencies from https://github.com/dotnet/efcore build 20210917.6 (#36667) [release/6.0-rc2] Update dependencies from dotnet/efcore * Use a fake clock in the test (#36626) Co-authored-by: Chris R <[email protected]> * Update dependencies from https://github.com/dotnet/runtime build 20210917.8 (#36675) [release/6.0-rc2] Update dependencies from dotnet/runtime * [release/6.0-rc2] Throw for invalid TryParse and BindAsync (#36662) * Backport of #36628 to release/6.0-rc2 * Throw for invalid TryParse and BindAsync * nit * use TypeNameHelper * nit Co-authored-by: Brennan <[email protected]> * Update dependencies from https://github.com/dotnet/efcore build 20210917.8 (#36681) [release/6.0-rc2] Update dependencies from dotnet/efcore * Revert Enforce WebSockets Transport for Blazor (#36656) * Revert Enforce WebSockets Transport for Blazor (changes introduced in #34644) * Updated Release JS Files * [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore (#36687) [release/6.0-rc2] Update dependencies from dotnet/runtime dotnet/efcore * Update dependencies from https://github.com/dotnet/runtime build 20210917.25 (#36699) [release/6.0-rc2] Update dependencies from dotnet/runtime * Update dependencies from https://github.com/dotnet/efcore build 20210917.18 (#36701) [release/6.0-rc2] Update dependencies from dotnet/efcore * [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime (#36706) [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime * [Release/6.0-rc2] Fix and test HttpSys delegation (#36698) * Out of proc delegation tests * Troubleshoot IsFeatureSupported * Fix test * Fix formatting * Seperate tests * Cleanup * Fix SLN * Update dependencies from https://github.com/dotnet/efcore build 20210918.7 (#36715) [release/6.0-rc2] Update dependencies from dotnet/efcore * Find inherited TryParse and BindAsync (#36694) Co-authored-by: Brennan <[email protected]> * [release/6.0-rc2] Use minimal APIs for F# project templates (#36660) * [release/6.0-rc2] Retarget DOTNETHOME when installing x64 on ARM64 (#36695) * Retarget DOTNETHOME when installing x64 on ARM64 * Make platform comparison case insenstive * Address feedback * Install x64 registry keys to different path on ARM64 machine Co-authored-by: Eric StJohn <[email protected]> * Pin analyzers that ship in the SDK (#36690) (#36754) * Pin analyzers that ship in the SDK (#36690) * Pin analyzers that ship in the SDK ASP.NET Core produces a few analyzer assemblies that are shipped as part of the .NET SDK. These analyzers are added to web projects targeting 3.1 and newer. In 6.0, we (unintentionally) bumped the version of Microsoft.CodeAnalysis that these projects referenced to a 4.0 version. This causes warnings when opening a 3.1 or 5.0 app in VS 2019 as it does not support these versions. Additionally update the version of Microsoft.CodeAnalysis.* packages used in tests, Razor, and framework analyzers that are only expected to run with VS 2020 to a more recent build. This is largely book-keeping, but allows us to write a test for file scoped namespaces. Fixes #36552 * Apply suggestions from code review * [release/6.0-rc2] Rename and consolidate "DelegateEndpoint" types (#36578) * Call AddEndpointsApiExplorer() in controllers Web API template (#36753) - backport of #36752 to release/6.0-rc2 Co-authored-by: DamianEdwards <[email protected]> * [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime (#36769) [release/6.0-rc2] Update dependencies from dotnet/efcore dotnet/runtime * Update dependencies from https://github.com/dotnet/efcore build 20210920.20 (#36778) [release/6.0-rc2] Update dependencies from dotnet/efcore Co-authored-by: dotnet-maestro[bot] <42748379+dotnet-maestro[bot]@users.noreply.github.com> Co-authored-by: Stephen Halter <[email protected]> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Safia Abdalla <[email protected]> Co-authored-by: Chris R <[email protected]> Co-authored-by: Brennan <[email protected]> Co-authored-by: Tanay Parikh <[email protected]> Co-authored-by: Chris Ross <[email protected]> Co-authored-by: Eric StJohn <[email protected]> Co-authored-by: Pranav K <[email protected]> Co-authored-by: DamianEdwards <[email protected]>
Description
Reverting changes introduced in #34644, which enforced WebSockets as the only available transport. Long polling was disabled as a fallback transport, due to concerns about user experience.
Customer Impact
This was a breaking change (announcement / docs). However, based on the feedback received in the recent RC1 release, more users are still utilizing long polling than expected. By adding back support of long polling, we're hoping to reduce migration complexity from .NET 5 -> .NET 6
Regression?
[If yes, specify the version the behavior has regressed from]
Risk
[Justify the selection above]
Reverting changes introduced in RC1 to add back long polling as a fallback transport.
Verification
Packaging changes reviewed?
Addresses #36655