Merge pull request #30887 from dotnet/main

aspnetcore/blazor/fundamentals/routing.md

@@ -515,6 +515,50 @@ Use <xref:Microsoft.AspNetCore.Components.NavigationManager> to manage URIs and
 
 :::moniker-end
 
+## Location changes
+
+For the <xref:Microsoft.AspNetCore.Components.NavigationManager.LocationChanged> event, <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs> provides the following information about navigation events:
+
+* <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs.Location>: The URL of the new location.
+* <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs.IsNavigationIntercepted>: If `true`, Blazor intercepted the navigation from the browser. If `false`, <xref:Microsoft.AspNetCore.Components.NavigationManager.NavigateTo%2A?displayProperty=nameWithType> caused the navigation to occur.
+
+The following component:
+
+* Navigates to the app's `Counter` component (`Counter.razor`) when the button is selected using <xref:Microsoft.AspNetCore.Components.NavigationManager.NavigateTo%2A>.
+* Handles the location changed event by subscribing to <xref:Microsoft.AspNetCore.Components.NavigationManager.LocationChanged?displayProperty=nameWithType>.
+  * The `HandleLocationChanged` method is unhooked when `Dispose` is called by the framework. Unhooking the method permits garbage collection of the component.
+  * The logger implementation logs the following information when the button is selected:
+
+    > :::no-loc text="BlazorSample.Pages.Navigate: Information: URL of new location: https://localhost:{PORT}/counter":::
+
+`Navigate.razor`:
+
+:::moniker range=">= aspnetcore-7.0"
+
+:::code language="razor" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
+
+:::moniker-end
+
+:::moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
+
+:::code language="razor" source="~/../blazor-samples/6.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
+
+:::moniker-end
+
+:::moniker range=">= aspnetcore-5.0 < aspnetcore-6.0"
+
+:::code language="razor" source="~/../blazor-samples/5.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
+
+:::moniker-end
+
+:::moniker range="< aspnetcore-5.0"
+
+:::code language="razor" source="~/../blazor-samples/3.1/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
+
+:::moniker-end
+
+For more information on component disposal, see <xref:blazor/components/lifecycle#component-disposal-with-idisposable-and-iasyncdisposable>.
+
 :::moniker range=">= aspnetcore-8.0"
 
 ## Enhanced navigation and form handling
@@ -532,8 +576,12 @@ Blazor Web Apps are capable of two types of routing for page navigation and form
 * The feature isn't [explicitly disabled](xref:blazor/fundamentals/startup#disable-enhanced-navigation-and-form-handling).
 * The destination URL is within the internal base URI space (the app's base path).
 
+If server-side routing and enhanced navigation are enabled, [location changing handlers](#location-changes) are only invoked for programmatic navigations initiated from an interactive runtime. In future releases, additional types of navigations, such as link clicks, may also invoke location changing handlers.
+
 If enhanced navigation is available for interactive client routing, navigation always goes through the interactive client-side router. This point is only relevant in an uncommon scenario where an interactive `<Router>` is nested inside a server-side rendered `<Router>`. In that case, the interactive router takes priority when handling navigation, so enhanced navigation isn't used for navigation because it's a server-side routing feature.
 
+When an enhanced navigation occurs, [`LocationChanged` event handlers](#location-changes) registered with interactive server and WebAssembly runtimes are typically invoked. There are cases when location changing handlers might not intercept an enhanced navigation. For example, the user might switch to another page before an interactive runtime becomes available. Therefore, it's important that app logic not rely on invoking a location changing handler, as there's no guarantee of the handler executing.
+
 When calling <xref:Microsoft.AspNetCore.Components.NavigationManager.NavigateTo%2A>:
 
 * If `forceLoad` is `false`, which is the default:
@@ -657,50 +705,6 @@ Passing `https://localhost:8001/segment` in `inputURI` results in the following
 
 > :::no-loc text="System.ArgumentException: 'The URI 'https://localhost:8001/segment' is not contained by the base URI 'https://localhost:8000/'.'":::
 
-## Location changes
-
-For the <xref:Microsoft.AspNetCore.Components.NavigationManager.LocationChanged> event, <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs> provides the following information about navigation events:
-
-* <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs.Location>: The URL of the new location.
-* <xref:Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs.IsNavigationIntercepted>: If `true`, Blazor intercepted the navigation from the browser. If `false`, <xref:Microsoft.AspNetCore.Components.NavigationManager.NavigateTo%2A?displayProperty=nameWithType> caused the navigation to occur.
-
-The following component:
-
-* Navigates to the app's `Counter` component (`Counter.razor`) when the button is selected using <xref:Microsoft.AspNetCore.Components.NavigationManager.NavigateTo%2A>.
-* Handles the location changed event by subscribing to <xref:Microsoft.AspNetCore.Components.NavigationManager.LocationChanged?displayProperty=nameWithType>.
-  * The `HandleLocationChanged` method is unhooked when `Dispose` is called by the framework. Unhooking the method permits garbage collection of the component.
-  * The logger implementation logs the following information when the button is selected:
-
-    > :::no-loc text="BlazorSample.Pages.Navigate: Information: URL of new location: https://localhost:{PORT}/counter":::
-
-`Navigate.razor`:
-
-:::moniker range=">= aspnetcore-7.0"
-
-:::code language="razor" source="~/../blazor-samples/7.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-6.0 < aspnetcore-7.0"
-
-:::code language="razor" source="~/../blazor-samples/6.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
-
-:::moniker-end
-
-:::moniker range=">= aspnetcore-5.0 < aspnetcore-6.0"
-
-:::code language="razor" source="~/../blazor-samples/5.0/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
-
-:::moniker-end
-
-:::moniker range="< aspnetcore-5.0"
-
-:::code language="razor" source="~/../blazor-samples/3.1/BlazorSample_WebAssembly/Pages/routing/Navigate.razor":::
-
-:::moniker-end
-
-For more information on component disposal, see <xref:blazor/components/lifecycle#component-disposal-with-idisposable-and-iasyncdisposable>.
-
 :::moniker range=">= aspnetcore-7.0"
 
 ## Navigation history state

aspnetcore/blazor/host-and-deploy/webassembly.md

@@ -122,9 +122,13 @@ In the app's project file:
 
 This setting trims away the IL code for most compiled methods, including methods from libraries and methods in the app. Not all compiled methods can be trimmed, as some are still required by the .NET interpreter at runtime.
 
-<!-- UPDATE 8.0 Remove the next line after some time has passed -->
+To report a problem with the trimming option, [open an issue on the `dotnet/runtime` GitHub repository](https://github.com/dotnet/runtime/issues).
 
-If you hit any issues using this trimming option, [open an issue on the `dotnet/runtime` GitHub repository](https://github.com/dotnet/runtime/issues).
+Disable the trimming property if it prevents your app from running normally:
+
+```xml
+<WasmStripILAfterAOT>false</WasmStripILAfterAOT>
+```
 
 :::moniker-end
 

aspnetcore/fundamentals/servers/httpsys.md

@@ -5,7 +5,7 @@ description: Learn about HTTP.sys, a web server for ASP.NET Core on Windows. Bui
 monikerRange: '>= aspnetcore-2.1'
 ms.author: riande
 ms.custom: mvc
-ms.date: 06/26/2023
+ms.date: 10/30/2023
 uid: fundamentals/servers/httpsys
 ---
 # HTTP.sys web server implementation in ASP.NET Core
@@ -64,7 +64,7 @@ HTTP/2 is enabled by default. If an HTTP/2 connection isn't established, the con
 
 ## HTTP/3 support
 
-[HTTP/3](https://quicwg.org/base-drafts/v2-samples/draft-ietf-quic-http.html) is enabled for ASP.NET Core apps when the following base requirements are met:
+[HTTP/3](https://datatracker.ietf.org/doc/rfc9114/) is enabled for ASP.NET Core apps when the following base requirements are met:
 
 * Windows Server 2022/Windows 11 or later
 * An `https` url binding is used.
@@ -171,7 +171,12 @@ In Visual Studio, the default launch profile is for IIS Express. To run the proj
 
    The settings in `UrlPrefixes` override `UseUrls`/`urls`/`ASPNETCORE_URLS` settings. Therefore, an advantage of `UseUrls`, `urls`, and the `ASPNETCORE_URLS` environment variable is that it's easier to switch between Kestrel and HTTP.sys.
 
-   HTTP.sys uses the [HTTP Server API UrlPrefix string formats](/windows/win32/http/urlprefix-strings).
+   HTTP.sys recognizes two types of wild cards in URL prefixes:   
+
+   * `*` is a *weak binding*, also known as a *fallback binding*. If the URL prefix is `http://*:5000`, and something else is bound to port 5000, this binding won't be used.
+   * `+` is a *strong binding*. If the URL prefix is `http://+:5000`, this binding will be used before other port 5000 bindings.
+
+   For more information, see [UrlPrefix Strings](/windows/win32/http/urlprefix-strings).
 
    > [!WARNING]
    > Top-level wildcard bindings (`http://*:80/` and `http://+:80`) should **not** be used. Top-level wildcard bindings create app security vulnerabilities. This applies to both strong and weak wildcards. Use explicit host names or IP addresses rather than wildcards. Subdomain wildcard binding (for example, `*.mysub.com`) isn't a security risk if you control the entire parent domain (as opposed to `*.com`, which is vulnerable). For more information, see [RFC 9110: Section 7.2: Host and :authority](https://www.rfc-editor.org/rfc/rfc9110#field.host).
@@ -315,6 +320,10 @@ Requirements to run gRPC with HTTP.sys:
 
 [!INCLUDE[](~/includes/reset.md)]
 
+## Tracing
+
+For information about how to get traces from HTTP.sys, see [HTTP.sys Manageability Scenarios](/windows/win32/http/http-sys-manageability-scenarios).
+
 ## Additional resources
 
 * [Enable Windows Authentication with HTTP.sys](xref:security/authentication/windowsauth#httpsys)

aspnetcore/fundamentals/servers/httpsys/includes/httpsys5-7.md

@@ -50,7 +50,7 @@ HTTP/2 is enabled by default. If an HTTP/2 connection isn't established, the con
 
 ## HTTP/3 support
 
-[HTTP/3](https://quicwg.org/base-drafts/v2-samples/draft-ietf-quic-http.html) is enabled for ASP.NET Core apps when the following base requirements are met:
+[HTTP/3](https://datatracker.ietf.org/doc/rfc9114/) is enabled for ASP.NET Core apps when the following base requirements are met:
 
 * Windows Server 2022/Windows 11 or later
 * An `https` url binding is used.

aspnetcore/fundamentals/servers/kestrel/includes/http3-6-7.md

@@ -70,7 +70,7 @@ HTTP/3 and QUIC have a number of benefits compared to HTTP/1.1 and HTTP/2:
 
 :::moniker range="= aspnetcore-6.0"
 
-[HTTP/3](https://quicwg.org/base-drafts/v2-samples/draft-ietf-quic-http.html) is the third and upcoming major version of HTTP. This article discusses requirements for HTTP/3 and how to configure Kestrel to use it.
+[HTTP/3](https://datatracker.ietf.org/doc/rfc9114/) is the third and upcoming major version of HTTP. This article discusses requirements for HTTP/3 and how to configure Kestrel to use it.
 
 > [!IMPORTANT]
 > HTTP/3 is available in .NET 6 as a *preview feature*. The HTTP/3 specification isn't finalized and behavioral or performance issues may exist in HTTP/3 with .NET 6.

aspnetcore/migration/70-80.md

@@ -83,6 +83,7 @@ The following migration scenarios are covered:
 * [Update a Blazor WebAssembly app](#update-a-blazor-webassembly-app)
 * [Convert a hosted Blazor WebAssembly app into a Blazor Web App](#convert-a-hosted-blazor-webassembly-app-into-a-blazor-web-app)
 * [Update service and endpoint option configuration](#update-service-and-endpoint-option-configuration)
+* [Drop Blazor Server with Yarp routing workaround](#drop-blazor-server-with-yarp-routing-workaround)
 
 For guidance on adding Blazor support to an ASP.NET Core app, see <xref:blazor/components/integration#add-blazor-support-to-an-aspnet-core-app>.
 
@@ -433,6 +434,10 @@ Updated configuration guidance appears in the following locations:
 
 -->
 
+### Drop Blazor Server with Yarp routing workaround
+
+If you previously followed the guidance in <xref:migration/inc/blazor?view=aspnetcore-7.0&preserve-view=true> for migrating a Blazor Server app with Yarp to .NET 6 or .NET 7, you can reverse the workaround steps that you took when following the article's guidance. Routing and deep linking for Blazor Server with Yarp work correctly in .NET 8.
+
 ## Update Docker images
 
 For apps using Docker, update your *Dockerfile* `FROM` statements and scripts. Use a base image that includes the ASP.NET Core 8.0 runtime. Consider the following `docker pull` command difference between ASP.NET Core 7.0 and 8.0:

aspnetcore/migration/inc/blazor.md

@@ -2,7 +2,7 @@
 title: Enable ASP.NET Core Blazor Server support with Yarp in incremental migration
 author: twsouthwick
 description: Learn how to enable ASP.NET Core Blazor Server support with Yarp in incremental migration.
-monikerRange: '>= aspnetcore-6.0'
+monikerRange: '>= aspnetcore-6.0 < aspnetcore-8.0'
 ms.author: tasou
 ms.custom: "mvc"
 ms.date: 03/01/2023

aspnetcore/release-notes/aspnetcore-8.0.md

@@ -4,7 +4,7 @@ author: rick-anderson
 description: Learn about the new features in ASP.NET Core 8.0.
 ms.author: riande
 ms.custom: mvc
-ms.date: 10/25/2023
+ms.date: 10/27/2023
 uid: aspnetcore-8
 ---
 # What's new in ASP.NET Core 8.0
@@ -284,6 +284,12 @@ The UI components also support advanced Identity concepts, such as multifactor a
 
 Authentication samples for other app types are in development, including Blazor WebAssembly and single page apps (Angular, React).
 
+## Blazor Server with Yarp routing
+
+Routing and deep linking for Blazor Server with Yarp work correctly in .NET 8.
+
+For more information, see <xref:migration/70-to-80#drop-blazor-server-with-yarp-routing-workaround>.
+
 ## SignalR
 
 ### New approach to set the server timeout and Keep-Alive interval
@@ -401,16 +407,9 @@ Stateful reconnect achieves this by:
 * Acknowledging messages received (ACK-ing) by both the server and client.
 * Recognizing when a connection is returning and replaying messages that might have been sent while the connection was down.
 
-To opt in to stateful reconnect for a JavaScript or TypeScript client:
+Stateful reconnect is available in ASP.NET Core 8.0 and later.
 
-* Update the JavaScript or TypeScript client code to enable the `withStatefulReconnect` option:
-
-  ```JavaScript
-  const builder = new signalR.HubConnectionBuilder()
-    .withUrl("/hubname")
-    .withStatefulReconnect({ bufferSize: 1000 });  // Optional, defaults to 100,000
-  const connection = builder.build();
-  ```
+Opt in to stateful reconnect at both the server hub endpoint and the client:
 
 * Update the server hub endpoint configuration to enable the `AllowStatefulReconnects` option:
 
@@ -421,9 +420,34 @@ To opt in to stateful reconnect for a JavaScript or TypeScript client:
   });
   ```
 
-To opt in to stateful reconnect for a .NET client:
+  Optionally, the maximum buffer size in bytes allowed by the server can be set globally or for a specific hub with the `StatefulReconnectBufferSize` option:
+
+  The `StatefulReconnectBufferSize` option set globally:
+
+  ```csharp
+  builder.AddSignalR(o => o.StatefulReconnectBufferSize = 1000);
+  ```
 
-* Update the .NET client code to enable the `WithStatefulReconnect` option:
+  The `StatefulReconnectBufferSize` option set for a specific hub:
+
+  ```csharp
+  builder.AddSignalR().AddHubOptions<MyHub>(o => o.StatefulReconnectBufferSize = 1000);
+  ```
+
+  The `StatefulReconnectBufferSize` option is optional with a default of 100,000 bytes.
+
+* Update JavaScript or TypeScript client code to enable the `withStatefulReconnect` option:
+
+  ```JavaScript
+  const builder = new signalR.HubConnectionBuilder()
+    .withUrl("/hubname")
+    .withStatefulReconnect({ bufferSize: 1000 });  // Optional, defaults to 100,000
+  const connection = builder.build();
+  ```
+
+  The `bufferSize` option is optional with a default of 100,000 bytes.
+
+* Update .NET client code to enable the `WithStatefulReconnect` option:
 
   ```csharp
     var builder = new HubConnectionBuilder()
@@ -433,14 +457,9 @@ To opt in to stateful reconnect for a .NET client:
     var hubConnection = builder.Build();
   ```
 
-* Update the server hub endpoint configuration to enable the `AllowStatefulReconnects` option:
+  The `StatefulReconnectBufferSize` option is optional with a default of 100,000 bytes.
 
-  ```csharp
-  app.MapHub<MyHub>("/hubName", options =>
-  {
-      options.AllowStatefulReconnects = true;
-  });
-  ```
+For more information, see [Configure stateful reconnect](xref:signalr/configuration#configure-stateful-reconnect).
 
 ## Minimal APIs