diff --git a/aspnetcore/blazor/components/render-modes.md b/aspnetcore/blazor/components/render-modes.md index 3972f72824ae..46352a23f108 100644 --- a/aspnetcore/blazor/components/render-modes.md +++ b/aspnetcore/blazor/components/render-modes.md @@ -342,7 +342,7 @@ If using the preceding component locally in a Blazor Web App, place the componen :::moniker range=">= aspnetcore-10.0" -During static SSR, Razor component page requests are processed by server-side ASP.NET Core middleware pipeline request processing for authorization. Dedicated Blazor features for authorization aren't operational because Razor components aren't rendered during server-side request processing. Blazor router features in the `Routes` component that aren't available during static SSR include displaying [Not Authorized content (`...`)](xref:blazor/security/index#authorizeview-component) (). Blazor Web Apps typically process unauthorized requests on the server by [customizing the behavior of Authorization Middleware](xref:security/authorization/authorizationmiddlewareresulthandler). +During static SSR, Razor component page requests are processed by server-side ASP.NET Core middleware pipeline request processing for authorization. Dedicated Blazor features for authorization aren't operational because Razor components aren't rendered during server-side request processing. Blazor router features in the `Routes` component that aren't available during static SSR include displaying [Not Authorized content (`...`)](xref:blazor/security/index#authorizeview-component) (). Blazor Web Apps typically process unauthorized requests on the server by [customizing the behavior of authorization middleware](xref:security/authorization/authorizationmiddlewareresulthandler). :::moniker-end @@ -350,7 +350,7 @@ During static SSR, Razor component page requests are processed by server-side AS During static SSR, Razor component page requests are processed by server-side ASP.NET Core middleware pipeline request processing for routing and authorization. Dedicated Blazor features for routing and authorization aren't operational because Razor components aren't rendered during server-side request processing. Blazor router features in the `Routes` component that aren't available during static SSR include displaying: -* [Not Authorized content (`...`)](xref:blazor/security/index#authorizeview-component) (): Blazor Web Apps typically process unauthorized requests on the server by [customizing the behavior of Authorization Middleware](xref:security/authorization/authorizationmiddlewareresulthandler). +* [Not Authorized content (`...`)](xref:blazor/security/index#authorizeview-component) (): Blazor Web Apps typically process unauthorized requests on the server by [customizing the behavior of authorization middleware](xref:security/authorization/authorizationmiddlewareresulthandler). * [Not Found content (`...`)](xref:blazor/fundamentals/routing#provide-custom-content-when-content-isnt-found) (): Blazor Web Apps typically process bad URL requests on the server by either displaying the browser's built-in 404 UI or returning a custom 404 page (or other response) via ASP.NET Core middleware (for example, [`UseStatusCodePagesWithRedirects`](xref:fundamentals/error-handling#usestatuscodepageswithredirects) / [API documentation](xref:Microsoft.AspNetCore.Builder.StatusCodePagesExtensions.UseStatusCodePagesWithRedirects%2A)). diff --git a/aspnetcore/blazor/components/rendering.md b/aspnetcore/blazor/components/rendering.md index 7c480e2a8164..a367c90f4488 100644 --- a/aspnetcore/blazor/components/rendering.md +++ b/aspnetcore/blazor/components/rendering.md @@ -59,12 +59,12 @@ To stream content updates when using static server-side rendering (static SSR) o If [enhanced navigation](xref:blazor/fundamentals/navigation#enhanced-navigation-and-form-handling) is active, streaming rendering renders [Not Found responses](xref:blazor/fundamentals/navigation#not-found-responses) without reloading the page. When enhanced navigation is blocked, the framework redirects to Not Found content with a page refresh. -Streaming rendering can only render components that have a route, such as a [`NotFoundPage` assignment](xref:blazor/fundamentals/navigation#not-found-responses) (`NotFoundPage="..."`) or a [Status Code Pages Re-execution Middleware page assignment](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) (). The Not Found render fragment (`...`) and the `DefaultNotFound` 404 content ("`Not found`" plain text) don't have routes, so they can't be used during streaming rendering. +Streaming rendering can only render components that have a route, such as a [`NotFoundPage` assignment](xref:blazor/fundamentals/navigation#not-found-responses) (`NotFoundPage="..."`) or a [status code pages re-execution middleware page assignment](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) (). The Not Found render fragment (`...`) and the `DefaultNotFound` 404 content ("`Not found`" plain text) don't have routes, so they can't be used during streaming rendering. Streaming `NavigationManager.NotFound` content rendering uses (in order): * A `NotFoundPage` passed to the `Router` component, if present. -* A Status Code Pages Re-execution Middleware page, if configured. +* A status code pages re-execution middleware page, if configured. * No action if neither of the preceding approaches is adopted. Non-streaming `NavigationManager.NotFound` content rendering uses (in order): @@ -73,7 +73,7 @@ Non-streaming `NavigationManager.NotFound` content rendering uses (in order): * Not Found render fragment content, if present. *Not recommended in .NET 10 or later.* * `DefaultNotFound` 404 content ("`Not found`" plain text). -[Status Code Pages Re-execution Middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. +[Status code pages re-execution middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. :::moniker-end diff --git a/aspnetcore/blazor/forms/index.md b/aspnetcore/blazor/forms/index.md index a7981b3868b0..94f9803d76d6 100644 --- a/aspnetcore/blazor/forms/index.md +++ b/aspnetcore/blazor/forms/index.md @@ -304,7 +304,7 @@ Adding token-based antiforgery middleware doesn't replace the automatic header-b The token-based result from antiforgery middleware is authoritative and overrides the earlier header-based CSRF middleware verdict. -To explicitly add Antiforgery Middleware, call after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . +To explicitly add antiforgery middleware, call after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . To disable the automatic header-based CSRF protection middleware, set the `DisableCsrfProtection` configuration key to true. For example, use the app settings file (`appsettings.json`) to disable the middleware: @@ -322,13 +322,13 @@ The the `DisableCsrfProtection` configuration setting can be supplied by any con For more information, see [Automatic CSRF protection](xref:security/anti-request-forgery#automatic-csrf-protection-in-aspnet-core). > [!IMPORTANT] -> The following guidance on the component and the service only apply to an app that explicitly adopts token-based Antiforgery Middleware by calling in its request processing pipeline. +> The following guidance on the component and the service only apply to an app that explicitly adopts token-based antiforgery middleware by calling in its request processing pipeline. :::moniker-end :::moniker range=">= aspnetcore-8.0 < aspnetcore-11.0" -The app uses Antiforgery Middleware by calling in its request processing pipeline in the `Program` file. is called after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . +The app uses antiforgery middleware by calling in its request processing pipeline in the `Program` file. is called after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . :::moniker-end diff --git a/aspnetcore/blazor/fundamentals/navigation.md b/aspnetcore/blazor/fundamentals/navigation.md index 39abdb6ed901..a71032afc946 100644 --- a/aspnetcore/blazor/fundamentals/navigation.md +++ b/aspnetcore/blazor/fundamentals/navigation.md @@ -301,7 +301,7 @@ You can use the `` MSBuild property set t > [!NOTE] > The following discussion mentions that a Not Found Razor component can be assigned to the `Router` component's parameter. The parameter works in concert with and is described in more detail later in this section. -Streaming rendering can only render components that have a route, such as a assignment (`NotFoundPage="..."`) or a [Status Code Pages Re-execution Middleware page assignment](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) (). `DefaultNotFound` 404 content ("`Not found`" plain text) doesn't have a route, so it can't be used during streaming rendering. +Streaming rendering can only render components that have a route, such as a assignment (`NotFoundPage="..."`) or a [status code pages re-execution middleware page assignment](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) (). `DefaultNotFound` 404 content ("`Not found`" plain text) doesn't have a route, so it can't be used during streaming rendering. > [!NOTE] > The Not Found render fragment (`...`) isn't supported in .NET 10 or later. @@ -310,10 +310,10 @@ Streaming rendering can only render components that have a route, such as a is set, render the contents of the assigned page. * If is set, render the assigned page. -* A Status Code Pages Re-execution Middleware page, if configured. +* A status code pages re-execution middleware page, if configured. * No action if none of the preceding approaches are adopted. -[Status Code Pages Re-execution Middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. +[Status code pages re-execution middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. When a component is rendered statically (static SSR) and is called, the 404 status code is set on the response: @@ -344,7 +344,7 @@ To provide Not Found content for global interactive rendering, use a Not Found p

Sorry, the content you are looking for does not exist.

``` -The `NotFound` component is assigned to , which supports routing that can be used across Status Code Pages Re-execution Middleware, including non-Blazor middleware. +The `NotFound` component is assigned to , which supports routing that can be used across status code pages re-execution middleware, including non-Blazor middleware. In the following example, the preceding `NotFound` component is present in the app's `Pages` folder and passed to the parameter: diff --git a/aspnetcore/blazor/fundamentals/routing.md b/aspnetcore/blazor/fundamentals/routing.md index f7f0b0bab23c..92c54a978fd0 100644 --- a/aspnetcore/blazor/fundamentals/routing.md +++ b/aspnetcore/blazor/fundamentals/routing.md @@ -188,7 +188,7 @@ The Blazor project template includes a `NotFound.razor` page. This page automati

Sorry, the content you are looking for does not exist.

``` -The `NotFound` component is assigned to the router's parameter, which supports routing that can be used across Status Code Pages Re-execution Middleware, including non-Blazor middleware. +The `NotFound` component is assigned to the router's parameter, which supports routing that can be used across status code pages re-execution middleware, including non-Blazor middleware. In the following example, the preceding `NotFound` component is present in the app's `Pages` folder and passed to the parameter: diff --git a/aspnetcore/blazor/fundamentals/signalr.md b/aspnetcore/blazor/fundamentals/signalr.md index 957de92a4829..745188d3acb2 100644 --- a/aspnetcore/blazor/fundamentals/signalr.md +++ b/aspnetcore/blazor/fundamentals/signalr.md @@ -109,7 +109,7 @@ This provides a clean, type-safe API for configuring SignalR connection settings ## Disable response compression for Hot Reload -When using [Hot Reload](xref:test/hot-reload), disable Response Compression Middleware in the `Development` environment. Whether or not the default code from a project template is used, always call first in the request processing pipeline. +When using [Hot Reload](xref:test/hot-reload), disable response compression middleware in the `Development` environment. Whether or not the default code from a project template is used, always call first in the request processing pipeline. In the `Program` file: diff --git a/aspnetcore/blazor/fundamentals/startup.md b/aspnetcore/blazor/fundamentals/startup.md index bc768a88d127..a69013dcf2f3 100644 --- a/aspnetcore/blazor/fundamentals/startup.md +++ b/aspnetcore/blazor/fundamentals/startup.md @@ -572,7 +572,7 @@ In the following examples, a [Content Security Policy (CSP)](https://developer.m ### Server-side and prerendered client-side scenarios -Use [ASP.NET Core Middleware](xref:fundamentals/middleware/index) to control the headers collection. +Use [ASP.NET Core middleware](xref:fundamentals/middleware/index) to control the headers collection. :::moniker range=">= aspnetcore-6.0" diff --git a/aspnetcore/blazor/fundamentals/static-files.md b/aspnetcore/blazor/fundamentals/static-files.md index 253f4ed7c783..45712db4237e 100644 --- a/aspnetcore/blazor/fundamentals/static-files.md +++ b/aspnetcore/blazor/fundamentals/static-files.md @@ -60,7 +60,7 @@ Serving static assets is managed by either routing endpoint conventions or a mid Feature | API | .NET Version | Description --- | --- | :---: | --- Map Static Assets routing endpoint conventions | | .NET 9 or later | Optimizes the delivery of static assets to clients. -Static File Middleware | | All .NET versions | Serves static assets to clients without the optimizations of Map Static Assets but useful for some tasks that Map Static Assets isn't capable of managing. +Static file middleware | | All .NET versions | Serves static assets to clients without the optimizations of Map Static Assets but useful for some tasks that Map Static Assets isn't capable of managing. Map Static Assets can replace in most situations. However, Map Static Assets is optimized for serving the assets from known locations in the app at build and publish time. If the app serves assets from other locations, such as disk or embedded resources, should be used. @@ -73,7 +73,7 @@ When [Interactive WebAssembly or Interactive Auto render modes](xref:blazor/fund * During WebAssembly boot, Blazor retrieves the URL, imports the module, and calls a function to retrieve the asset collection and reconstruct it in memory. The URL is specific to the content and cached forever, so this overhead cost is only paid once per user until the app is updated. * The resource collection is also exposed at a human-readable URL (`_framework/resource-collection.js`), so JS has access to the resource collection for [enhanced navigation](xref:blazor/fundamentals/navigation#enhanced-navigation-and-form-handling) or to implement features of other frameworks and third-party components. -Static File Middleware () is useful in the following situations that Map Static Assets () can't handle: +Static file middleware () is useful in the following situations that Map Static Assets () can't handle: * Serving files from disk that aren't part of the build or publish process, for example, files added to the application folder during or after deployment. * Applying a path prefix to Blazor WebAssembly static asset files, which is covered in the [Prefix for Blazor WebAssembly assets](#prefix-for-blazor-webassembly-assets) section. @@ -229,9 +229,9 @@ For examples of how to address the policy violation with Subresource Integrity ( :::moniker range="< aspnetcore-9.0" -Configure Static File Middleware to serve static assets to clients by calling in the app's request processing pipeline. For more information, see . +Configure static file middleware to serve static assets to clients by calling in the app's request processing pipeline. For more information, see . -In releases prior to .NET 8, Blazor framework static files, such as the Blazor script, are served via Static File Middleware. In .NET 8 or later, Blazor framework static files are mapped using endpoint routing, and Static File Middleware is no longer used. +In releases prior to .NET 8, Blazor framework static files, such as the Blazor script, are served via static file middleware. In .NET 8 or later, Blazor framework static files are mapped using endpoint routing, and static file middleware is no longer used. :::moniker-end @@ -506,7 +506,7 @@ To create additional file mappings with a to execute a custom Static File Middleware: +* You can avoid interfering with serving `_framework/blazor.server.js` by using to execute a custom static file middleware: ```csharp app.MapWhen(ctx => !ctx.Request.Path diff --git a/aspnetcore/blazor/globalization-localization.md b/aspnetcore/blazor/globalization-localization.md index 23698c73b75e..9475b2b2f83c 100644 --- a/aspnetcore/blazor/globalization-localization.md +++ b/aspnetcore/blazor/globalization-localization.md @@ -306,7 +306,7 @@ In ***client-side development***, dynamically setting the culture from the `Acce > [!NOTE] > If the app's specification requires limiting the supported cultures to an explicit list, see the [Dynamically set the client-side culture by user preference](#dynamically-set-the-client-side-culture-by-user-preference) section of this article. -Apps are localized using [Localization Middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . +Apps are localized using [localization middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . Add the following line to the `Program` file where services are registered: @@ -316,13 +316,13 @@ builder.Services.AddLocalization(); :::moniker range=">= aspnetcore-8.0" -In ***server-side development***, specify the app's supported cultures before any middleware that might check the request culture. Generally, place Request Localization Middleware immediately before calling . The following example configures supported cultures for United States English and Costa Rican Spanish: +In ***server-side development***, specify the app's supported cultures before any middleware that might check the request culture. Generally, place localization middleware immediately before calling . The following example configures supported cultures for United States English and Costa Rican Spanish: :::moniker-end :::moniker range="< aspnetcore-8.0" -In ***server-side development***, specify the app's supported cultures immediately after Routing Middleware () is added to the processing pipeline. The following example configures supported cultures for United States English and Costa Rican Spanish using the following API: +In ***server-side development***, specify the app's supported cultures immediately after routing middleware () is added to the processing pipeline. The following example configures supported cultures for United States English and Costa Rican Spanish using the following API: * adds the set of the supported cultures for *globalization* (date, number, and currency formatting). * adds the set of the supported UI cultures *for localization* (translated UI strings for rendering content). @@ -355,7 +355,7 @@ app.UseRequestLocalization(localizationOptions); In the preceding example, [`CultureTypes.SpecificCultures`](xref:System.Globalization.CultureTypes) returns only cultures that are specific to a country or region—such as `en-US` or `fr-FR`—which come with full, concrete globalization data (for dates, numbers, calendars, and other cultural UI) that .NET can use for accurate formatting and parsing. Neutral cultures, such as `en` or `fr`, may not have complete globalization data, so they aren't included in this list. -For information on ordering the Localization Middleware in the middleware pipeline of the `Program` file, see . +For information on ordering the localization middleware in the middleware pipeline of the `Program` file, see . Use the `CultureExample1` component shown in the [Demonstration component](#demonstration-component) section to study how globalization works. Issue a request with United States English (`en-US`). Switch to Costa Rican Spanish (`es-CR`) in the browser's language settings. Request the webpage again. @@ -469,7 +469,7 @@ Use the `CultureExample1` component shown in the [Demonstration component](#demo :::moniker range=">= aspnetcore-6.0" -Server-side apps are localized using [Localization Middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . +Server-side apps are localized using [localization middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . In the `Program` file: @@ -481,13 +481,13 @@ builder.Services.AddLocalization(); :::moniker range=">= aspnetcore-8.0" -Specify the static culture in the `Program` file before any middleware that might check the request culture. Generally, place Request Localization Middleware immediately before . The following example configures United States English: +Specify the static culture in the `Program` file before any middleware that might check the request culture. Generally, place localization middleware immediately before . The following example configures United States English: :::moniker-end :::moniker range=">= aspnetcore-6.0 < aspnetcore-8.0" -Specify the static culture in the `Program` file immediately after Routing Middleware () is added to the processing pipeline. The following example configures United States English: +Specify the static culture in the `Program` file immediately after routing middleware () is added to the processing pipeline. The following example configures United States English: :::moniker-end @@ -499,13 +499,13 @@ app.UseRequestLocalization("en-US"); The culture value for must conform to the [BCP-47 language tag format](https://www.rfc-editor.org/info/bcp47). -For information on ordering the Localization Middleware in the middleware pipeline of the `Program` file, see . +For information on ordering the localization middleware in the middleware pipeline of the `Program` file, see . :::moniker-end :::moniker range="< aspnetcore-6.0" -Server-side apps are localized using [Localization Middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . +Server-side apps are localized using [localization middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . In `Startup.ConfigureServices` (`Startup.cs`): @@ -513,7 +513,7 @@ In `Startup.ConfigureServices` (`Startup.cs`): services.AddLocalization(); ``` -Specify the static culture in `Startup.Configure` (`Startup.cs`) immediately after Routing Middleware is added to the processing pipeline. The following example configures United States English: +Specify the static culture in `Startup.Configure` (`Startup.cs`) immediately after routing middleware is added to the processing pipeline. The following example configures United States English: ```csharp app.UseRequestLocalization("en-US"); @@ -521,7 +521,7 @@ app.UseRequestLocalization("en-US"); The culture value for must conform to the [BCP-47 language tag format](https://www.rfc-editor.org/info/bcp47). -For information on ordering the Localization Middleware in the middleware pipeline of `Startup.Configure`, see . +For information on ordering the localization middleware in the middleware pipeline of `Startup.Configure`, see . :::moniker-end @@ -750,7 +750,7 @@ Add the [`Microsoft.Extensions.Localization` package](https://www.nuget.org/pack [!INCLUDE[](~/includes/package-reference.md)] -Server-side apps are localized using [Localization Middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . +Server-side apps are localized using [localization middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . In the `Program` file: @@ -768,7 +768,7 @@ Before the call to ) is added to the request processing pipeline, place the following code: +After routing middleware () is added to the request processing pipeline, place the following code: :::moniker-end @@ -782,9 +782,9 @@ var localizationOptions = new RequestLocalizationOptions() app.UseRequestLocalization(localizationOptions); ``` -For information on ordering the Localization Middleware in the middleware pipeline, see . +For information on ordering the localization middleware in the middleware pipeline, see . -The following example shows how to set the current culture in a cookie that can be read by the Localization Middleware. +The following example shows how to set the current culture in a cookie that can be read by the localization middleware. :::moniker range=">= aspnetcore-8.0" @@ -845,7 +845,7 @@ Add the following to the file: :::moniker-end -For information on ordering the Localization Middleware in the middleware pipeline, see . +For information on ordering the localization middleware in the middleware pipeline, see . If the app isn't configured to process controller actions: @@ -1338,7 +1338,7 @@ Add the [`Microsoft.Extensions.Localization` package](https://www.nuget.org/pack [!INCLUDE[](~/includes/package-reference.md)] -Server-side apps are localized using [Localization Middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . +Server-side apps are localized using [localization middleware](xref:fundamentals/localization#localization-middleware). Add localization services to the app with . In the server project's `Program` file where services are registered: @@ -1360,7 +1360,7 @@ var localizationOptions = new RequestLocalizationOptions() app.UseRequestLocalization(localizationOptions); ``` -The following example shows how to set the current culture in a cookie that can be read by the Localization Middleware. +The following example shows how to set the current culture in a cookie that can be read by the localization middleware. The following namespaces are required for the `App` component: @@ -1496,7 +1496,7 @@ builder.Services.AddLocalization(); ### Server-side localization -Use [Localization Middleware](xref:fundamentals/localization#localization-middleware) to set the app's culture. +Use [localization middleware](xref:fundamentals/localization#localization-middleware) to set the app's culture. If the app doesn't already support dynamic culture selection: @@ -1513,13 +1513,13 @@ builder.Services.AddLocalization(); :::moniker range=">= aspnetcore-8.0" -Place Request Localization Middleware before any middleware that might check the request culture. Generally, place the middleware immediately before calling : +Place localization middleware before any middleware that might check the request culture. Generally, place the middleware immediately before calling : :::moniker-end :::moniker range=">= aspnetcore-6.0 < aspnetcore-8.0" -Immediately after Routing Middleware () is added to the processing pipeline: +Immediately after routing middleware () is added to the processing pipeline: :::moniker-end @@ -1535,7 +1535,7 @@ var localizationOptions = new RequestLocalizationOptions() app.UseRequestLocalization(localizationOptions); ``` -For information on ordering the Localization Middleware in the middleware pipeline, see . +For information on ordering the localization middleware in the middleware pipeline, see . :::moniker-end @@ -1550,7 +1550,7 @@ In `Startup.ConfigureServices` (`Startup.cs`): services.AddLocalization(); ``` -In `Startup.Configure` immediately after Routing Middleware () is added to the processing pipeline: +In `Startup.Configure` immediately after routing middleware () is added to the processing pipeline: ```csharp var supportedCultures = new[] { "en-US", "es-CR" }; @@ -1562,7 +1562,7 @@ var localizationOptions = new RequestLocalizationOptions() app.UseRequestLocalization(localizationOptions); ``` -For information on ordering the Localization Middleware in the middleware pipeline of `Startup.Configure`, see . +For information on ordering the localization middleware in the middleware pipeline of `Startup.Configure`, see . :::moniker-end diff --git a/aspnetcore/blazor/host-and-deploy/app-base-path.md b/aspnetcore/blazor/host-and-deploy/app-base-path.md index 6ac3187572b2..14de89e8256c 100644 --- a/aspnetcore/blazor/host-and-deploy/app-base-path.md +++ b/aspnetcore/blazor/host-and-deploy/app-base-path.md @@ -246,7 +246,7 @@ In many hosting scenarios, the relative URL path to the app is the root of the a :::moniker-end > [!NOTE] -> When using (see ), [`app.UseRouting`](xref:Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.UseRouting%2A) must be called after so that the Routing Middleware can observe the modified path before matching routes. Otherwise, routes are matched before the path is rewritten by as described in the and . +> When using (see ), [`app.UseRouting`](xref:Microsoft.AspNetCore.Builder.EndpointRoutingApplicationBuilderExtensions.UseRouting%2A) must be called after so that the routing middleware can observe the modified path before matching routes. Otherwise, routes are matched before the path is rewritten by as described in the and . Don't prefix links throughout the app with a forward slash. Either avoid the use of a path segment separator or use dot-slash (`./`) relative path notation: @@ -265,7 +265,7 @@ Don't prefix [Navigation Manager](xref:blazor/fundamentals/navigation#uri-and-na * Correct: `Navigation.NavigateTo("other");` * Correct: `Navigation.NavigateTo("./other");` -In typical configurations for Azure/IIS hosting, additional configuration usually isn't required. In some non-IIS hosting and reverse proxy hosting scenarios, additional Static File Middleware configuration might be required: +In typical configurations for Azure/IIS hosting, additional configuration usually isn't required. In some non-IIS hosting and reverse proxy hosting scenarios, additional static file middleware configuration might be required: * To serve static files correctly (for example, `app.UseStaticFiles("/CoolApp");`). * To serve the Blazor script (`_framework/blazor.*.js`). For more information, see . diff --git a/aspnetcore/blazor/host-and-deploy/index.md b/aspnetcore/blazor/host-and-deploy/index.md index 8ccd5f98fc33..140094c852b2 100644 --- a/aspnetcore/blazor/host-and-deploy/index.md +++ b/aspnetcore/blazor/host-and-deploy/index.md @@ -161,7 +161,7 @@ In scenarios where an app requires a separate area with custom resources and Raz * `~/css/site.css` * `~/BlazorSample.styles.css` (the example app's namespace is `BlazorSample`) * `~/_framework/blazor.server.js` (Blazor script) -* If the area should have its own static asset folder, add the folder and specify its location to Static File Middleware in `Program.cs` (for example, `app.UseStaticFiles("/Admin/wwwroot")`). +* If the area should have its own static asset folder, add the folder and specify its location to static file middleware in `Program.cs` (for example, `app.UseStaticFiles("/Admin/wwwroot")`). * Razor components are added to the area's folder. At a minimum, add an `Index` component to the area folder with the correct `@page` directive for the area. For example, add a `Pages/Admin/Index.razor` file based on the app's default `Pages/Index.razor` file. Indicate the Admin area as the route template at the top of the file (`@page "/admin"`). Add additional components as needed. For example, `Pages/Admin/Component1.razor` with an `@page` directive and route template of `@page "/admin/component1`. * In `Program.cs`, call for the area's request path immediately before the fallback root page path to the `_Host` page: diff --git a/aspnetcore/blazor/host-and-deploy/webassembly/multiple-hosted-webassembly.md b/aspnetcore/blazor/host-and-deploy/webassembly/multiple-hosted-webassembly.md index 30715c5e9bdb..adc2ffe9cccf 100644 --- a/aspnetcore/blazor/host-and-deploy/webassembly/multiple-hosted-webassembly.md +++ b/aspnetcore/blazor/host-and-deploy/webassembly/multiple-hosted-webassembly.md @@ -196,7 +196,7 @@ In the server app's `Program.cs` file, remove the following code, which appears - app.MapFallbackToFile("index.html"); ``` - Leave Static File Middleware in place: + Leave static file middleware in place: ```csharp app.UseStaticFiles(); diff --git a/aspnetcore/blazor/javascript-interoperability/index.md b/aspnetcore/blazor/javascript-interoperability/index.md index acdda1c58132..374a87d41380 100644 --- a/aspnetcore/blazor/javascript-interoperability/index.md +++ b/aspnetcore/blazor/javascript-interoperability/index.md @@ -396,7 +396,7 @@ To disable client-side caching in browsers, developers usually adopt one of the * Disable caching when the browser's developer tools console is open. Guidance can be found in the developer tools documentation of each browser maintainer: * [Chrome DevTools](https://developer.chrome.com/docs/devtools/) * [Microsoft Edge Developer Tools overview](/microsoft-edge/devtools-guide-chromium/) -* Perform a manual browser refresh of any webpage of the Blazor app to reload JS files from the server. ASP.NET Core's HTTP Caching Middleware always honors a valid no-cache [`Cache-Control` header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control) sent by a client. +* Perform a manual browser refresh of any webpage of the Blazor app to reload JS files from the server. ASP.NET Core's HTTP response caching middleware always honors a valid no-cache [`Cache-Control` header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control) sent by a client. For more information, see: diff --git a/aspnetcore/blazor/security/additional-scenarios.md b/aspnetcore/blazor/security/additional-scenarios.md index 582b547ae980..1cebf40c5e52 100644 --- a/aspnetcore/blazor/security/additional-scenarios.md +++ b/aspnetcore/blazor/security/additional-scenarios.md @@ -478,13 +478,13 @@ In a component that presents a **Logout** button to authorized users: :::moniker range=">= aspnetcore-6.0" -For an app that uses more than one Authentication Middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of the `Program` file. The following example sets the OpenID Connect (OIDC) scheme: +For an app that uses more than one authentication middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of the `Program` file. The following example sets the OpenID Connect (OIDC) scheme: :::moniker-end :::moniker range="< aspnetcore-6.0" -For an app that uses more than one Authentication Middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of `Startup.cs`. The following example sets the OpenID Connect (OIDC) scheme: +For an app that uses more than one authentication middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of `Startup.cs`. The following example sets the OpenID Connect (OIDC) scheme: :::moniker-end @@ -523,7 +523,7 @@ app.MapBlazorHub().RequireAuthorization( :::moniker range="< aspnetcore-5.0" -For an app that uses more than one Authentication Middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of `Startup.Configure`. The following example sets the Microsoft Entra ID scheme: +For an app that uses more than one authentication middleware and thus has more than one authentication scheme, the scheme that Blazor uses can be explicitly set in the endpoint configuration of `Startup.Configure`. The following example sets the Microsoft Entra ID scheme: ```csharp endpoints.MapBlazorHub().RequireAuthorization( @@ -803,7 +803,7 @@ Use the service in a component to obtain the user:

Hello, @(UserService.GetUser().Identity?.Name ?? "world")!

``` -To set the user in middleware for MVC, Razor Pages, and in other ASP.NET Core scenarios, call `SetUser` on the `UserService` in custom middleware after the Authentication Middleware runs, or set the user with an implementation. The following example adopts the middleware approach. +To set the user in middleware for MVC, Razor Pages, and in other ASP.NET Core scenarios, call `SetUser` on the `UserService` in custom middleware after the authentication middleware runs, or set the user with an implementation. The following example adopts the middleware approach. `UserServiceMiddleware.cs`: diff --git a/aspnetcore/blazor/security/gdpr.md b/aspnetcore/blazor/security/gdpr.md index 0be367e597a1..348b9c0559ac 100644 --- a/aspnetcore/blazor/security/gdpr.md +++ b/aspnetcore/blazor/security/gdpr.md @@ -35,13 +35,13 @@ builder.Services.AddHttpContextAccessor(); :::moniker range=">= aspnetcore-8.0" -In the `Program` file before the call to , add Cookie Policy Middleware by calling : +In the `Program` file before the call to , add cookie policy middleware by calling : :::moniker-end :::moniker range="< aspnetcore-8.0" -In the `Program` file before the call to , add Cookie Policy Middleware by calling : +In the `Program` file before the call to , add cookie policy middleware by calling : :::moniker-end diff --git a/aspnetcore/blazor/security/index.md b/aspnetcore/blazor/security/index.md index 544b432b32e0..9081fe34491c 100644 --- a/aspnetcore/blazor/security/index.md +++ b/aspnetcore/blazor/security/index.md @@ -79,7 +79,7 @@ The Blazor project template: Antiforgery *middleware* isn't automatically included in the request processing pipeline without explicitly calling . -To explicitly add Antiforgery Middleware, call after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . +To explicitly add antiforgery middleware, call after the call to . If there are calls to and , the call to must go between them. A call to must be placed after calls to and . Adding token-based antiforgery middleware doesn't replace the automatic header-based CSRF protection middleware. When an app calls , both defense mechanisms run for a form post: @@ -1815,7 +1815,7 @@ PII refers any information relating to an identified or identifiable natural per * [Quickstart: Add sign-in with Microsoft to an ASP.NET Core web app](/entra/identity-platform/quickstart-v2-aspnet-core-webapp) * [Quickstart: Protect an ASP.NET Core web API with Microsoft identity platform](/entra/identity-platform/quickstart-v2-aspnet-core-web-api) * : Includes guidance on: - * Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks. + * Using forwarded headers middleware to preserve HTTPS scheme information across proxy servers and internal networks. * Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies. * Microsoft identity platform documentation * [Overview](/entra/identity-platform/) @@ -1839,7 +1839,7 @@ PII refers any information relating to an identified or identifiable natural per * [Quickstart: Add sign-in with Microsoft to an ASP.NET Core web app](/entra/identity-platform/quickstart-v2-aspnet-core-webapp) * [Quickstart: Protect an ASP.NET Core web API with Microsoft identity platform](/entra/identity-platform/quickstart-v2-aspnet-core-web-api) * : Includes guidance on: - * Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks. + * Using forwarded headers middleware to preserve HTTPS scheme information across proxy servers and internal networks. * Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies. * Microsoft identity platform documentation * [Overview](/entra/identity-platform/) diff --git a/aspnetcore/blazor/security/interactive-server-side-rendering.md b/aspnetcore/blazor/security/interactive-server-side-rendering.md index f06aaec13e97..5ef08b025a31 100644 --- a/aspnetcore/blazor/security/interactive-server-side-rendering.md +++ b/aspnetcore/blazor/security/interactive-server-side-rendering.md @@ -414,7 +414,7 @@ For more information, see . Cross-origin attacks involve a client from a different origin performing an action against the server. The malicious action is typically a GET request or a form POST (Cross-Site Request Forgery, CSRF), but opening a malicious WebSocket is also possible. Blazor apps offer [the same guarantees that any other SignalR app using the hub protocol offer](xref:signalr/security): -* Apps can be accessed cross-origin unless additional measures are taken to prevent it. To disable cross-origin access, either disable CORS in the endpoint by adding the CORS Middleware to the pipeline and adding the to the Blazor endpoint metadata or limit the set of allowed origins by [configuring SignalR for Cross-Origin Resource Sharing](xref:signalr/security#cross-origin-resource-sharing). For guidance on WebSocket origin restrictions, see . +* Apps can be accessed cross-origin unless additional measures are taken to prevent it. To disable cross-origin access, either disable CORS in the endpoint by adding the CORS middleware to the pipeline and adding the to the Blazor endpoint metadata or limit the set of allowed origins by [configuring SignalR for Cross-Origin Resource Sharing](xref:signalr/security#cross-origin-resource-sharing). For guidance on WebSocket origin restrictions, see . * If CORS is enabled, extra steps might be required to protect the app depending on the CORS configuration. If CORS is globally enabled, CORS can be disabled for the Blazor SignalR hub by adding the metadata to the endpoint metadata after calling on the endpoint route builder. For more information, see . diff --git a/aspnetcore/blazor/security/qrcodes-for-authenticator-apps.md b/aspnetcore/blazor/security/qrcodes-for-authenticator-apps.md index 8f13b5709fde..5599202d125f 100644 --- a/aspnetcore/blazor/security/qrcodes-for-authenticator-apps.md +++ b/aspnetcore/blazor/security/qrcodes-for-authenticator-apps.md @@ -20,7 +20,7 @@ The guidance in this article relies upon either creating the app with **Individu > [!WARNING] > TOTP codes should be kept secret because they can be used to authenticate multiple times before they expire. -## Adding QR codes to the 2FA configuration page +## Add QR codes to the 2FA configuration page A QR code generated by the app to set up 2FA with an TOTP authenticator app must be generated by a QR code library. diff --git a/aspnetcore/blazor/security/webassembly/hosted-with-identity-server.md b/aspnetcore/blazor/security/webassembly/hosted-with-identity-server.md index 54c97ffed18f..e99cc605e6ec 100644 --- a/aspnetcore/blazor/security/webassembly/hosted-with-identity-server.md +++ b/aspnetcore/blazor/security/webassembly/hosted-with-identity-server.md @@ -177,7 +177,7 @@ The following services are registered. :::moniker-end - * The Identity Server Middleware exposes the OpenID Connect (OIDC) endpoints: + * The Identity Server middleware exposes the OpenID Connect (OIDC) endpoints: ```csharp app.UseIdentityServer(); @@ -185,7 +185,7 @@ The following services are registered. :::moniker range="< aspnetcore-7.0" - * The Authentication Middleware is responsible for validating request credentials and setting the user on the request context: + * The authentication middleware is responsible for validating request credentials and setting the user on the request context: ```csharp app.UseAuthentication(); @@ -193,7 +193,7 @@ The following services are registered. :::moniker-end - * Authorization Middleware enables authorization capabilities: + * Authorization middleware enables authorization capabilities: ```csharp app.UseAuthorization(); @@ -212,7 +212,7 @@ The helper method configures a policy scheme for the app as the default authentication handler. The policy is configured to allow Identity to handle all requests routed to any subpath in the Identity URL space under `/Identity`. The handles all other requests. Additionally, this method: * Registers an API resource with Identity Server with a default scope of `{PROJECT NAME}API`, where the `{PROJECT NAME}` placeholder is the project's name at app creation. -* Configures the JWT Bearer Token Middleware to validate tokens issued by Identity Server for the app. +* Configures the JWT bearer token middleware to validate tokens issued by Identity Server for the app. ### Weather forecast controller @@ -734,6 +734,6 @@ Get-ChildItem -path Cert:\CurrentUser\My -Recurse | Format-List DnsNameList, Sub * * [Unauthenticated or unauthorized web API requests in an app with a secure default client](xref:blazor/security/webassembly/additional-scenarios#unauthenticated-or-unauthorized-web-api-requests-in-an-app-with-a-secure-default-client) * : Includes guidance on: - * Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks. + * Using forwarded headers middleware to preserve HTTPS scheme information across proxy servers and internal networks. * Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies. * [Duende Identity Server](https://docs.duendesoftware.com) diff --git a/aspnetcore/blazor/security/webassembly/index.md b/aspnetcore/blazor/security/webassembly/index.md index 9e7fbac395e5..1ec05623df43 100644 --- a/aspnetcore/blazor/security/webassembly/index.md +++ b/aspnetcore/blazor/security/webassembly/index.md @@ -376,7 +376,7 @@ For more information, see the following resources: * [General documentation](/entra/identity-platform/) * [Access tokens](/entra/identity-platform/access-tokens) * - * Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks. + * Using forwarded headers middleware to preserve HTTPS scheme information across proxy servers and internal networks. * Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies. * [Prerendering with authentication](xref:blazor/security/webassembly/additional-scenarios#prerendering-with-authentication) * [WebAssembly: Security](https://webassembly.org/docs/security/) diff --git a/aspnetcore/blazor/security/webassembly/standalone-with-authentication-library.md b/aspnetcore/blazor/security/webassembly/standalone-with-authentication-library.md index b2292543b09b..f18c0c593a77 100644 --- a/aspnetcore/blazor/security/webassembly/standalone-with-authentication-library.md +++ b/aspnetcore/blazor/security/webassembly/standalone-with-authentication-library.md @@ -229,5 +229,5 @@ The * [Unauthenticated or unauthorized web API requests in an app with a secure default client](xref:blazor/security/webassembly/additional-scenarios#unauthenticated-or-unauthorized-web-api-requests-in-an-app-with-a-secure-default-client) * : Includes guidance on: - * Using Forwarded Headers Middleware to preserve HTTPS scheme information across proxy servers and internal networks. + * Using forwarded headers middleware to preserve HTTPS scheme information across proxy servers and internal networks. * Additional scenarios and use cases, including manual scheme configuration, request path changes for correct request routing, and forwarding the request scheme for Linux and non-IIS reverse proxies. diff --git a/aspnetcore/blazor/tutorials/movie-database-app/part-1.md b/aspnetcore/blazor/tutorials/movie-database-app/part-1.md index 2b44ef40c851..0f8b0f6d5469 100644 --- a/aspnetcore/blazor/tutorials/movie-database-app/part-1.md +++ b/aspnetcore/blazor/tutorials/movie-database-app/part-1.md @@ -290,8 +290,8 @@ Next, the HTTP request pipeline is configured. When the app isn't running in the `Development` environment: -* Exception Handler Middleware () processes errors and displays a custom error page. -* [HTTP Strict Transport Security Protocol (HSTS) Middleware](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) () processes [HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html). +* Exception handler middleware () processes errors and displays a custom error page. +* [HTTP Strict Transport Security (HSTS) protocol middleware](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) () processes [HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html). ```csharp if (!app.Environment.IsDevelopment()) @@ -303,7 +303,7 @@ if (!app.Environment.IsDevelopment()) :::moniker range=">= aspnetcore-10.0" -By default, an ASP.NET Core app doesn't provide a status code page for HTTP error status codes, such as *404 - Not Found*. When the app sets an HTTP 400-599 error status code without a body, it returns the status code and an empty response body. However, an app generated from the Blazor Web App project template calls to add Status Code Pages Middleware to the request pipeline for pages that aren't found, which generates the response body by re-executing the request pipeline using the path to the Not Found error page (`/not-found`): +By default, an ASP.NET Core app doesn't provide a status code page for HTTP error status codes, such as *404 - Not Found*. When the app sets an HTTP 400-599 error status code without a body, it returns the status code and an empty response body. However, an app generated from the Blazor Web App project template calls to add status code pages middleware to the request pipeline for pages that aren't found, which generates the response body by re-executing the request pipeline using the path to the Not Found error page (`/not-found`): ```csharp app.UseStatusCodePagesWithReExecute("/not-found", @@ -312,13 +312,13 @@ app.UseStatusCodePagesWithReExecute("/not-found", :::moniker-end -HTTPS Redirection Middleware () enforces the HTTPS protocol by redirecting HTTP requests to HTTPS if an HTTPS port is available: +HTTPS redirection middleware () enforces the HTTPS protocol by redirecting HTTP requests to HTTPS if an HTTPS port is available: ```csharp app.UseHttpsRedirection(); ``` -Antiforgery Middleware () enforces antiforgery protection for form processing: +Antiforgery middleware () enforces antiforgery protection for form processing: ```csharp app.UseAntiforgery(); @@ -336,7 +336,7 @@ app.MapStaticAssets(); :::moniker range="< aspnetcore-9.0" -Static File Middleware () serves static files, such as images, scripts, and stylesheets from the `wwwroot` folder: +Static file middleware () serves static files, such as images, scripts, and stylesheets from the `wwwroot` folder: ```csharp app.UseStaticFiles(); diff --git a/aspnetcore/blazor/tutorials/signalr-blazor.md b/aspnetcore/blazor/tutorials/signalr-blazor.md index 0def71316fc9..e93526194c56 100644 --- a/aspnetcore/blazor/tutorials/signalr-blazor.md +++ b/aspnetcore/blazor/tutorials/signalr-blazor.md @@ -201,7 +201,7 @@ using Microsoft.AspNetCore.ResponseCompression; using BlazorSignalRApp.Hubs; ``` -Add SignalR and Response Compression Middleware services: +Add SignalR and response compression middleware services: ```csharp builder.Services.AddSignalR(); @@ -213,7 +213,7 @@ builder.Services.AddResponseCompression(opts => }); ``` -Use Response Compression Middleware at the top of the processing pipeline's configuration. Place the following line of code immediately after the line that builds the app (`var app = builder.Build();`): +Use response compression middleware at the top of the processing pipeline's configuration. Place the following line of code immediately after the line that builds the app (`var app = builder.Build();`): ```csharp app.UseResponseCompression(); @@ -242,7 +242,7 @@ Add an entry to the `NavMenu` component to reach the chat page. In `Components/L ``` > [!NOTE] -> Disable Response Compression Middleware in the `Development` environment when using [Hot Reload](xref:test/hot-reload). For more information, see . +> Disable response compression middleware in the `Development` environment when using [Hot Reload](xref:test/hot-reload). For more information, see . ## Run the app @@ -422,7 +422,7 @@ Add the namespace for the `ChatHub` class to the top of the file: using BlazorWebAssemblySignalRApp.Server.Hubs; ``` -Add SignalR and Response Compression Middleware services: +Add SignalR and response compression middleware services: ```csharp builder.Services.AddSignalR(); @@ -433,7 +433,7 @@ builder.Services.AddResponseCompression(opts => }); ``` -Use Response Compression Middleware at the top of the processing pipeline's configuration immediately after the line that builds the app: +Use response compression middleware at the top of the processing pipeline's configuration immediately after the line that builds the app: ```csharp app.UseResponseCompression(); @@ -457,7 +457,7 @@ Add the namespace for the `ChatHub` class to the top of the file: using BlazorWebAssemblySignalRApp.Server.Hubs; ``` -Add SignalR and Response Compression Middleware services: +Add SignalR and response compression middleware services: ```csharp services.AddSignalR(); @@ -468,7 +468,7 @@ services.AddResponseCompression(opts => }); ``` -Use Response Compression Middleware at the top of the processing pipeline's configuration: +Use response compression middleware at the top of the processing pipeline's configuration: ```csharp app.UseResponseCompression(); @@ -519,7 +519,7 @@ Replace the markup with the following code: :::moniker range=">= aspnetcore-6.0 < aspnetcore-8.0" > [!NOTE] -> Disable Response Compression Middleware in the `Development` environment when using [Hot Reload](xref:test/hot-reload). For more information, see . +> Disable response compression middleware in the `Development` environment when using [Hot Reload](xref:test/hot-reload). For more information, see . :::moniker-end diff --git a/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md b/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md index 7f9d0cee9dd9..70c792d58a26 100644 --- a/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md +++ b/aspnetcore/breaking-changes/5/middleware-exception-handler-throws-original-exception.md @@ -1,13 +1,13 @@ --- -title: "Breaking change: Middleware: Exception Handler Middleware throws original exception if handler not found" -description: "Learn about the breaking change in ASP.NET Core 5.0 titled Middleware: Exception Handler Middleware throws original exception if handler not found" +title: "Breaking change: Middleware: Exception handler middleware throws original exception if handler not found" +description: "Learn about the breaking change in ASP.NET Core 5.0 titled Middleware: Exception handler middleware throws original exception if handler not found" ms.author: wpickett ms.date: 10/01/2020 ms.custom: https://github.com/aspnet/Announcements/issues/434 --- -# Middleware: Exception Handler Middleware throws original exception if handler not found +# Middleware: Exception handler middleware throws original exception if handler not found -Before ASP.NET Core 5.0, the [Exception Handler Middleware](xref:Microsoft.AspNetCore.Builder.ExceptionHandlerExtensions.UseExceptionHandler%2A) executes the configured exception handler when an exception has occurred. If the exception handler, configured via , can't be found, an HTTP 404 response is produced. The response is misleading in that it: +Before ASP.NET Core 5.0, the [exception handler middleware](xref:Microsoft.AspNetCore.Builder.ExceptionHandlerExtensions.UseExceptionHandler%2A) executes the configured exception handler when an exception has occurred. If the exception handler, configured via , can't be found, an HTTP 404 response is produced. The response is misleading in that it: * Seems to be a user error. * Obscures the fact that an exception occurred on the server. @@ -22,11 +22,11 @@ For discussion, see GitHub issue [dotnet/aspnetcore#25288](https://github.com/do ## Old behavior -The Exception Handler Middleware produces an HTTP 404 response if the configured exception handler can't be found. +The exception handler middleware produces an HTTP 404 response if the configured exception handler can't be found. ## New behavior -The Exception Handler Middleware throws the original exception if the configured exception handler can't be found. +The exception handler middleware throws the original exception if the configured exception handler can't be found. ## Reason for change diff --git a/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md b/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md index 2a543de4945a..40c54ce91c11 100644 --- a/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md +++ b/aspnetcore/breaking-changes/5/static-files-csv-content-type-changed.md @@ -7,7 +7,7 @@ ms.custom: https://github.com/aspnet/Announcements/issues/395 --- # Static files: CSV content type changed to standards-compliant -In ASP.NET Core 5.0, the default `Content-Type` response header value that the [Static File Middleware](/aspnet/core/fundamentals/static-files) uses for *.csv* files has changed to the standards-compliant value `text/csv`. +In ASP.NET Core 5.0, the default `Content-Type` response header value that the [static file middleware](/aspnet/core/fundamentals/static-files) uses for *.csv* files has changed to the standards-compliant value `text/csv`. For discussion on this issue, see [dotnet/aspnetcore#17385](https://github.com/dotnet/AspNetCore/issues/17385). diff --git a/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md b/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md index 45d703c09a1c..1947353d6eae 100644 --- a/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md +++ b/aspnetcore/breaking-changes/6/middleware-ambiguous-https-ports-exception.md @@ -1,13 +1,13 @@ --- -title: "Breaking change: Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports" -description: "Learn about the breaking change in ASP.NET Core 6.0 titled Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports" +title: "Breaking change: Middleware: HTTPS redirection middleware throws exception on ambiguous HTTPS ports" +description: "Learn about the breaking change in ASP.NET Core 6.0 titled Middleware: HTTPS redirection middleware throws exception on ambiguous HTTPS ports" ms.author: wpickett ms.date: 02/04/2021 ms.custom: https://github.com/aspnet/Announcements/issues/448 --- -# Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports +# Middleware: HTTPS redirection middleware throws exception on ambiguous HTTPS ports -In ASP.NET Core 6.0, the [HTTPS Redirection Middleware](xref:Microsoft.AspNetCore.Builder.HttpsPolicyBuilderExtensions.UseHttpsRedirection%2A) throws an exception of type when it finds multiple HTTPS ports in the server configuration. The exception's message contains the text "Cannot determine the https port from IServerAddressesFeature, multiple values were found. Set the desired port explicitly on HttpsRedirectionOptions.HttpsPort." +In ASP.NET Core 6.0, the [HTTPS redirection middleware](xref:Microsoft.AspNetCore.Builder.HttpsPolicyBuilderExtensions.UseHttpsRedirection%2A) throws an exception of type when it finds multiple HTTPS ports in the server configuration. The exception's message contains the text "Cannot determine the https port from IServerAddressesFeature, multiple values were found. Set the desired port explicitly on HttpsRedirectionOptions.HttpsPort." For discussion, see GitHub issue [dotnet/aspnetcore#29222](https://github.com/dotnet/aspnetcore/issues/29222). @@ -17,13 +17,13 @@ ASP.NET Core 6.0 ## Old behavior -When the HTTPS Redirection Middleware isn't explicitly configured with a port, it searches during the first request to determine the HTTPS port to which it should redirect. +When the HTTPS redirection middleware isn't explicitly configured with a port, it searches during the first request to determine the HTTPS port to which it should redirect. If there are no HTTPS ports or multiple distinct ports, it's unclear which port should be used. The middleware logs a warning and disables itself. HTTP requests are processed normally. ## New behavior -When the HTTPS Redirection Middleware isn't explicitly configured with a port, it searches `IServerAddressesFeature` during the first request to determine the HTTPS port to which it should redirect. +When the HTTPS redirection middleware isn't explicitly configured with a port, it searches `IServerAddressesFeature` during the first request to determine the HTTPS port to which it should redirect. If there are no HTTPS ports, the middleware still logs a warning and disables itself. HTTP requests are processed normally. This behavior supports: @@ -40,7 +40,7 @@ This change prevents potentially sensitive data from being served over unencrypt To enable HTTPS redirection when the server has multiple distinct HTTPS ports, you must specify one port in the configuration. For more information, see [Port configuration](/aspnet/core/security/enforcing-ssl?view=aspnetcore-5.0&preserve-view=true#port-configuration). -If you don't need the HTTPS Redirection Middleware in your app, remove `UseHttpsRedirection` from *Startup.cs*. +If you don't need the HTTPS redirection middleware in your app, remove `UseHttpsRedirection` from *Startup.cs*. If you need to select the correct HTTPS port dynamically, provide feedback in GitHub issue [dotnet/aspnetcore#21291](https://github.com/dotnet/aspnetcore/issues/21291). diff --git a/aspnetcore/breaking-changes/6/overview.md b/aspnetcore/breaking-changes/6/overview.md index 94b5c3e381fa..5ffaa6e59720 100644 --- a/aspnetcore/breaking-changes/6/overview.md +++ b/aspnetcore/breaking-changes/6/overview.md @@ -25,7 +25,7 @@ If you're migrating an app to ASP.NET Core 6, the breaking changes listed here m | [Identity: Default Bootstrap version of UI changed](identity-bootstrap4-to-5.md) | ❌ | ❌ | | [Kestrel: Log message attributes changed](kestrel-log-message-attributes-changed.md) | ✔️ | ❌ | | [Microsoft.AspNetCore.Http.Features split](microsoft-aspnetcore-http-features-package-split.md) | ❌ | ✔️ | -| [Middleware: HTTPS Redirection Middleware throws exception on ambiguous HTTPS ports](middleware-ambiguous-https-ports-exception.md) | ✔️ | ❌ | +| [Middleware: HTTPS redirection middleware throws exception on ambiguous HTTPS ports](middleware-ambiguous-https-ports-exception.md) | ✔️ | ❌ | | [Middleware: New Use overload](middleware-new-use-overload.md) | ✔️ | ❌ | | [Minimal API renames in RC 1](rc1-minimal-api-renames.md) | ❌ | ❌ | | [Minimal API renames in RC 2](rc2-minimal-api-renames.md) | ❌ | ❌ | diff --git a/aspnetcore/breaking-changes/8/forwarded-headers-unknown-proxies.md b/aspnetcore/breaking-changes/8/forwarded-headers-unknown-proxies.md index a59eafdcafdb..e05c20e19c90 100644 --- a/aspnetcore/breaking-changes/8/forwarded-headers-unknown-proxies.md +++ b/aspnetcore/breaking-changes/8/forwarded-headers-unknown-proxies.md @@ -1,12 +1,12 @@ --- -title: "Breaking change: Forwarded Headers Middleware ignores X-Forwarded-* headers from unknown proxies" -description: Learn about the breaking change in ASP.NET Core where Forwarded Headers Middleware now ignores headers from proxies that aren't explicitly configured as trusted. +title: "Breaking change: Forwarded headers middleware ignores X-Forwarded-* headers from unknown proxies" +description: Learn about the breaking change in ASP.NET Core where forwarded headers middleware now ignores headers from proxies that aren't explicitly configured as trusted. ms.date: 08/15/2025 ms.custom: https://github.com/aspnet/Announcements/issues/517 --- -# Forwarded Headers Middleware ignores X-Forwarded-* headers from unknown proxies +# Forwarded headers middleware ignores X-Forwarded-* headers from unknown proxies -Starting in ASP.NET Core 8.0.17 and 9.0.6, the Forwarded Headers Middleware ignores all `X-Forwarded-*` headers from proxies that aren't explicitly configured as trusted. This change was made for security hardening, as the proxy and IP lists weren't being applied in all cases. +Starting in ASP.NET Core 8.0.17 and 9.0.6, the forwarded headers middleware ignores all `X-Forwarded-*` headers from proxies that aren't explicitly configured as trusted. This change was made for security hardening, as the proxy and IP lists weren't being applied in all cases. ## Version introduced diff --git a/aspnetcore/breaking-changes/8/overview.md b/aspnetcore/breaking-changes/8/overview.md index 6f90e865fd1e..5ac539c93cf6 100644 --- a/aspnetcore/breaking-changes/8/overview.md +++ b/aspnetcore/breaking-changes/8/overview.md @@ -15,7 +15,7 @@ If you're migrating an app to ASP.NET Core 8, the breaking changes listed here m | ---------------------------------------------------------------------------------------------------- | ------------------- | | [ConcurrencyLimiterMiddleware is obsolete](concurrencylimitermiddleware-obsolete.md) | Source incompatible | | [Custom converters for serialization removed](problemdetails-custom-converters.md) | Behavioral change | -| [Forwarded Headers Middleware ignores X-Forwarded-* headers from unknown proxies](forwarded-headers-unknown-proxies.md) | Behavioral change | +| [Forwarded headers middleware ignores X-Forwarded-* headers from unknown proxies](forwarded-headers-unknown-proxies.md) | Behavioral change | | [HTTP logging middleware requires AddHttpLogging()](httplogging-addhttplogging-requirement.md) | Behavioral change | | [ISystemClock is obsolete](isystemclock-obsolete.md) | Source incompatible | | [Minimal APIs: IFormFile parameters require anti-forgery checks](antiforgery-checks.md) | Behavioral change | diff --git a/aspnetcore/breaking-changes/9/overview.md b/aspnetcore/breaking-changes/9/overview.md index 625e837a0214..c10c7c401d97 100644 --- a/aspnetcore/breaking-changes/9/overview.md +++ b/aspnetcore/breaking-changes/9/overview.md @@ -15,7 +15,7 @@ If you're migrating an app to ASP.NET Core 9, the breaking changes listed here m |--------------------------------------------------------------------------------|-------------------| | [DefaultKeyResolution.ShouldGenerateNewKey altered meaning](key-resolution.md) | Behavioral change | | [Dev cert export no longer creates folder](certificate-export.md) | Behavioral change | -| [Forwarded Headers Middleware ignores X-Forwarded-* headers from unknown proxies](../8/forwarded-headers-unknown-proxies.md) | Behavioral change | +| [Forwarded headers middleware ignores X-Forwarded-* headers from unknown proxies](../8/forwarded-headers-unknown-proxies.md) | Behavioral change | | [HostBuilder enables ValidateOnBuild/ValidateScopes in development environment](hostbuilder-validation.md) | Behavioral change | | [Legacy Mono and Emscripten APIs not exported to global namespace](legacy-apis.md) | Source incompatible | | [Middleware types with multiple constructors](middleware-constructors.md) | Behavioral change | diff --git a/aspnetcore/client-side/spa-services.md b/aspnetcore/client-side/spa-services.md index 7b7204963740..dc53d27f5549 100644 --- a/aspnetcore/client-side/spa-services.md +++ b/aspnetcore/client-side/spa-services.md @@ -45,7 +45,7 @@ SpaServices was created to position ASP.NET Core as developers' preferred server SpaServices provides useful infrastructure such as: * [Server-side prerendering](#server-side-prerendering) -* [Webpack Dev Middleware](#webpack-dev-middleware) +* [Webpack dev middleware](#webpack-dev-middleware) * [Hot Module Replacement](#hot-module-replacement) * [Routing helpers](#routing-helpers) @@ -125,15 +125,15 @@ The `postList` array defined inside the `globals` object is attached to the brow ![global postList variable attached to window object](spa-services/_static/global_variable.png) -## Webpack Dev Middleware +## Webpack dev middleware -[Webpack Dev Middleware](https://webpack.js.org/guides/development/#using-webpack-dev-middleware) introduces a streamlined development workflow whereby Webpack builds resources on demand. The middleware automatically compiles and serves client-side resources when a page is reloaded in the browser. The alternate approach is to manually invoke Webpack via the project's npm build script when a third-party dependency or the custom code changes. An npm build script in the `package.json` file is shown in the following example: +[Webpack dev middleware](https://webpack.js.org/guides/development/#using-webpack-dev-middleware) introduces a streamlined development workflow whereby Webpack builds resources on demand. The middleware automatically compiles and serves client-side resources when a page is reloaded in the browser. The alternate approach is to manually invoke Webpack via the project's npm build script when a third-party dependency or the custom code changes. An npm build script in the `package.json` file is shown in the following example: ```json "build": "npm run build:vendor && npm run build:custom", ``` -### Webpack Dev Middleware prerequisites +### Webpack dev middleware prerequisites Install the [aspnet-webpack](https://www.npmjs.com/package/aspnet-webpack) npm package: @@ -141,9 +141,9 @@ Install the [aspnet-webpack](https://www.npmjs.com/package/aspnet-webpack) npm p npm i -D aspnet-webpack ``` -### Webpack Dev Middleware configuration +### Webpack dev middleware configuration -Webpack Dev Middleware is registered into the HTTP request pipeline via the following code in the `Startup.cs` file's `Configure` method: +Webpack dev middleware is registered into the HTTP request pipeline via the following code in the `Startup.cs` file's `Configure` method: [!code-csharp[](../client-side/spa-services/sample/SpaServicesSampleApp/Startup.cs?name=snippet_WebpackMiddlewareRegistration&highlight=4)] @@ -155,7 +155,7 @@ The `webpack.config.js` file's `output.publicPath` property tells the middleware ## Hot Module Replacement -Think of Webpack's [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/) (HMR) feature as an evolution of [Webpack Dev Middleware](#webpack-dev-middleware). HMR introduces all the same benefits, but it further streamlines the development workflow by automatically updating page content after compiling the changes. Don't confuse this with a refresh of the browser, which would interfere with the current in-memory state and debugging session of the SPA. There's a live link between the Webpack Dev Middleware service and the browser, which means changes are pushed to the browser. +Think of Webpack's [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/) (HMR) feature as an evolution of [webpack dev middleware](#webpack-dev-middleware). HMR introduces all the same benefits, but it further streamlines the development workflow by automatically updating page content after compiling the changes. Don't confuse this with a refresh of the browser, which would interfere with the current in-memory state and debugging session of the SPA. There's a live link between the webpack dev middleware service and the browser, which means changes are pushed to the browser. ### Hot Module Replacement prerequisites @@ -175,7 +175,7 @@ app.UseWebpackDevMiddleware(new WebpackDevMiddlewareOptions { }); ``` -As was true with [Webpack Dev Middleware](#webpack-dev-middleware), the `UseWebpackDevMiddleware` extension method must be called before the `UseStaticFiles` extension method. For security reasons, register the middleware only when the app runs in development mode. +As was true with [webpack dev middleware](#webpack-dev-middleware), the `UseWebpackDevMiddleware` extension method must be called before the `UseStaticFiles` extension method. For security reasons, register the middleware only when the app runs in development mode. The `webpack.config.js` file must define a `plugins` array, even if it's left empty: @@ -266,7 +266,7 @@ Open the `.csproj` file generated by the [dotnet new](/dotnet/core/tools/dotnet- ## Test the app -SpaServices templates are pre-configured to run client-side tests using [Karma](https://karma-runner.github.io/1.0/index.html) and [Jasmine](https://jasmine.github.io/). Jasmine is a popular unit testing framework for JavaScript, whereas Karma is a test runner for those tests. Karma is configured to work with the [Webpack Dev Middleware](#webpack-dev-middleware) such that the developer isn't required to stop and run the test every time changes are made. Whether it's the code running against the test case or the test case itself, the test runs automatically. +SpaServices templates are pre-configured to run client-side tests using [Karma](https://karma-runner.github.io/1.0/index.html) and [Jasmine](https://jasmine.github.io/). Jasmine is a popular unit testing framework for JavaScript, whereas Karma is a test runner for those tests. Karma is configured to work with the [webpack dev middleware](#webpack-dev-middleware) such that the developer isn't required to stop and run the test every time changes are made. Whether it's the code running against the test case or the test case itself, the test runs automatically. Using the Angular application as an example, two Jasmine test cases are already provided for the `CounterComponent` in the `counter.component.spec.ts` file: diff --git a/aspnetcore/client-side/spa/includes/intro6-7.md b/aspnetcore/client-side/spa/includes/intro6-7.md index cec06996a12d..1d6430869bc2 100644 --- a/aspnetcore/client-side/spa/includes/intro6-7.md +++ b/aspnetcore/client-side/spa/includes/intro6-7.md @@ -5,7 +5,7 @@ The Single Page Application (SPA) templates for [Angular](https://angular.dev/) and [React](https://reactjs.org/) offer the ability to develop Angular and React apps that are hosted inside a .NET backend server. -At publish time, the files of the Angular and React app are copied to the `wwwroot` folder and are served via the [Static File Middleware](xref:fundamentals/static-files). +At publish time, the files of the Angular and React app are copied to the `wwwroot` folder and are served via the [static file middleware](xref:fundamentals/static-files). Rather than returning HTTP 404 (Not Found), a fallback route handles unknown requests to the backend and serves the `index.html` for the SPA. diff --git a/aspnetcore/diagnostics/mvc1005.md b/aspnetcore/diagnostics/mvc1005.md index b5785800ca6d..30c00f42602f 100644 --- a/aspnetcore/diagnostics/mvc1005.md +++ b/aspnetcore/diagnostics/mvc1005.md @@ -20,7 +20,7 @@ UseMvc was invoked as part of startup. ### Rule description -Using MVC via or requires an explicit opt-in inside `Startup.ConfigureServices`. This is required because MVC must know whether it can rely on the authorization and CORS Middleware during initialization. +Using MVC via or requires an explicit opt-in inside `Startup.ConfigureServices`. This is required because MVC must know whether it can rely on the authorization and CORS middleware during initialization. ## How to fix violations diff --git a/aspnetcore/fundamentals/app-state.md b/aspnetcore/fundamentals/app-state.md index cfbd7b1cd1d9..fd8e9f1a1b51 100644 --- a/aspnetcore/fundamentals/app-state.md +++ b/aspnetcore/fundamentals/app-state.md @@ -122,7 +122,7 @@ To override cookie session defaults, use property to determine how long a session can be idle before its contents in the server's cache are abandoned. This property is independent of the cookie expiration. Each request that passes through the [Session Middleware](xref:Microsoft.AspNetCore.Session.SessionMiddleware) resets the timeout. +The app uses the property to determine how long a session can be idle before its contents in the server's cache are abandoned. This property is independent of the cookie expiration. Each request that passes through the [session middleware](xref:Microsoft.AspNetCore.Session.SessionMiddleware) resets the timeout. Session state is *non-locking*. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. `Session` is implemented as a *coherent session*, which means that all the contents are stored together. When two requests seek to modify different session values, the last request may override session changes made by the first. @@ -406,7 +406,7 @@ To override cookie session defaults, use property to determine how long a session can be idle before its contents in the server's cache are abandoned. This property is independent of the cookie expiration. Each request that passes through the [Session Middleware](xref:Microsoft.AspNetCore.Session.SessionMiddleware) resets the timeout. +The app uses the property to determine how long a session can be idle before its contents in the server's cache are abandoned. This property is independent of the cookie expiration. Each request that passes through the [session middleware](xref:Microsoft.AspNetCore.Session.SessionMiddleware) resets the timeout. Session state is *non-locking*. If two requests simultaneously attempt to modify the contents of a session, the last request overrides the first. `Session` is implemented as a *coherent session*, which means that all the contents are stored together. When two requests seek to modify different session values, the last request may override session changes made by the first. diff --git a/aspnetcore/fundamentals/configuration/index.md b/aspnetcore/fundamentals/configuration/index.md index 9a0316801c81..b801a73b4d18 100644 --- a/aspnetcore/fundamentals/configuration/index.md +++ b/aspnetcore/fundamentals/configuration/index.md @@ -131,8 +131,8 @@ Default host configuration sources from highest to lowest priority for the [Web * Command-line arguments using the [Command-line Configuration Provider](#command-line). * Web Host default configuration () * Kestrel is used as the web server and configured using the app's configuration providers. - * Add [Host Filtering Middleware](xref:fundamentals/servers/kestrel/host-filtering). - * Add [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer#forwarded-headers) if the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` environment variable is set to `true`. + * Add [host-filtering middleware](xref:fundamentals/servers/kestrel/host-filtering). + * Add [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer#forwarded-headers) if the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` environment variable is set to `true`. * Enable IIS integration. :::moniker-end diff --git a/aspnetcore/fundamentals/environments.md b/aspnetcore/fundamentals/environments.md index a51269e8ccab..ebc4446ea0c1 100644 --- a/aspnetcore/fundamentals/environments.md +++ b/aspnetcore/fundamentals/environments.md @@ -86,8 +86,8 @@ Use to distinguish the environment. -* Calls , which adds [Exception Handler Middleware](xref:fundamentals/error-handling) to the request processing pipeline to handle exceptions. -* Calls , which adds [HSTS Middleware](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) to apply the [`Strict-Transport-Security` header](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security). +* Calls , which adds [exception handler middleware](xref:fundamentals/error-handling) to the request processing pipeline to handle exceptions. +* Calls , which adds [HSTS middleware](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) to apply the [`Strict-Transport-Security` header](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Strict-Transport-Security). ```csharp if (!app.Environment.IsDevelopment()) @@ -109,7 +109,7 @@ The following code in `Startup.Configure`: * Injects into `Startup.Configure` to tailor the code to the environment. This approach is useful when the app only requires adjusting `Startup.Configure` for a few environments with minimal code differences per environment. When many code differences exist per environment, consider using [accessing the environment from a `Startup` class](#access-the-environment-from-a-startup-class), which is covered later in this article. * Calls when `ASPNETCORE_ENVIRONMENT` is set to `Development`. The call adds middleware that captures exceptions and generates HTML error responses. -* Calls when the value of `ASPNETCORE_ENVIRONMENT` is set to `Production`, `Staging`, or `Testing`. The call adds [Exception Handler Middleware](xref:fundamentals/error-handling) to the pipeline to handle exceptions. +* Calls when the value of `ASPNETCORE_ENVIRONMENT` is set to `Production`, `Staging`, or `Testing`. The call adds [exception handler middleware](xref:fundamentals/error-handling) to the pipeline to handle exceptions. ```csharp public void Configure(IApplicationBuilder app, IWebHostEnvironment env) diff --git a/aspnetcore/fundamentals/error-handling-api.md b/aspnetcore/fundamentals/error-handling-api.md index 90c1c49d63b2..5a20c0a753de 100644 --- a/aspnetcore/fundamentals/error-handling-api.md +++ b/aspnetcore/fundamentals/error-handling-api.md @@ -53,17 +53,17 @@ To see the Developer Exception Page in a controller-based API: ## Exception handler -In non-development environments, use the [Exception Handler Middleware](xref:fundamentals/error-handling#exception-handler-page) to produce an error payload. +In non-development environments, use the [exception handler middleware](xref:fundamentals/error-handling#exception-handler-page) to produce an error payload. #### [Minimal APIs](#tab/minimal-apis) -To configure the `Exception Handler Middleware`, call . For example, the following code changes the app to respond with an [RFC 7807](https://tools.ietf.org/html/rfc7807)-compliant payload to the client. For more information, see the [Problem Details](#problem-details) section later in this article. +To configure the `exception handler middleware`, call . For example, the following code changes the app to respond with an [RFC 7807](https://tools.ietf.org/html/rfc7807)-compliant payload to the client. For more information, see the [Problem Details](#problem-details) section later in this article. :::code language="csharp" source="~/fundamentals/minimal-apis/handle-errors/sample8/Program.cs" id="snippet_WithUseExceptionHandler" highlight="4-7"::: #### [Controllers](#tab/controllers) -1. In `Program.cs`, call to add the Exception Handling Middleware: +1. In `Program.cs`, call to add the exception handling middleware: :::code language="csharp" source="~/web-api/handle-errors/samples/6.x/HandleErrorsSample/Program.cs" id="snippet_Middleware" highlight="7"::: @@ -140,7 +140,7 @@ In the following code, `httpContext.Response.WriteAsync("Fallback: An error occu The preceding code: * Writes an error message with the fallback code if the `problemDetailsService` is unable to write a `ProblemDetails`. For example, an endpoint where the [Accept request header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Accept) specifies a media type that the `DefaultProblemDetailsWriter` does not support. -* Uses the [Exception Handler Middleware](#exception-handler). +* Uses the [exception handler middleware](#exception-handler). > [!NOTE] > The `DefaultProblemDetailsWriter` supports the following media types in the `Accept` request header: diff --git a/aspnetcore/fundamentals/error-handling.md b/aspnetcore/fundamentals/error-handling.md index df38116d56d0..2c97abe01052 100644 --- a/aspnetcore/fundamentals/error-handling.md +++ b/aspnetcore/fundamentals/error-handling.md @@ -31,7 +31,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. Since this middleware can re-execute the request pipeline: @@ -139,7 +139,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/7.x/ErrorHandlingSample/Snippets/Program.cs" id="snippet_UseStatusCodePages" highlight="9"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When `UseStatusCodePages` is called, the browser returns the following response: @@ -319,7 +319,7 @@ An implementation can be :::code language="csharp" source="~/../AspNetCore.Docs.Samples/fundamentals/middleware/problem-details-service/Program.cs" id="snippet_sampleproblemdetailswriter" ::: -#### Problem details from Middleware +#### Problem details from middleware An alternative approach to using with is to set the in middleware. A problem details response can be written by calling [`IProblemDetailsService.WriteAsync`](/dotnet/api/microsoft.aspnetcore.http.iproblemdetailsservice.writeasync?view=aspnetcore-7.0&preserve-view=true): diff --git a/aspnetcore/fundamentals/error-handling/includes/error-handling3-7.md b/aspnetcore/fundamentals/error-handling/includes/error-handling3-7.md index deac48d06e00..8acc6bf0c66e 100644 --- a/aspnetcore/fundamentals/error-handling/includes/error-handling3-7.md +++ b/aspnetcore/fundamentals/error-handling/includes/error-handling3-7.md @@ -32,7 +32,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. Since this middleware can re-execute the request pipeline: @@ -84,7 +84,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/7.x/ErrorHandlingSample/Snippets/Program.cs" id="snippet_UseStatusCodePages" highlight="9"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When `UseStatusCodePages` is called, the browser returns the following response: @@ -351,7 +351,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. In the following example, adds the exception handling middleware in non-`Development` environments: @@ -394,7 +394,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/6.x/ErrorHandlingSample/Snippets/Program.cs" id="snippet_UseStatusCodePages" highlight="9"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When `UseStatusCodePages` is called, the browser returns the following response: @@ -561,7 +561,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. In the following example, adds the exception handling middleware in non-`Development` environments: @@ -620,7 +620,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/5.x/ErrorHandlingSample/StartupUseStatusCodePages.cs" id="snippet" highlight="13"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. For example, navigating to `Home/Privacy2`. When `UseStatusCodePages` is called, the browser returns: @@ -810,12 +810,12 @@ The Developer Exception Page includes the following information about the except ## Exception handler page -To configure a custom error handling page for the `Production` environment, use the Exception Handling Middleware. The middleware: +To configure a custom error handling page for the `Production` environment, use the exception handling middleware. The middleware: * Catches and logs exceptions. * Re-executes the request in an alternate pipeline for the page or controller indicated. The request isn't re-executed if the response has started. The template generated code re-executes the request to `/Error`. -In the following example, adds the Exception Handling Middleware in non-`Development` environments: +In the following example, adds the exception handling middleware in non-`Development` environments: :::code language="csharp" source="~/fundamentals/error-handling/samples/2.x/ErrorHandlingSample/Startup.cs" id="snippet_DevPageAndHandlerPage" highlight="5-9"::: @@ -859,7 +859,7 @@ To enable default text-only handlers for common error status codes, call . > [!TIP] -> Exception filters are useful for trapping exceptions that occur within MVC actions, but they're not as flexible as the Exception Handling Middleware. We recommend using the middleware. Use filters only where you need to perform error handling differently based on which MVC action is chosen. +> Exception filters are useful for trapping exceptions that occur within MVC actions, but they're not as flexible as the exception handling middleware. We recommend using the middleware. Use filters only where you need to perform error handling differently based on which MVC action is chosen. ## Model state errors diff --git a/aspnetcore/fundamentals/error-handling/includes/error-handling8.md b/aspnetcore/fundamentals/error-handling/includes/error-handling8.md index 30de4445f7d8..c50db2c9149d 100644 --- a/aspnetcore/fundamentals/error-handling/includes/error-handling8.md +++ b/aspnetcore/fundamentals/error-handling/includes/error-handling8.md @@ -33,7 +33,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. Since this middleware can re-execute the request pipeline: @@ -111,7 +111,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/7.x/ErrorHandlingSample/Snippets/Program.cs" id="snippet_UseStatusCodePages" highlight="9"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When `UseStatusCodePages` is called, the browser returns the following response: diff --git a/aspnetcore/fundamentals/error-handling/includes/error-handling9.md b/aspnetcore/fundamentals/error-handling/includes/error-handling9.md index 214ce8566ad7..5d22c2109bd3 100644 --- a/aspnetcore/fundamentals/error-handling/includes/error-handling9.md +++ b/aspnetcore/fundamentals/error-handling/includes/error-handling9.md @@ -16,7 +16,7 @@ To configure a custom error handling page for the [`Production` environment](xre * Re-executes the request in an alternate pipeline using the path indicated. The request isn't re-executed if the response has started. The template-generated code re-executes the request using the `/Error` path. > [!WARNING] -> If the alternate pipeline throws an exception of its own, Exception Handling Middleware rethrows the original exception. +> If the alternate pipeline throws an exception of its own, exception handling middleware rethrows the original exception. Since this middleware can re-execute the request pipeline: @@ -98,7 +98,7 @@ By default, an ASP.NET Core app doesn't provide a status code page for HTTP erro :::code language="csharp" source="~/fundamentals/error-handling/samples/7.x/ErrorHandlingSample/Snippets/Program.cs" id="snippet_UseStatusCodePages" highlight="9"::: -Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the Static File Middleware and the Endpoints Middleware. +Call `UseStatusCodePages` before request handling middleware. For example, call `UseStatusCodePages` before the static file middleware and the endpoints middleware. When `UseStatusCodePages` isn't used, navigating to a URL without an endpoint returns a browser-dependent error message indicating the endpoint can't be found. When `UseStatusCodePages` is called, the browser returns the following response: diff --git a/aspnetcore/fundamentals/file-providers.md b/aspnetcore/fundamentals/file-providers.md index ba6aecb65dc6..38285794aa1f 100644 --- a/aspnetcore/fundamentals/file-providers.md +++ b/aspnetcore/fundamentals/file-providers.md @@ -19,7 +19,7 @@ By [Steve Smith](https://ardalis.com/) ASP.NET Core abstracts file system access through the use of File Providers. File Providers are used throughout the ASP.NET Core framework. For example: * exposes the app's [content root](xref:fundamentals/index#content-root) and [web root](xref:fundamentals/index#web-root) as `IFileProvider` types. -* [Static File Middleware](xref:fundamentals/static-files) uses File Providers to locate static files. +* [Static file middleware](xref:fundamentals/static-files) uses File Providers to locate static files. * [Razor](xref:mvc/views/razor) uses File Providers to locate pages and views. * .NET tooling uses File Providers and glob patterns to specify which files should be published. @@ -173,7 +173,7 @@ The following table provides common examples of glob patterns. ASP.NET Core abstracts file system access through the use of File Providers. File Providers are used throughout the ASP.NET Core framework: * exposes the app's [content root](xref:fundamentals/index#content-root) and [web root](xref:fundamentals/index#web-root) as `IFileProvider` types. -* [Static File Middleware](xref:fundamentals/static-files) uses File Providers to locate static files. +* [Static file middleware](xref:fundamentals/static-files) uses File Providers to locate static files. * [Razor](xref:mvc/views/razor) uses File Providers to locate pages and views. * .NET tooling uses File Providers and glob patterns to specify which files should be published. diff --git a/aspnetcore/fundamentals/host/generic-host.md b/aspnetcore/fundamentals/host/generic-host.md index a413e4711b9c..c11ee1961ccf 100644 --- a/aspnetcore/fundamentals/host/generic-host.md +++ b/aspnetcore/fundamentals/host/generic-host.md @@ -146,7 +146,7 @@ The . -* Adds [Host Filtering middleware](xref:fundamentals/servers/kestrel/host-filtering). +* Adds [host-filtering middleware](xref:fundamentals/servers/kestrel/host-filtering). * Adds [Forwarded Headers middleware](xref:host-and-deploy/proxy-load-balancer#forwarded-headers) if the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` property is set to `true`. diff --git a/aspnetcore/fundamentals/index.md b/aspnetcore/fundamentals/index.md index c45cd514c2e0..ad15b0d05136 100644 --- a/aspnetcore/fundamentals/index.md +++ b/aspnetcore/fundamentals/index.md @@ -145,7 +145,7 @@ For more information, see . Execution environments, such as `Development`, `Staging`, and `Production`, are available in ASP.NET Core. Specify the environment an app is running in by setting the `ASPNETCORE_ENVIRONMENT` environment variable. ASP.NET Core reads that environment variable at app startup and stores the value in an `IWebHostEnvironment` implementation. This implementation is available anywhere in an app via dependency injection (DI). -The following example configures the exception handler and [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) middleware when ***not*** running in the `Development` environment: +The following example configures the exception handler and [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) middleware when ***not*** running in the `Development` environment: :::code language="csharp" source="~/fundamentals/index/samples/9.0/BlazorWebAppMovies/Program.cs" id="snippet_environments" highlight="1"::: diff --git a/aspnetcore/fundamentals/index/includes/index3-7.md b/aspnetcore/fundamentals/index/includes/index3-7.md index bff15a98f762..fbf7036dfc61 100644 --- a/aspnetcore/fundamentals/index/includes/index3-7.md +++ b/aspnetcore/fundamentals/index/includes/index3-7.md @@ -116,7 +116,7 @@ For more information, see . Execution environments, such as `Development`, `Staging`, and `Production`, are available in ASP.NET Core. Specify the environment an app is running in by setting the `ASPNETCORE_ENVIRONMENT` environment variable. ASP.NET Core reads that environment variable at app startup and stores the value in an `IWebHostEnvironment` implementation. This implementation is available anywhere in an app via dependency injection (DI). -The following example configures the exception handler and [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) middleware when ***not*** running in the `Development` environment: +The following example configures the exception handler and [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) middleware when ***not*** running in the `Development` environment: [!code-csharp[](~/fundamentals/startup/6.0_samples/WebAll/Program.cs?name=snippet&highlight=10-14)] diff --git a/aspnetcore/fundamentals/index/includes/index8.md b/aspnetcore/fundamentals/index/includes/index8.md index 4185c3039849..0ec241984fc7 100644 --- a/aspnetcore/fundamentals/index/includes/index8.md +++ b/aspnetcore/fundamentals/index/includes/index8.md @@ -118,7 +118,7 @@ For more information, see . Execution environments, such as `Development`, `Staging`, and `Production`, are available in ASP.NET Core. Specify the environment an app is running in by setting the `ASPNETCORE_ENVIRONMENT` environment variable. ASP.NET Core reads that environment variable at app startup and stores the value in an `IWebHostEnvironment` implementation. This implementation is available anywhere in an app via dependency injection (DI). -The following example configures the exception handler and [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) middleware when ***not*** running in the `Development` environment: +The following example configures the exception handler and [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) middleware when ***not*** running in the `Development` environment: [!code-csharp[](~/fundamentals/startup/6.0_samples/WebAll/Program.cs?name=snippet&highlight=10-14)] diff --git a/aspnetcore/fundamentals/localization-extensibility.md b/aspnetcore/fundamentals/localization-extensibility.md index bb41fba1ad20..4fdadbfd5eb8 100644 --- a/aspnetcore/fundamentals/localization-extensibility.md +++ b/aspnetcore/fundamentals/localization-extensibility.md @@ -37,7 +37,7 @@ ASP.NET Core localization APIs have four default providers that can determine th * * -The preceding providers are described in detail in the [Localization Middleware](xref:fundamentals/localization) documentation. If the default providers don't meet your needs, build a custom provider using one of the following approaches: +The preceding providers are described in detail in the [localization middleware](xref:fundamentals/localization) documentation. If the default providers don't meet your needs, build a custom provider using one of the following approaches: ### Use CustomRequestCultureProvider diff --git a/aspnetcore/fundamentals/localization/includes/localization35.md b/aspnetcore/fundamentals/localization/includes/localization35.md index badfa25b2a3e..a1e5245f020d 100644 --- a/aspnetcore/fundamentals/localization/includes/localization35.md +++ b/aspnetcore/fundamentals/localization/includes/localization35.md @@ -251,7 +251,7 @@ Localization is configured in the `Startup.ConfigureServices` method: ### Localization middleware -The current culture on a request is set in the localization [Middleware](xref:fundamentals/middleware/index). The localization middleware is enabled in the `Startup.Configure` method. The localization middleware must be configured before any middleware that might check the request culture (for example, `app.UseMvcWithDefaultRoute()`). Localization Middleware must appear after Routing Middleware if using . For more information on middleware order, see . +The current culture on a request is set in the localization [Middleware](xref:fundamentals/middleware/index). The localization middleware is enabled in the `Startup.Configure` method. The localization middleware must be configured before any middleware that might check the request culture (for example, `app.UseMvcWithDefaultRoute()`). Localization middleware must appear after routing middleware if using . For more information on middleware order, see . [!code-csharp[](~/fundamentals/localization/sample/3.x/Localization/Startup.cs?name=snippet2)] diff --git a/aspnetcore/fundamentals/logging/index.md b/aspnetcore/fundamentals/logging/index.md index 75239357f010..3c6aa8211b8e 100644 --- a/aspnetcore/fundamentals/logging/index.md +++ b/aspnetcore/fundamentals/logging/index.md @@ -1466,9 +1466,9 @@ Diagnostics Host Filtering -* `Microsoft.AspNetCore.HostFiltering`: Hosts allowed and denied by the host filtering middleware. -* `Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware`: Logs related to the host filtering middleware, including allowed and denied hosts. -* `Microsoft.AspNetCore.HostFiltering.HostFilteringOptions`: Logs concerning options for the HostFiltering middleware. +* `Microsoft.AspNetCore.HostFiltering`: Hosts allowed and denied by the host-filtering middleware. +* `Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware`: Logs related to the host-filtering middleware, including allowed and denied hosts. +* `Microsoft.AspNetCore.HostFiltering.HostFilteringOptions`: Logs concerning options for the host-filtering middleware. Hosting diff --git a/aspnetcore/fundamentals/middleware/index.md b/aspnetcore/fundamentals/middleware/index.md index e817daf8801b..57e079d92849 100644 --- a/aspnetcore/fundamentals/middleware/index.md +++ b/aspnetcore/fundamentals/middleware/index.md @@ -1,5 +1,5 @@ --- -title: ASP.NET Core Middleware +title: ASP.NET Core middleware ai-usage: ai-assisted author: tdykstra description: Learn about ASP.NET Core middleware and the request pipeline. @@ -9,7 +9,7 @@ ms.custom: mvc ms.date: 06/09/2026 uid: fundamentals/middleware/index --- -# ASP.NET Core Middleware +# ASP.NET Core middleware [!INCLUDE[](~/includes/not-latest-version.md)] @@ -124,7 +124,7 @@ In the app's console window when the app is run: > :::no-loc text="Work that doesn't write to the response. (2)"::: > :::no-loc text="Work that doesn't write to the response. (1)"::: -*Short-circuiting* the request pipeline is often desirable because it avoids unnecessary work. For example, [Static File Middleware](xref:fundamentals/static-files) can act as a *terminal middleware* by processing a request for a static file and short-circuiting the rest of the pipeline. Middleware added to the pipeline before the terminal middleware still processes code after their `next.Invoke` statements. If you don't plan to call `next.Invoke` because your goal is to terminate the pipeline, use a [`Run` delegate](#run-delegate) instead of calling the extension method. +*Short-circuiting* the request pipeline is often desirable because it avoids unnecessary work. For example, [static file middleware](xref:fundamentals/static-files) can act as a *terminal middleware* by processing a request for a static file and short-circuiting the rest of the pipeline. Middleware added to the pipeline before the terminal middleware still processes code after their `next.Invoke` statements. If you don't plan to call `next.Invoke` because your goal is to terminate the pipeline, use a [`Run` delegate](#run-delegate) instead of calling the extension method. Don't call `next.Invoke` during or after the response is sent to the client. After an is started, changes result in an exception. For example, [setting headers or a response status code throw an exception](xref:fundamentals/best-practices#do-not-modify-the-status-code-or-headers-after-the-response-body-has-started) after the response starts. Writing to the response body after calling `next` may: @@ -361,7 +361,7 @@ app.Use(async (context, next) => }); ``` -When a delegate doesn't pass a request to the next delegate, it's called *short-circuiting the request pipeline*. Short-circuiting is often desirable because it avoids unnecessary work. For example, [Static File Middleware](xref:fundamentals/static-files) can act as a *terminal middleware* by processing a request for a static file and short-circuiting the rest of the pipeline. Middleware added to the pipeline before the middleware that terminates further processing still processes code after their `next.Invoke` statements. However, see the following warning about attempting to write to a response that has already been sent. +When a delegate doesn't pass a request to the next delegate, it's called *short-circuiting the request pipeline*. Short-circuiting is often desirable because it avoids unnecessary work. For example, [static file middleware](xref:fundamentals/static-files) can act as a *terminal middleware* by processing a request for a static file and short-circuiting the rest of the pipeline. Middleware added to the pipeline before the middleware that terminates further processing still processes code after their `next.Invoke` statements. However, see the following warning about attempting to write to a response that has already been sent. > [!WARNING] > Don't call `next.Invoke` after the response has been sent to the client. Changes to after the response has started throw an exception. For example, [setting headers and a status code throw an exception](xref:fundamentals/best-practices#do-not-modify-the-status-code-or-headers-after-the-response-body-has-started). Writing to the response body after calling `next`: @@ -549,20 +549,20 @@ The following examples demonstrate middleware order for common app scenarios. Ea 1. Exception/error handling * When the app runs in the `Development` environment: - * Developer Exception Page Middleware () reports app runtime errors. - * Database Error Page Middleware () reports database runtime errors. + * Developer exception page middleware () reports app runtime errors. + * Database error page middleware () reports database runtime errors. * When the app runs in the `Production` environment: - * Exception Handler Middleware () catches exceptions thrown in the following middlewares. - * HTTP Strict Transport Security Protocol (HSTS) Middleware () adds the `Strict-Transport-Security` header. -1. HTTPS Redirection Middleware () redirects HTTP requests to HTTPS. -1. Static File Middleware (if required, ) returns static files and short-circuits further request processing. -1. Cookie Policy Middleware () conforms the app to the EU General Data Protection Regulation (GDPR). -1. Routing Middleware () to route requests. -1. Authentication Middleware () attempts to authenticate the user before they're allowed access to secure resources. -1. Authorization Middleware () authorizes a user to access secure resources. -1. Antiforgery Middleware () adds antiforgery middleware to the pipeline must be placed after calls to and . -1. Session Middleware (Razor Pages and MVC only, ) establishes and maintains session state. If the app uses session state, call Session Middleware after Cookie Policy Middleware and before Razor Pages/MVC Middleware. -1. Endpoint Routing Middleware + * Exception handler middleware () catches exceptions thrown in the following middlewares. + * HTTP Strict Transport Security (HSTS) protocol middleware () adds the `Strict-Transport-Security` header. +1. HTTPS redirection middleware () redirects HTTP requests to HTTPS. +1. Static file middleware (if required, ) returns static files and short-circuits further request processing. +1. Cookie policy middleware () conforms the app to the EU General Data Protection Regulation (GDPR). +1. Routing middleware () to route requests. +1. Authentication middleware () attempts to authenticate the user before they're allowed access to secure resources. +1. Authorization middleware () authorizes a user to access secure resources. +1. Antiforgery middleware () adds antiforgery middleware to the pipeline must be placed after calls to and . +1. Session middleware (Razor Pages and MVC only, ) establishes and maintains session state. If the app uses session state, call session middleware after cookie policy middleware and before Razor Pages/MVC middleware. +1. Endpoint routing middleware * to add Razor component endpoints to the request pipeline. * to add Razor Pages endpoints to the request pipeline. * to add controller endpoints to the request pipeline. @@ -627,10 +627,10 @@ app.Run(); In the preceding code: -* CORS Middleware (), Authentication Middleware (), and Authorization Middleware () must appear in the order shown. -* CORS Middleware () must appear before Response Caching Middleware () to add CORS headers on every request, including cached responses. For more information, see [It is not clear that UseCORS must come before UseResponseCaching (`dotnet/aspnetcore` #23218](https://github.com/dotnet/aspnetcore/issues/23218). -* Request Localization Middleware () must appear before any middleware that might check the request culture, for example, Static File Middleware (). -* Rate Limiting Middleware () must be called after Routing Middleware () when rate limiting endpoint-specific APIs are used. For example, if the [`[EnableRateLimiting]` attribute](xref:Microsoft.AspNetCore.RateLimiting.EnableRateLimitingAttribute) is used, Rate Limiting Middleware must be called after Routing Middleware. When calling only global limiters, Rate Limiting Middleware can be called before Routing Middleware. +* CORS middleware (), authentication middleware (), and authorization middleware () must appear in the order shown. +* CORS middleware () must appear before response caching middleware () to add CORS headers on every request, including cached responses. For more information, see [It is not clear that UseCORS must come before UseResponseCaching (`dotnet/aspnetcore` #23218](https://github.com/dotnet/aspnetcore/issues/23218). +* Request localization middleware () must appear before any middleware that might check the request culture, for example, static file middleware (). +* Rate-limiting middleware () must be called after routing middleware () when rate limiting endpoint-specific APIs are used. For example, if the [`[EnableRateLimiting]` attribute](xref:Microsoft.AspNetCore.RateLimiting.EnableRateLimitingAttribute) is used, rate-limiting middleware must be called after routing middleware. When calling only global limiters, rate-limiting middleware can be called before routing middleware. In some scenarios, middleware has different ordering. For example, caching and compression ordering depends on the app's specification. In the following order, CPU usage might be reduced by caching the compressed response, but the app might end up caching multiple representations of a resource using different compression algorithms, such as Gzip or Brotli: @@ -641,7 +641,7 @@ app.UseResponseCompression(); Static assets are typically served early in the pipeline so that the app can short-circuit request processing to improve performance. -Authentication doesn't short-circuit unauthenticated requests. Although Authentication Middleware authenticates requests, authorization occurs after the framework selects a Razor component in a Blazor Web App, a page in a Razor Pages app, or a controller and action in an MVC app. +Authentication doesn't short-circuit unauthenticated requests. Although authentication middleware authenticates requests, authorization occurs after the framework selects a Razor component in a Blazor Web App, a page in a Razor Pages app, or a controller and action in an MVC app. :::moniker-end @@ -740,19 +740,19 @@ The following `Program.cs` code adds middleware components for common app scenar 1. Exception/error handling * When the app runs in the `Development` environment: - * Developer Exception Page Middleware () reports app runtime errors. - * Database Error Page Middleware () reports database runtime errors. + * Developer exception page middleware () reports app runtime errors. + * Database error page middleware () reports database runtime errors. * When the app runs in the `Production` environment: - * Exception Handler Middleware () catches exceptions thrown in the following middlewares. - * HTTP Strict Transport Security Protocol (HSTS) Middleware () adds the `Strict-Transport-Security` header. -1. HTTPS Redirection Middleware () redirects HTTP requests to HTTPS. -1. Static File Middleware () returns static files and short-circuits further request processing. -1. Cookie Policy Middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. -1. Routing Middleware () to route requests. -1. Authentication Middleware () attempts to authenticate the user before they're allowed access to secure resources. -1. Authorization Middleware () authorizes a user to access secure resources. -1. Session Middleware () establishes and maintains session state. If the app uses session state, call Session Middleware after Cookie Policy Middleware and before MVC Middleware. -1. Endpoint Routing Middleware ( with ) to add Razor Pages endpoints to the request pipeline. + * Exception handler middleware () catches exceptions thrown in the following middlewares. + * HTTP Strict Transport Security (HSTS) protocol middleware () adds the `Strict-Transport-Security` header. +1. HTTPS redirection middleware () redirects HTTP requests to HTTPS. +1. Static file middleware () returns static files and short-circuits further request processing. +1. Cookie policy middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. +1. Routing middleware () to route requests. +1. Authentication middleware () attempts to authenticate the user before they're allowed access to secure resources. +1. Authorization middleware () authorizes a user to access secure resources. +1. Session middleware () establishes and maintains session state. If the app uses session state, call session middleware after cookie policy middleware and before MVC middleware. +1. Endpoint routing middleware ( with ) to add Razor Pages endpoints to the request pipeline. ```csharp if (env.IsDevelopment()) @@ -777,16 +777,16 @@ app.MapRazorPages(); In the preceding example code, each middleware extension method is exposed on through the namespace. - is the first middleware component added to the pipeline. Therefore, the Exception Handler Middleware catches any exceptions that occur in later calls. + is the first middleware component added to the pipeline. Therefore, the exception handler middleware catches any exceptions that occur in later calls. -Static File Middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The Static File Middleware provides **no** authorization checks. Any files served by Static File Middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . +Static file middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The static file middleware provides **no** authorization checks. Any files served by static file middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . -If the request isn't handled by the Static File Middleware, it's passed on to the Authentication Middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although Authentication Middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. +If the request isn't handled by the static file middleware, it's passed on to the authentication middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although authentication middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. -The following example demonstrates a middleware order where requests for static files are handled by Static File Middleware before Response Compression Middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. +The following example demonstrates a middleware order where requests for static files are handled by static file middleware before response compression middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. ```csharp -// Static files aren't compressed by Static File Middleware. +// Static files aren't compressed by static file middleware. app.UseStaticFiles(); app.UseRouting(); @@ -894,19 +894,19 @@ The following `Program.cs` code adds middleware components for common app scenar 1. Exception/error handling * When the app runs in the `Development` environment: - * Developer Exception Page Middleware () reports app runtime errors. - * Database Error Page Middleware () reports database runtime errors. + * Developer exception page middleware () reports app runtime errors. + * Database error page middleware () reports database runtime errors. * When the app runs in the `Production` environment: - * Exception Handler Middleware () catches exceptions thrown in the following middlewares. - * HTTP Strict Transport Security Protocol (HSTS) Middleware () adds the `Strict-Transport-Security` header. -1. HTTPS Redirection Middleware () redirects HTTP requests to HTTPS. -1. Static File Middleware () returns static files and short-circuits further request processing. -1. Cookie Policy Middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. -1. Routing Middleware () to route requests. -1. Authentication Middleware () attempts to authenticate the user before they're allowed access to secure resources. -1. Authorization Middleware () authorizes a user to access secure resources. -1. Session Middleware () establishes and maintains session state. If the app uses session state, call Session Middleware after Cookie Policy Middleware and before MVC Middleware. -1. Endpoint Routing Middleware ( with ) to add Razor Pages endpoints to the request pipeline. + * Exception handler middleware () catches exceptions thrown in the following middlewares. + * HTTP Strict Transport Security (HSTS) protocol middleware () adds the `Strict-Transport-Security` header. +1. HTTPS redirection middleware () redirects HTTP requests to HTTPS. +1. Static file middleware () returns static files and short-circuits further request processing. +1. Cookie policy middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. +1. Routing middleware () to route requests. +1. Authentication middleware () attempts to authenticate the user before they're allowed access to secure resources. +1. Authorization middleware () authorizes a user to access secure resources. +1. Session middleware () establishes and maintains session state. If the app uses session state, call session middleware after cookie policy middleware and before MVC middleware. +1. Endpoint routing middleware ( with ) to add Razor Pages endpoints to the request pipeline. ```csharp if (env.IsDevelopment()) @@ -931,16 +931,16 @@ app.MapRazorPages(); In the preceding example code, each middleware extension method is exposed on through the namespace. - is the first middleware component added to the pipeline. Therefore, the Exception Handler Middleware catches any exceptions that occur in later calls. + is the first middleware component added to the pipeline. Therefore, the exception handler middleware catches any exceptions that occur in later calls. -Static File Middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The Static File Middleware provides **no** authorization checks. Any files served by Static File Middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . +Static file middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The static file middleware provides **no** authorization checks. Any files served by static file middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . -If the request isn't handled by the Static File Middleware, it's passed on to the Authentication Middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although Authentication Middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. +If the request isn't handled by the static file middleware, it's passed on to the authentication middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although authentication middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. -The following example demonstrates a middleware order where requests for static files are handled by Static File Middleware before Response Compression Middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. +The following example demonstrates a middleware order where requests for static files are handled by static file middleware before response compression middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. ```csharp -// Static files aren't compressed by Static File Middleware. +// Static files aren't compressed by static file middleware. app.UseStaticFiles(); app.UseRouting(); @@ -1031,19 +1031,19 @@ The following `Startup.Configure` method adds middleware components for common a 1. Exception/error handling * When the app runs in the `Development` environment: - * Developer Exception Page Middleware () reports app runtime errors. - * Database Error Page Middleware reports database runtime errors. + * Developer exception page middleware () reports app runtime errors. + * Database error page middleware reports database runtime errors. * When the app runs in the `Production` environment: - * Exception Handler Middleware () catches exceptions thrown in the following middlewares. - * HTTP Strict Transport Security Protocol (HSTS) Middleware () adds the `Strict-Transport-Security` header. -1. HTTPS Redirection Middleware () redirects HTTP requests to HTTPS. -1. Static File Middleware () returns static files and short-circuits further request processing. -1. Cookie Policy Middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. -1. Routing Middleware () to route requests. -1. Authentication Middleware () attempts to authenticate the user before they're allowed access to secure resources. -1. Authorization Middleware () authorizes a user to access secure resources. -1. Session Middleware () establishes and maintains session state. If the app uses session state, call Session Middleware after Cookie Policy Middleware and before MVC Middleware. -1. Endpoint Routing Middleware ( with ) to add Razor Pages endpoints to the request pipeline. + * Exception handler middleware () catches exceptions thrown in the following middlewares. + * HTTP Strict Transport Security (HSTS) protocol middleware () adds the `Strict-Transport-Security` header. +1. HTTPS redirection middleware () redirects HTTP requests to HTTPS. +1. Static file middleware () returns static files and short-circuits further request processing. +1. Cookie policy middleware () conforms the app to the EU General Data Protection Regulation (GDPR) regulations. +1. Routing middleware () to route requests. +1. Authentication middleware () attempts to authenticate the user before they're allowed access to secure resources. +1. Authorization middleware () authorizes a user to access secure resources. +1. Session middleware () establishes and maintains session state. If the app uses session state, call session middleware after cookie policy middleware and before MVC middleware. +1. Endpoint routing middleware ( with ) to add Razor Pages endpoints to the request pipeline. ```csharp public void Configure(IApplicationBuilder app, IWebHostEnvironment env) @@ -1076,18 +1076,18 @@ public void Configure(IApplicationBuilder app, IWebHostEnvironment env) In the preceding example code, each middleware extension method is exposed on through the namespace. - is the first middleware component added to the pipeline. Therefore, the Exception Handler Middleware catches any exceptions that occur in later calls. + is the first middleware component added to the pipeline. Therefore, the exception handler middleware catches any exceptions that occur in later calls. -Static File Middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The Static File Middleware provides **no** authorization checks. Any files served by Static File Middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . +Static file middleware is called early in the pipeline so that it can handle requests and short-circuit without going through the remaining components. The static file middleware provides **no** authorization checks. Any files served by static file middleware, including those under *wwwroot*, are publicly available. For an approach to secure static files, see . -If the request isn't handled by the Static File Middleware, it's passed on to the Authentication Middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although Authentication Middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. +If the request isn't handled by the static file middleware, it's passed on to the authentication middleware (), which performs authentication. Authentication doesn't short-circuit unauthenticated requests. Although authentication middleware authenticates requests, authorization (and rejection) occurs only after MVC selects a specific Razor Page or MVC controller and action. -The following example demonstrates a middleware order where requests for static files are handled by Static File Middleware before Response Compression Middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. +The following example demonstrates a middleware order where requests for static files are handled by static file middleware before response compression middleware. Static files aren't compressed with this middleware order. The Razor Pages responses can be compressed. ```csharp public void Configure(IApplicationBuilder app) { - // Static files aren't compressed by Static File Middleware. + // Static files aren't compressed by static file middleware. app.UseStaticFiles(); app.UseRouting(); @@ -1116,9 +1116,9 @@ For information about Single Page Applications, see the guides for the [React](x For more information on ordering and , see . -## Forwarded Headers Middleware order +## Forwarded headers middleware order -Run Forwarded Headers Middleware before other middleware to ensure that the middleware relying on forwarded headers information can consume the header values for processing. To run Forwarded Headers Middleware after Diagnostics and Error Handling Middleware, see [Forwarded Headers Middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). +Run forwarded headers middleware before other middleware to ensure that the middleware relying on forwarded headers information can consume the header values for processing. To run forwarded headers middleware after diagnostics and error handling middleware, see [forwarded headers middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). ## Built-in middleware @@ -1138,7 +1138,7 @@ Middleware | Description | UI stack | Order --- | --- | --- | --- [Antiforgery](xref:security/anti-request-forgery) | Provides anti-request-forgery support. | All | After authentication and authorization, before endpoints. [Authentication](xref:security/authentication/identity) | Provides authentication support. | All | Before `HttpContext.User` is required. Terminal for OAuth callbacks. -[Authorization](xref:Microsoft.AspNetCore.Builder.AuthorizationAppBuilderExtensions.UseAuthorization%2A) | Provides authorization support. | All | Immediately after the Authentication Middleware. +[Authorization](xref:Microsoft.AspNetCore.Builder.AuthorizationAppBuilderExtensions.UseAuthorization%2A) | Provides authorization support. | All | Immediately after the authentication middleware. [Cookie Policy](xref:security/gdpr) | Tracks consent from users for storing personal information and enforces minimum standards for cookie fields, such as `secure` and `SameSite`. | All | Before middleware that issues cookies. Examples: Authentication, Session, MVC (TempData). [CORS](xref:security/cors) | Configures Cross-Origin Resource Sharing. | All | Before middleware that use CORS. must go before . For more information, see [It is not clear that UseCORS must come before UseResponseCaching (`dotnet/aspnetcore` #23218](https://github.com/dotnet/aspnetcore/issues/23218). [Developer Exception Page](xref:Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware) | Generates a page with error information that is intended for use only in the `Development` environment. | All | Before middleware that generate errors. The project templates automatically register this middleware as the first middleware in the pipeline when the environment is `Development`. @@ -1150,14 +1150,14 @@ All | [HTTP Logging](xref:fundamentals/http-logging/index) | Logs HTTP Requests and Responses. | All | At the beginning of the middleware pipeline. [HTTP Method Override](xref:Microsoft.AspNetCore.Builder.HttpMethodOverrideExtensions) | Allows an incoming POST request to override the method. | All | Before middleware that consume the updated method. [HTTPS Redirection](xref:security/enforcing-ssl#require-https) | Redirect all HTTP requests to HTTPS. | All | Before middleware that consume the URL. -[HTTP Strict Transport Security (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) | Security enhancement middleware that adds a special response header. | All | Before responses are sent and after middleware that modify requests. Examples: Forwarded Headers, URL Rewriting. +[HTTP Strict Transport Security (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) | Security enhancement middleware that adds a special response header. | All | Before responses are sent and after middleware that modify requests. Examples: Forwarded Headers, URL Rewriting. [MVC](xref:mvc/overview) | Processes requests with MVC/Razor Pages. | RP/MVC | Terminal if a request matches a route. -[OWIN](xref:fundamentals/owin) | Interop with OWIN-based apps, servers, and middleware. | RP/MVC | Terminal if the OWIN Middleware fully processes the request. +[OWIN](xref:fundamentals/owin) | Interop with OWIN-based apps, servers, and middleware. | RP/MVC | Terminal if the OWIN middleware fully processes the request. [Output Caching](xref:performance/caching/output) | Provides support for caching responses based on configuration. | RP/MVC | Before middleware that require caching. , , , and must come before . [Response Caching](xref:performance/caching/middleware) | Provides support for caching responses. This requires client participation to work. Use output caching for complete server control. | RP/MVC | Before middleware that require caching. must come before . Response caching isn't typically beneficial for UI apps, such as Razor Pages, because browsers generally set request headers that prevent caching. [Output caching](xref:performance/caching/output) benefits UI apps. [Request Decompression](xref:fundamentals/middleware/request-decompression) | Provides support for decompressing requests. | All | Before middleware that read the request body. [Response Compression](xref:performance/response-compression) | Provides support for compressing responses. | All | Before middleware that require compression. -[Request Localization](xref:fundamentals/localization) | Provides localization support. | All | Before localization sensitive middleware. Must appear after Routing Middleware when using . +[Request Localization](xref:fundamentals/localization) | Provides localization support. | All | Before localization sensitive middleware. Must appear after routing middleware when using . [Request Timeouts](xref:performance/timeouts) | Provides support for configuring request timeouts, global and per endpoint. | All | must come after , , and . [Endpoint Routing](xref:fundamentals/routing). | Defines and constrains request routes. | All | Terminal for matching routes. [SPA](xref:Microsoft.AspNetCore.Builder.SpaApplicationBuilderExtensions.UseSpa%2A) | Handles all requests from this point in the middleware chain by returning the default page for the Single Page Application (SPA). | All | Appears late in the pipeline, so other middleware for serving static files, such as MVC actions, take precedence. diff --git a/aspnetcore/fundamentals/minimal-apis.md b/aspnetcore/fundamentals/minimal-apis.md index 2562a77b574b..b7c9eb7e0e31 100644 --- a/aspnetcore/fundamentals/minimal-apis.md +++ b/aspnetcore/fundamentals/minimal-apis.md @@ -34,7 +34,7 @@ The Minimal APIs consist of: [!INCLUDE[](~/fundamentals/minimal-apis/includes/webapplication10.md)] -## ASP.NET Core Middleware +## ASP.NET Core middleware The following table lists some of the middleware frequently used with Minimal APIs. diff --git a/aspnetcore/fundamentals/minimal-apis/handle-errors/includes/handle-errors7.md b/aspnetcore/fundamentals/minimal-apis/handle-errors/includes/handle-errors7.md index 68dde5754247..21a6197c6182 100644 --- a/aspnetcore/fundamentals/minimal-apis/handle-errors/includes/handle-errors7.md +++ b/aspnetcore/fundamentals/minimal-apis/handle-errors/includes/handle-errors7.md @@ -60,7 +60,7 @@ Accept-Encoding: gzip, deflate, br ### Exception handler -In non-development environments, use the [Exception Handler Middleware](xref:fundamentals/error-handling#exception-handler-page) to produce an error payload. To configure the `Exception Handler Middleware`, call . +In non-development environments, use the [exception handler middleware](xref:fundamentals/error-handling#exception-handler-page) to produce an error payload. To configure the `exception handler middleware`, call . For example, the following code changes the app to respond with an [RFC 7807](https://tools.ietf.org/html/rfc7807)-compliant payload to the client. For more information, see [Problem Details](#problem-details) section. diff --git a/aspnetcore/fundamentals/minimal-apis/includes/minimal-apis6.md b/aspnetcore/fundamentals/minimal-apis/includes/minimal-apis6.md index 059731711457..a7608c9d1165 100644 --- a/aspnetcore/fundamentals/minimal-apis/includes/minimal-apis6.md +++ b/aspnetcore/fundamentals/minimal-apis/includes/minimal-apis6.md @@ -228,7 +228,7 @@ Extension methods on can be ### Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: [!code-csharp[](~/fundamentals/minimal-apis/samples/WebMinAPIs/Program.cs?name=snippet_chngr)] @@ -248,7 +248,7 @@ builder.Host.ConfigureContainer(builder => builder.RegisterMod var app = builder.Build(); ``` -### Add Middleware +### Add middleware Any existing ASP.NET Core middleware can be configured on the `WebApplication`: @@ -262,7 +262,7 @@ For more information, see can be ### Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: [!code-csharp[](~/fundamentals/minimal-apis/7.0-samples/WebMinAPIs/Program.cs?name=snippet_chngr)] @@ -257,7 +257,7 @@ builder.Host.ConfigureContainer(builder => builder.RegisterMod var app = builder.Build(); ``` -### Add Middleware +### Add middleware Any existing ASP.NET Core middleware can be configured on the `WebApplication`: diff --git a/aspnetcore/fundamentals/minimal-apis/includes/webapplication7.md b/aspnetcore/fundamentals/minimal-apis/includes/webapplication7.md index 88b2993bff4a..7935199711f7 100644 --- a/aspnetcore/fundamentals/minimal-apis/includes/webapplication7.md +++ b/aspnetcore/fundamentals/minimal-apis/includes/webapplication7.md @@ -213,7 +213,7 @@ Extension methods on can be ### Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: [!code-csharp[](~/fundamentals/minimal-apis/7.0-samples/WebMinAPIs/Program.cs?name=snippet_chngr)] @@ -233,7 +233,7 @@ builder.Host.ConfigureContainer(builder => builder.RegisterMod var app = builder.Build(); ``` -### Add Middleware +### Add middleware Any existing ASP.NET Core middleware can be configured on the `WebApplication`: diff --git a/aspnetcore/fundamentals/minimal-apis/includes/webapplication8.md b/aspnetcore/fundamentals/minimal-apis/includes/webapplication8.md index cb1dd1c90de1..5a46f19ee1c2 100644 --- a/aspnetcore/fundamentals/minimal-apis/includes/webapplication8.md +++ b/aspnetcore/fundamentals/minimal-apis/includes/webapplication8.md @@ -237,7 +237,7 @@ Extension methods on can be ### Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: [!code-csharp[](~/fundamentals/minimal-apis/7.0-samples/WebMinAPIs/Program.cs?name=snippet_chngr)] @@ -257,7 +257,7 @@ builder.Host.ConfigureContainer(builder => builder.RegisterMod var app = builder.Build(); ``` -### Add Middleware +### Add middleware Any existing ASP.NET Core middleware can be configured on the `WebApplication`: diff --git a/aspnetcore/fundamentals/minimal-apis/includes/webapplication9.md b/aspnetcore/fundamentals/minimal-apis/includes/webapplication9.md index 741744df6adb..8c55be330c95 100644 --- a/aspnetcore/fundamentals/minimal-apis/includes/webapplication9.md +++ b/aspnetcore/fundamentals/minimal-apis/includes/webapplication9.md @@ -237,7 +237,7 @@ Extension methods on can be ### Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed with `WebHostOptions`, the command line, or with the method: [!code-csharp[](~/fundamentals/minimal-apis/7.0-samples/WebMinAPIs/Program.cs?name=snippet_chngr)] @@ -257,7 +257,7 @@ builder.Host.ConfigureContainer(builder => builder.RegisterMod var app = builder.Build(); ``` -### Add Middleware +### Add middleware Any existing ASP.NET Core middleware can be configured on the `WebApplication`: diff --git a/aspnetcore/fundamentals/minimal-apis/middleware.md b/aspnetcore/fundamentals/minimal-apis/middleware.md index 54f0e138b9a2..3cfe7becd350 100644 --- a/aspnetcore/fundamentals/minimal-apis/middleware.md +++ b/aspnetcore/fundamentals/minimal-apis/middleware.md @@ -23,6 +23,6 @@ This article describes how to use middleware in Minimal API applications. Take a ## Related content -- [ASP.NET Core Middleware](xref:fundamentals/middleware/index) +- [ASP.NET Core middleware](xref:fundamentals/middleware/index) - [Built-in middleware (list)](xref:fundamentals/middleware/index#built-in-middleware) - [Minimal APIs overview](xref:fundamentals/apis) \ No newline at end of file diff --git a/aspnetcore/fundamentals/minimal-apis/security.md b/aspnetcore/fundamentals/minimal-apis/security.md index 0da1322f2a64..31acbd76ccfd 100644 --- a/aspnetcore/fundamentals/minimal-apis/security.md +++ b/aspnetcore/fundamentals/minimal-apis/security.md @@ -155,5 +155,5 @@ curl -i -H "Authorization: Bearer {token}" https://localhost:{port}/hello - [The authentication service (IAuthenticationService)](/dotnet/api/microsoft.aspnetcore.authentication.iauthenticationservice) - [The authorization service (IAuthorizationService)](/dotnet/api/microsoft.aspnetcore.authorization.iauthorizationservice) -- [ASP.NET Core Middleware](./middleware.md) +- [ASP.NET Core middleware](xref:fundamentals/middleware/index) - [Manage JSON Web Tokens with the dotnet user-jwts tool](../../security/authentication/jwt-authn.md) diff --git a/aspnetcore/fundamentals/portable-object-localization.md b/aspnetcore/fundamentals/portable-object-localization.md index 78bb087277ec..491b6ff17665 100644 --- a/aspnetcore/fundamentals/portable-object-localization.md +++ b/aspnetcore/fundamentals/portable-object-localization.md @@ -114,7 +114,7 @@ msgstr[1] "Il y a {0} éléments." See [What is a PO file?](#what-is-a-po-file) for an explanation of what each entry in this example represents. -### Adding a language using different pluralization forms +### Add a language using different pluralization forms English and French strings were used in the previous example. English and French have only two pluralization forms and share the same form rules, which is that a cardinality of one is mapped to the first plural form. Any other cardinality is mapped to the second plural form. @@ -334,7 +334,7 @@ msgstr[1] "Il y a {0} éléments." See [What is a PO file?](#what-is-a-po-file) for an explanation of what each entry in this example represents. -### Adding a language using different pluralization forms +### Add a language using different pluralization forms English and French strings were used in the previous example. English and French have only two pluralization forms and share the same form rules, which is that a cardinality of one is mapped to the first plural form. Any other cardinality is mapped to the second plural form. @@ -547,7 +547,7 @@ msgstr[1] "Il y a {0} éléments." See [What is a PO file?](#what-is-a-po-file) for an explanation of what each entry in this example represents. -### Adding a language using different pluralization forms +### Add a language using different pluralization forms English and French strings were used in the previous example. English and French have only two pluralization forms and share the same form rules, which is that a cardinality of one is mapped to the first plural form. Any other cardinality is mapped to the second plural form. diff --git a/aspnetcore/fundamentals/servers/index.md b/aspnetcore/fundamentals/servers/index.md index 1ca25e9aa631..5230907fb13f 100644 --- a/aspnetcore/fundamentals/servers/index.md +++ b/aspnetcore/fundamentals/servers/index.md @@ -118,7 +118,7 @@ The following diagram illustrates the relationship between IIS, the ASP.NET Core Requests arrive from the web to the kernel-mode HTTP.sys driver. The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443. -The module specifies the port via an environment variable at startup, and the [IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. +The module specifies the port via an environment variable at startup, and the [IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. The middleware pipeline handles the request and passes it on as an `HttpContext` instance to the app's logic. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request. diff --git a/aspnetcore/fundamentals/servers/kestrel/endpoints/includes/endpoints5-7.md b/aspnetcore/fundamentals/servers/kestrel/endpoints/includes/endpoints5-7.md index 6841b2a2a195..479cc82d662d 100644 --- a/aspnetcore/fundamentals/servers/kestrel/endpoints/includes/endpoints5-7.md +++ b/aspnetcore/fundamentals/servers/kestrel/endpoints/includes/endpoints5-7.md @@ -381,7 +381,7 @@ For more information, see . ## Connection logging -Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [Connection Middleware](#connection-middleware). +Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [connection middleware](#connection-middleware). :::code language="csharp" source="~/fundamentals/servers/kestrel/samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureKestrelUseConnectionLogging"::: @@ -467,7 +467,7 @@ On Linux, can be used to filter TL :::code language="csharp" source="~/fundamentals/servers/kestrel/samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureHttpsDefaultsCipherSuitesPolicy"::: -## Connection Middleware +## Connection middleware Custom connection middleware can filter TLS handshakes on a per-connection basis for specific ciphers if necessary. @@ -936,7 +936,7 @@ For more information, see . ## Connection logging -Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [Connection Middleware](#connection-middleware). +Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [connection middleware](#connection-middleware). :::code language="csharp" source="~/fundamentals/servers/kestrel/samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureKestrelUseConnectionLogging"::: @@ -1015,7 +1015,7 @@ On Linux, can be used to filter TL :::code language="csharp" source="~/fundamentals/servers/kestrel/samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureHttpsDefaultsCipherSuitesPolicy"::: -## Connection Middleware +## Connection middleware Custom connection middleware can filter TLS handshakes on a per-connection basis for specific ciphers if necessary. @@ -1611,7 +1611,7 @@ For more information, see . ## Connection logging -Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [Connection Middleware](#connection-middleware). +Call to emit Debug level logs for byte-level communication on a connection. Connection logging is helpful for troubleshooting problems in low-level communication, such as during TLS encryption and behind proxies. If `UseConnectionLogging` is placed before `UseHttps`, encrypted traffic is logged. If `UseConnectionLogging` is placed after `UseHttps`, decrypted traffic is logged. This is built-in [connection middleware](#connection-middleware). ```csharp webBuilder.ConfigureKestrel(serverOptions => @@ -1735,7 +1735,7 @@ webBuilder.ConfigureKestrel(serverOptions => }); ``` -## Connection Middleware +## Connection middleware Custom connection middleware can filter TLS handshakes on a per-connection basis for specific ciphers if necessary. diff --git a/aspnetcore/fundamentals/servers/kestrel/host-filtering.md b/aspnetcore/fundamentals/servers/kestrel/host-filtering.md index d05ef43c3a24..42799ac2ba6b 100644 --- a/aspnetcore/fundamentals/servers/kestrel/host-filtering.md +++ b/aspnetcore/fundamentals/servers/kestrel/host-filtering.md @@ -15,11 +15,11 @@ uid: fundamentals/servers/kestrel/host-filtering While Kestrel supports configuration based on prefixes such as `http://example.com:5000`, Kestrel largely ignores the host name. Host `localhost` is a special case used for binding to loopback addresses. Any host other than an explicit IP address binds to all public IP addresses. `Host` headers aren't validated. -As a workaround, use Host Filtering Middleware. The middleware is added by , which calls : +As a workaround, use host-filtering middleware. The middleware is added by , which calls : [!code-csharp[](samples-snapshot/2.x/KestrelSample/Program.cs?name=snippet_Program&highlight=9)] -Host Filtering Middleware is disabled by default. To enable the middleware, define an `AllowedHosts` key in `appsettings.json`/`appsettings.{Environment}.json`. The value is a semicolon-delimited list of host names without port numbers: +Host-filtering middleware is disabled by default. To enable the middleware, define an `AllowedHosts` key in `appsettings.json`/`appsettings.{Environment}.json`. The value is a semicolon-delimited list of host names without port numbers: `appsettings.json`: @@ -30,6 +30,6 @@ Host Filtering Middleware is disabled by default. To enable the middleware, defi ``` > [!NOTE] -> [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) also has an option. Forwarded Headers Middleware and Host Filtering Middleware have similar functionality for different scenarios. Setting `AllowedHosts` with Forwarded Headers Middleware is appropriate when the `Host` header isn't preserved while forwarding requests with a reverse proxy server or load balancer. Setting `AllowedHosts` with Host Filtering Middleware is appropriate when Kestrel is used as a public-facing edge server or when the `Host` header is directly forwarded. +> [Forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) also has an option. Forwarded headers middleware and host-filtering middleware have similar functionality for different scenarios. Setting `AllowedHosts` with forwarded headers middleware is appropriate when the `Host` header isn't preserved while forwarding requests with a reverse proxy server or load balancer. Setting `AllowedHosts` with host-filtering middleware is appropriate when Kestrel is used as a public-facing edge server or when the `Host` header is directly forwarded. > -> For more information on Forwarded Headers Middleware, see . +> For more information on forwarded headers middleware, see . diff --git a/aspnetcore/fundamentals/servers/kestrel/includes/kestrel6.md b/aspnetcore/fundamentals/servers/kestrel/includes/kestrel6.md index 733f32e39b29..dcfe89a016ea 100644 --- a/aspnetcore/fundamentals/servers/kestrel/includes/kestrel6.md +++ b/aspnetcore/fundamentals/servers/kestrel/includes/kestrel6.md @@ -224,7 +224,7 @@ A reverse proxy: * Simplify load balancing and secure communication (HTTPS) configuration. Only the reverse proxy server requires an X.509 certificate, and that server can communicate with the app's servers on the internal network using plain HTTP. > [!WARNING] -> Hosting in a reverse proxy configuration requires [Forwarded Headers Middleware configuration](xref:host-and-deploy/proxy-load-balancer). +> Hosting in a reverse proxy configuration requires [forwarded headers middleware configuration](xref:host-and-deploy/proxy-load-balancer). ## Kestrel in ASP.NET Core apps @@ -885,7 +885,7 @@ webBuilder.ConfigureKestrel(serverOptions => }); ``` -Use Connection Middleware to filter TLS handshakes on a per-connection basis for specific ciphers if required. +Use connection middleware to filter TLS handshakes on a per-connection basis for specific ciphers if required. The following example throws for any cipher algorithm that the app doesn't support. Alternatively, define and compare [ITlsHandshakeFeature.CipherAlgorithm](xref:Microsoft.AspNetCore.Connections.Features.ITlsHandshakeFeature.CipherAlgorithm) to a list of acceptable cipher suites. @@ -1056,7 +1056,7 @@ Only HTTP URL prefixes are valid. Kestrel doesn't support HTTPS when configuring Host names, `*`, and `+`, aren't special. Anything not recognized as a valid IP address or `localhost` binds to all IPv4 and IPv6 IPs. To bind different host names to different ASP.NET Core apps on the same port, use [HTTP.sys](xref:fundamentals/servers/httpsys) or a reverse proxy server, such as IIS, Nginx, or Apache. > [!WARNING] - > Hosting in a reverse proxy configuration requires [Forwarded Headers Middleware configuration](xref:host-and-deploy/proxy-load-balancer). + > Hosting in a reverse proxy configuration requires [forwarded headers middleware configuration](xref:host-and-deploy/proxy-load-balancer). * Host `localhost` name with port number or loopback IP with port number @@ -1072,11 +1072,11 @@ Only HTTP URL prefixes are valid. Kestrel doesn't support HTTPS when configuring While Kestrel supports configuration based on prefixes such as `http://example.com:5000`, Kestrel largely ignores the host name. Host `localhost` is a special case used for binding to loopback addresses. Any host other than an explicit IP address binds to all public IP addresses. `Host` headers aren't validated. -As a workaround, use Host Filtering Middleware. Host Filtering Middleware is provided by the [Microsoft.AspNetCore.HostFiltering](https://www.nuget.org/packages/Microsoft.AspNetCore.HostFiltering) package, which is implicitly provided for ASP.NET Core apps. The middleware is added by , which calls : +As a workaround, use host-filtering middleware. Host-filtering middleware is provided by the [Microsoft.AspNetCore.HostFiltering](https://www.nuget.org/packages/Microsoft.AspNetCore.HostFiltering) package, which is implicitly provided for ASP.NET Core apps. The middleware is added by , which calls : :::code language="csharp" source="~/fundamentals/servers/kestrel/samples-snapshot/2.x/KestrelSample/Program.cs" id="snippet_Program" highlight="9"::: -Host Filtering Middleware is disabled by default. To enable the middleware, define an `AllowedHosts` key in `appsettings.json`/`appsettings.{Environment}.json`. The value is a semicolon-delimited list of host names without port numbers: +Host-filtering middleware is disabled by default. To enable the middleware, define an `AllowedHosts` key in `appsettings.json`/`appsettings.{Environment}.json`. The value is a semicolon-delimited list of host names without port numbers: `appsettings.json`: @@ -1087,9 +1087,9 @@ Host Filtering Middleware is disabled by default. To enable the middleware, defi ``` > [!NOTE] -> [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) also has an option. Forwarded Headers Middleware and Host Filtering Middleware have similar functionality for different scenarios. Setting `AllowedHosts` with Forwarded Headers Middleware is appropriate when the `Host` header isn't preserved while forwarding requests with a reverse proxy server or load balancer. Setting `AllowedHosts` with Host Filtering Middleware is appropriate when Kestrel is used as a public-facing edge server or when the `Host` header is directly forwarded. +> [Forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) also has an option. Forwarded headers middleware and host-filtering middleware have similar functionality for different scenarios. Setting `AllowedHosts` with forwarded headers middleware is appropriate when the `Host` header isn't preserved while forwarding requests with a reverse proxy server or load balancer. Setting `AllowedHosts` with host-filtering middleware is appropriate when Kestrel is used as a public-facing edge server or when the `Host` header is directly forwarded. > -> For more information on Forwarded Headers Middleware, see . +> For more information on forwarded headers middleware, see . ## Libuv transport configuration diff --git a/aspnetcore/fundamentals/servers/kestrel/security-considerations.md b/aspnetcore/fundamentals/servers/kestrel/security-considerations.md index 1c9df369213d..8ce8e39e842e 100644 --- a/aspnetcore/fundamentals/servers/kestrel/security-considerations.md +++ b/aspnetcore/fundamentals/servers/kestrel/security-considerations.md @@ -49,7 +49,7 @@ Kestrel's security posture depends on where it sits in the network architecture. When Kestrel is directly accessible from the internet, it is the first line of defense: - **Kestrel handles all TLS termination.** Configure [certificates, TLS protocol versions, and client certificate requirements](#transport-security-tlshttps) directly in Kestrel. -- **[Host header filtering](#host-filtering) is critical.** Without a reverse proxy to validate the Host header, Kestrel must do it. Use Host Filtering middleware to prevent DNS rebinding and host header attacks. +- **[Host header filtering](#host-filtering) is critical.** Without a reverse proxy to validate the Host header, Kestrel must do it. Use host-filtering middleware to prevent DNS rebinding and host header attacks. - **Don't enable [Forwarded Headers](#forwarded-headers) middleware.** When there is no trusted proxy, processing `X-Forwarded-*` headers allows any client to spoof their IP address, scheme, and host. Also verify the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` environment variable isn't set—see the [environment variable warning](#behind-a-reverse-proxy) in the reverse proxy section. - **[Rate limiting](#rate-limiting) must be handled by the application.** There is no upstream proxy to absorb floods. - **[Connection limits](#connection-limits) should be monitored.** The defaults for `MaxConcurrentConnections` and `MaxConcurrentUpgradedConnections` are unlimited. Setting a limit can DoS legitimate requests if the limits are too low, or there is an unexpected surge in traffic. [Metrics](#monitoring-with-metrics) can be used to observe traffic patterns. @@ -139,12 +139,12 @@ Quick reference for production deployments. Each row links to the detailed secti | Feature | Default | [Edge Server](#edge-server-direct-internet-exposure) | [Behind Proxy](#behind-a-reverse-proxy) | Details | |---|---|---|---|---| -| [**Host Filtering**](#host-filtering) | All hosts allowed | Configure `AllowedHosts` | Optional (defense-in-depth) | [Security Middleware](#security-middleware) | -| [**HTTPS Redirection**](#https-redirection) | Not enabled | Enable | Depends on proxy config | [Security Middleware](#security-middleware) | -| [**HSTS**](#http-strict-transport-security-hsts) | Not enabled | Enable | Enable | [Security Middleware](#security-middleware) | -| [**Forwarded Headers**](#forwarded-headers) | Not enabled | **Don't enable** | Enable with `KnownProxies` | [Security Middleware](#security-middleware) | -| [**Rate Limiting**](#rate-limiting) | Disabled | Enable | Enable (app-level) | [Security Middleware](#security-middleware) | -| [**CORS**](#cors) | Disabled | Configure per API (if needed) | Configure per API (if needed) | [Security Middleware](#security-middleware) | +| [**Host Filtering**](#host-filtering) | All hosts allowed | Configure `AllowedHosts` | Optional (defense-in-depth) | [Security middleware](#security-middleware) | +| [**HTTPS Redirection**](#https-redirection) | Not enabled | Enable | Depends on proxy config | [Security middleware](#security-middleware) | +| [**HSTS**](#http-strict-transport-security-hsts) | Not enabled | Enable | Enable | [Security middleware](#security-middleware) | +| [**Forwarded Headers**](#forwarded-headers) | Not enabled | **Don't enable** | Enable with `KnownProxies` | [Security middleware](#security-middleware) | +| [**Rate Limiting**](#rate-limiting) | Disabled | Enable | Enable (app-level) | [Security middleware](#security-middleware) | +| [**CORS**](#cors) | Disabled | Configure per API (if needed) | Configure per API (if needed) | [Security middleware](#security-middleware) | | [**MaxRequestBodySize**](#request-limits) | 30 MB | Review and lower | Review and lower | [Configurable Limits](#configurable-limits) | | [**TLS Protocol Versions**](#tls-protocol-versions) | OS default | Review—ensure TLS 1.0/1.1 disabled | N/A (proxy terminates) | [Transport Security](#transport-security-tlshttps) | | [**Client Certificates**](#client-certificate-modes-mtls) | `NoCertificate` | Configure if mTLS needed | N/A (proxy handles) | [Transport Security](#transport-security-tlshttps) | diff --git a/aspnetcore/fundamentals/servers/yarp/config-files.md b/aspnetcore/fundamentals/servers/yarp/config-files.md index 852476a401f5..7d0901695e9c 100644 --- a/aspnetcore/fundamentals/servers/yarp/config-files.md +++ b/aspnetcore/fundamentals/servers/yarp/config-files.md @@ -41,7 +41,7 @@ app.Run(); ``` > [!NOTE] -> For details about middleware ordering, see [ASP.NET Core Middleware > Middleware order](/aspnet/core/fundamentals/middleware/#middleware-order). +> For details about middleware ordering, see [ASP.NET Core middleware > Middleware order](/aspnet/core/fundamentals/middleware/#middleware-order). Configuration can be modified during the load sequence by using [YARP configuration filters](xref:fundamentals/servers/yarp/config-filters). diff --git a/aspnetcore/fundamentals/servers/yarp/cors.md b/aspnetcore/fundamentals/servers/yarp/cors.md index 8e42f1086482..64411a4d7ee5 100644 --- a/aspnetcore/fundamentals/servers/yarp/cors.md +++ b/aspnetcore/fundamentals/servers/yarp/cors.md @@ -48,7 +48,7 @@ Example: } ``` -[CORS policies](/aspnet/core/security/cors#cors-with-named-policy-and-middleware) are an ASP.NET Core concept that the proxy utilizes. The proxy provides the above configuration to specify a policy per route and the rest is handled by existing ASP.NET Core CORS Middleware. +[CORS policies](/aspnet/core/security/cors#cors-with-named-policy-and-middleware) are an ASP.NET Core concept that the proxy utilizes. The proxy provides the above configuration to specify a policy per route and the rest is handled by existing ASP.NET Core CORS middleware. CORS policies can be configured in the application as follows: ```csharp diff --git a/aspnetcore/fundamentals/servers/yarp/dests-health-checks.md b/aspnetcore/fundamentals/servers/yarp/dests-health-checks.md index 660152ad190a..095595e2b25b 100644 --- a/aspnetcore/fundamentals/servers/yarp/dests-health-checks.md +++ b/aspnetcore/fundamentals/servers/yarp/dests-health-checks.md @@ -188,7 +188,7 @@ public class CustomProbingRequestFactory : IProbingRequestFactory ``` ## Passive health checks -YARP can passively watch for successes and failures in client request proxying to reactively evaluate destination health states. Responses to the proxied requests are intercepted by a dedicated passive health check middleware which passes them to a policy configured on the cluster. The policy analyzes the responses to evaluate if the destinations that produced them are healthy or not. Then, it calculates and assigns new passive health states to the respective destinations and rebuilds the cluster's healthy destination collection. +YARP can passively watch for successes and failures in client request proxying to reactively evaluate destination health states. Responses to the proxied requests are intercepted by a dedicated passive health checks middleware which passes them to a policy configured on the cluster. The policy analyzes the responses to evaluate if the destinations that produced them are healthy or not. Then, it calculates and assigns new passive health states to the respective destinations and rebuilds the cluster's healthy destination collection. Note the response is normally sent to the client before the passive health policy runs, so a policy cannot intercept the response body, nor modify anything in the response headers unless the proxy application introduces full response buffering. diff --git a/aspnetcore/fundamentals/servers/yarp/extensibility.md b/aspnetcore/fundamentals/servers/yarp/extensibility.md index c52136f2f967..51fc2ef7f4ed 100644 --- a/aspnetcore/fundamentals/servers/yarp/extensibility.md +++ b/aspnetcore/fundamentals/servers/yarp/extensibility.md @@ -13,8 +13,8 @@ ai-usage: ai-assisted There are 2 main styles of extensibility for YARP, depending on the routing behavior desired: -* Middleware Pipeline -* Http Forwarder +* Middleware pipeline +* HTTP forwarder ## Middleware pipeline @@ -34,7 +34,7 @@ Most of the prebuilt pipeline can be customized through code: You can also change the pipeline definition to replace modules with your own implementations or add additional modules as needed. For more information see [Middleware](xref:fundamentals/servers/yarp/middleware). -## HTTP Forwarder +## HTTP forwarder If the YARP pipeline is too rigid for your use case or the scale of routing rules and destinations isn't suitable for loading into memory, then you can implement your own routing logic and use the HTTP Forwarder to direct requests to your chosen destination. The `HttpForwarder` component takes the HTTP context and forwards the request to the supplied destination. diff --git a/aspnetcore/fundamentals/servers/yarp/middleware.md b/aspnetcore/fundamentals/servers/yarp/middleware.md index f8daaf957a4e..79cd361515d5 100644 --- a/aspnetcore/fundamentals/servers/yarp/middleware.md +++ b/aspnetcore/fundamentals/servers/yarp/middleware.md @@ -1,7 +1,7 @@ --- uid: fundamentals/servers/yarp/middleware -title: YARP Middleware -description: YARP Middleware +title: YARP middleware +description: YARP middleware author: wadepickett ms.author: wpickett ms.date: 04/04/2025 @@ -10,7 +10,7 @@ content_well_notification: AI-contribution ai-usage: ai-assisted --- -# YARP Middleware +# YARP middleware ## Introduction @@ -30,7 +30,7 @@ app.Run(); The parameterless `MapReverseProxy()` in [ReverseProxyIEndpointRouteBuilderExtensions](xref:Microsoft.AspNetCore.Builder.ReverseProxyIEndpointRouteBuilderExtensions) overload includes all standard proxy middleware for [session affinity](xref:fundamentals/servers/yarp/session-affinity), [load balancing](xref:fundamentals/servers/yarp/load-balancing), [passive health checks](dests-health-checks.md#passive-health-checks), and the final proxying of the request. Each of these check the configuration of the matched route, cluster, and destination and perform their task accordingly. -## Adding Middleware +## Add middleware Middleware added to your application pipeline will see the request in different states of processing depending on where the middleware is added. Middleware added before `UseRouting` will see all requests and can manipulate them before any routing takes place. Middleware added between `UseRouting` and `UseEndpoints` can call `HttpContext.GetEndpoint()` to check which endpoint routing matched the request to (if any), and use any metadata that was associated with that endpoint. This is how [Authentication, Authorization](xref:fundamentals/servers/yarp/authn-authz) and [CORS](xref:fundamentals/servers/yarp/cors) are handled. @@ -53,7 +53,7 @@ app.MapReverseProxy(proxyPipeline => By default this overload of `MapReverseProxy` only includes the minimal setup, proxying logic, and limit enforcement at the start and end of its pipeline. Middleware for session affinity, load balancing, and passive health checks are not included by default so that you can exclude, replace, or control their ordering with any additional middleware. -## Custom Proxy Middleware +## Custom proxy middleware Middleware inside the `MapReverseProxy` pipeline have access to all of the proxy data and state associated with a request (the route, cluster, destinations, etc.) through the [IReverseProxyFeature](xref:Yarp.ReverseProxy.Model.IReverseProxyFeature). This is available from `HttpContext.Features` or the extension method `HttpContext.GetReverseProxyFeature()`. diff --git a/aspnetcore/fundamentals/servers/yarp/timeouts.md b/aspnetcore/fundamentals/servers/yarp/timeouts.md index 535998149aa7..9e45a0b9aebd 100644 --- a/aspnetcore/fundamentals/servers/yarp/timeouts.md +++ b/aspnetcore/fundamentals/servers/yarp/timeouts.md @@ -14,7 +14,7 @@ ai-usage: ai-assisted ## Introduction -.NET 8 introduced the [Request Timeouts Middleware](/aspnet/core/performance/timeouts) to enable configuring request timeouts globally as well as per endpoint. This functionality is also available in YARP 2.1 when running on .NET 8 or newer. +.NET 8 introduced the [request timeouts middleware](/aspnet/core/performance/timeouts) to enable configuring request timeouts globally as well as per endpoint. This functionality is also available in YARP 2.1 when running on .NET 8 or newer. ## Defaults Requests do not have any timeouts by default, other than the [ActivityTimeout](xref:fundamentals/servers/yarp/http-client-config#HttpRequest) used to clean up idle requests. A default policy specified in [RequestTimeoutOptions](/dotnet/api/microsoft.aspnetcore.http.timeouts.requesttimeoutoptions) will apply to proxied requests as well. diff --git a/aspnetcore/fundamentals/servers/yarp/transforms.md b/aspnetcore/fundamentals/servers/yarp/transforms.md index 9a9443c81ca4..63366e604b51 100644 --- a/aspnetcore/fundamentals/servers/yarp/transforms.md +++ b/aspnetcore/fundamentals/servers/yarp/transforms.md @@ -50,7 +50,7 @@ Transforms fall into a few categories: [Request](./transforms-request.md), [Resp If the built-in set of transforms is insufficient, then custom transforms can be added via [extensibility](./extensibility-transforms.md). -## Adding transforms +## Add transforms Transforms can be added to routes either through configuration or programmatically. diff --git a/aspnetcore/fundamentals/startup/includes/startup56.md b/aspnetcore/fundamentals/startup/includes/startup56.md index 8318624a5ae1..6dd0e90e6d81 100644 --- a/aspnetcore/fundamentals/startup/includes/startup56.md +++ b/aspnetcore/fundamentals/startup/includes/startup56.md @@ -119,7 +119,7 @@ The [ASP.NET Core templates](/dotnet/core/tools/dotnet-new) configure the pipeli * [Developer Exception Page](xref:fundamentals/error-handling#developer-exception-page) * [Exception handler](xref:fundamentals/error-handling#exception-handler-page) -* [HTTP Strict Transport Security (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) +* [HTTP Strict Transport Security (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) * [HTTPS redirection](xref:security/enforcing-ssl) * [Static files](xref:fundamentals/static-files) * ASP.NET Core [MVC](xref:mvc/overview) and [Razor Pages](xref:razor-pages/index) diff --git a/aspnetcore/fundamentals/static-files.md b/aspnetcore/fundamentals/static-files.md index c07d720ba3aa..6cfab34d9e90 100644 --- a/aspnetcore/fundamentals/static-files.md +++ b/aspnetcore/fundamentals/static-files.md @@ -2,7 +2,7 @@ title: Static files in ASP.NET Core ai-usage: ai-assisted author: wadepickett -description: Learn how to serve and secure static files and configure Map Static Assets endpoint conventions and Static File Middleware in ASP.NET Core web apps. +description: Learn how to serve and secure static files and configure Map Static Assets endpoint conventions and static file middleware in ASP.NET Core web apps. monikerRange: '>= aspnetcore-3.1' ms.author: wpickett ms.reviewer: wpickett @@ -44,7 +44,7 @@ Map Static Assets provides the following benefits: Map Static Assets doesn't provide features for minification or other file transformations. Minification is usually handled by custom code or [third-party tooling](xref:blazor/fundamentals/index#community-links-to-blazor-resources). > [!NOTE] -> [Default documents](#serve-default-documents) are served compressed by only when Default Files Middleware () runs before Routing Middleware (). `UseDefaultFiles` rewrites the request path to the default document (for example, `/` to `/index.html`) before endpoint routing matches the request, which allows the Map Static Assets endpoint to serve the compressed asset. Calling `UseDefaultFiles` before `MapStaticAssets` satisfies this requirement. +> [Default documents](#serve-default-documents) are served compressed by only when default files middleware () runs before routing middleware (). `UseDefaultFiles` rewrites the request path to the default document (for example, `/` to `/index.html`) before endpoint routing matches the request, which allows the Map Static Assets endpoint to serve the compressed asset. Calling `UseDefaultFiles` before `MapStaticAssets` satisfies this requirement. :::moniker-end @@ -54,9 +54,9 @@ To enable static file handling in ASP.NET Core, call is called in the app's request processing pipeline. Files are served from the path specified in or , which defaults to the web root folder, typically `wwwroot`. +Static file middleware enables static file serving and is used by an app when is called in the app's request processing pipeline. Files are served from the path specified in or , which defaults to the web root folder, typically `wwwroot`. :::moniker-end @@ -227,19 +227,19 @@ var builder = WebApplication.CreateBuilder(new WebApplicationOptions :::moniker range=">= aspnetcore-9.0" -## Static File Middleware +## Static file middleware -Static File Middleware enables static file serving in specific static files scenarios, usually in addition to Map Static Assets endpoint routing conventions (). +Static file middleware enables static file serving in specific static files scenarios, usually in addition to Map Static Assets endpoint routing conventions (). -Static File Middleware is included in request processing when is called in the app's request processing pipeline, typically after Map Static Assets endpoint conventions () are added. +Static file middleware is included in request processing when is called in the app's request processing pipeline, typically after Map Static Assets endpoint conventions () are added. -Map Static Assets endpoint conventions are used in apps that target .NET 9 or later. Static File Middleware must be used in apps that target versions of .NET prior to .NET 9. +Map Static Assets endpoint conventions are used in apps that target .NET 9 or later. Static file middleware must be used in apps that target versions of .NET prior to .NET 9. -Static File Middleware serves static files, but it doesn't provide the same level of optimization as Map Static Assets endpoint conventions. The build-time compression and fingerprinting features of Map Static Assets endpoint conventions aren't available when only relying on Static File Middleware. +Static file middleware serves static files, but it doesn't provide the same level of optimization as Map Static Assets endpoint conventions. The build-time compression and fingerprinting features of Map Static Assets endpoint conventions aren't available when only relying on static file middleware. -The endpoint conventions are optimized for serving assets that the app has knowledge of at runtime. If the app serves assets from other locations, such as disk or embedded resources, use Static File Middleware. +The endpoint conventions are optimized for serving assets that the app has knowledge of at runtime. If the app serves assets from other locations, such as disk or embedded resources, use static file middleware. -The following features covered in this article are supported with Static File Middleware but not with Map Static Assets endpoint conventions: +The following features covered in this article are supported with static file middleware but not with Map Static Assets endpoint conventions: * [Serve files outside of the web root directory](#serve-files-outside-of-the-web-root-directory-via-usestaticfiles) * [Set HTTP response headers](#set-http-response-headers) @@ -264,7 +264,7 @@ Consider the following directory hierarchy with static files residing outside of * `images` * `red-rose.jpg` -A request can access `red-rose.jpg` by configuring a new instance of Static File Middleware: +A request can access `red-rose.jpg` by configuring a new instance of static file middleware: Namespaces for the following API: @@ -371,7 +371,7 @@ app.Environment.WebRootFileProvider = compositeProvider; ## Set HTTP response headers -Use to set HTTP response headers. In addition to configuring Static File Middleware to serve static files, the following code sets the [`Cache-Control` header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control) to 604,800 seconds (one week). +Use to set HTTP response headers. In addition to configuring static file middleware to serve static files, the following code sets the [`Cache-Control` header](https://developer.mozilla.org/docs/Web/HTTP/Headers/Cache-Control) to 604,800 seconds (one week). Namespaces for the following API: @@ -412,7 +412,7 @@ In the following example, the exclusion patten adds the static files in the `lib ``` -After HTTPS Redirection Middleware (`app.UseHttpsRedirection();`) processing in the `Program` file: +After HTTPS redirection middleware (`app.UseHttpsRedirection();`) processing in the `Program` file: * Call to handle the excluded files (`lib/icons/**`) and any other files not covered by . * Call after to handle critical application files (CSS, JS, images). @@ -429,7 +429,7 @@ app.MapStaticAssets(); :::moniker range=">= aspnetcore-9.0" -When an app adopts a [fallback authorization policy](xref:security/authorization/secure-data#require-authenticated-users), it requires authorization for all requests that don't explicitly specify an authorization policy. This requirement includes requests for static files after Authorization Middleware processes requests. To allow anonymous access to static files, apply to the endpoint builder for static files: +When an app adopts a [fallback authorization policy](xref:security/authorization/secure-data#require-authenticated-users), it requires authorization for all requests that don't explicitly specify an authorization policy. This requirement includes requests for static files after authorization middleware processes requests. To allow anonymous access to static files, apply to the endpoint builder for static files: ```csharp app.MapStaticAssets().Add(endpointBuilder => @@ -440,10 +440,10 @@ app.MapStaticAssets().Add(endpointBuilder => :::moniker range="< aspnetcore-9.0" -When an app adopts a [fallback authorization policy](xref:security/authorization/secure-data#require-authenticated-users), authorization is required for all requests that don't explicitly specify an authorization policy, including requests for static files after Authorization Middleware processes requests. The ASP.NET Core templates allow anonymous access to static files by calling before calling . Most apps follow this pattern. When the Static File Middleware is called before the authorization middleware: +When an app adopts a [fallback authorization policy](xref:security/authorization/secure-data#require-authenticated-users), authorization is required for all requests that don't explicitly specify an authorization policy, including requests for static files after authorization middleware processes requests. The ASP.NET Core templates allow anonymous access to static files by calling before calling . Most apps follow this pattern. When the static file middleware is called before the authorization middleware: * No authorization checks are performed on the static files. -* Static files served by the Static File Middleware, such as those in the web root (typically, `wwwroot`), are publicly accessible. +* Static files served by the static file middleware, such as those in the web root (typically, `wwwroot`), are publicly accessible. :::moniker-end @@ -523,11 +523,11 @@ In the preceding code, the fallback authorization policy requires authenticated adds to the current instance, which enforces that the current user is authenticated. -Static assets stored in the app's web root are publicly accessible because the default Static File Middleware () is called before . Static assets in the `SecureStaticFiles` folder require authentication. +Static assets stored in the app's web root are publicly accessible because the default static file middleware () is called before . Static assets in the `SecureStaticFiles` folder require authentication. An alternative approach to serve files based on authorization is to: -* Store the files outside of the web root and any directory accessible to Static File Middleware. +* Store the files outside of the web root and any directory accessible to static file middleware. * Serve the files via an action method to which authorization is applied and return a object. From a Razor page (`Pages/BannerImage.cshtml.cs`): @@ -793,7 +793,7 @@ The preceding code allows directory browsing of the `wwwroot/images` folder usin :::moniker range=">= aspnetcore-6.0" - adds services required by the Directory Browsing Middleware, including . These services may be added by other calls, such as , but we recommend calling to ensure the services are added. + adds services required by the directory-browsing middleware, including . These services may be added by other calls, such as , but we recommend calling to ensure the services are added. :::moniker-end @@ -1061,7 +1061,7 @@ For more information, see [MIME content types](https://www.iana.org/assignments/ ## Non-standard content types -The Static File Middleware understands almost 400 known file content types. If the user requests a file with an unknown file type, the Static File Middleware passes the request to the next middleware in the pipeline. If no middleware handles the request, a *404 Not Found* response is returned. If directory browsing is enabled, a link to the file is displayed in a directory listing. +The static file middleware understands almost 400 known file content types. If the user requests a file with an unknown file type, the static file middleware passes the request to the next middleware in the pipeline. If no middleware handles the request, a *404 Not Found* response is returned. If directory browsing is enabled, a link to the file is displayed in a directory listing. The following code enables serving unknown content types and renders the unknown file as an image: diff --git a/aspnetcore/fundamentals/url-rewriting.md b/aspnetcore/fundamentals/url-rewriting.md index 9ac083d9cb19..6bc2cf35e422 100644 --- a/aspnetcore/fundamentals/url-rewriting.md +++ b/aspnetcore/fundamentals/url-rewriting.md @@ -1,14 +1,14 @@ --- -title: URL Rewriting Middleware in ASP.NET Core +title: URL rewriting middleware in ASP.NET Core author: wadepickett -description: Learn about URL rewriting and redirecting with URL Rewriting Middleware in ASP.NET Core applications. +description: Learn about URL rewriting and redirecting with URL rewriting middleware in ASP.NET Core applications. monikerRange: '>= aspnetcore-2.1' ms.author: wpickett ms.custom: mvc, sfi-image-nochange ms.date: 07/06/2026 uid: fundamentals/url-rewriting --- -# URL Rewriting Middleware in ASP.NET Core +# URL rewriting middleware in ASP.NET Core [!INCLUDE[](~/includes/not-latest-version.md)] @@ -16,7 +16,7 @@ By [Kirk Larkin](https://twitter.com/serpent5) and [Rick Anderson](https://twitt :::moniker range=">= aspnetcore-6.0" -This article introduces URL rewriting with instructions on how to use URL Rewriting Middleware in ASP.NET Core apps. +This article introduces URL rewriting with instructions on how to use URL rewriting middleware in ASP.NET Core apps. URL rewriting is the act of modifying request URLs based on one or more predefined rules. URL rewriting creates an abstraction between resource locations and their addresses so that the locations and addresses aren't tightly linked. URL rewriting is valuable in several scenarios to: @@ -32,7 +32,7 @@ URL rewriting is the act of modifying request URLs based on one or more predefin ## URL redirect and URL rewrite -The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL Rewriting Middleware is capable of meeting the need for both. +The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL rewriting middleware is capable of meeting the need for both. A *URL redirect* involves a client-side operation, where the client is instructed to access a resource at a different address than the client originally requested. This requires a round trip to the server. The redirect URL returned to the client appears in the browser's address bar when the client makes a new request for the resource. @@ -58,11 +58,11 @@ Although the client might be able to retrieve the resource at the rewritten URL, ## URL rewriting sample app -Explore the features of the URL Rewriting Middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. +Explore the features of the URL rewriting middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. ## When to use URL rewriting middleware -Use URL Rewriting Middleware when the following approaches aren't satisfactory: +Use URL rewriting middleware when the following approaches aren't satisfactory: * [URL Rewrite module with IIS on Windows Server](https://www.iis.net/downloads/microsoft/url-rewrite) * [Apache mod_rewrite module on Apache Server](https://httpd.apache.org/docs/2.4/rewrite/) @@ -81,7 +81,7 @@ The main reasons to use the server-based URL rewriting technologies in IIS, Apac ## Extension and options -Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of the rewrite rules. Chain multiple rules ***in the order that they should be processed***. The `RewriteOptions` are passed into the URL Rewriting Middleware as it's added to the request pipeline with : +Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of the rewrite rules. Chain multiple rules ***in the order that they should be processed***. The `RewriteOptions` are passed into the URL rewriting middleware as it's added to the request pipeline with : [!code-csharp[](url-rewriting/samples/6.x/SampleApp/Program.cs?name=snippet1&highlight=7-24)] @@ -135,7 +135,7 @@ Use > [!NOTE] -> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware. For more information, see [Enforce HTTPS](xref:security/enforcing-ssl#require-https). +> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware. For more information, see [Enforce HTTPS](xref:security/enforcing-ssl#require-https). The sample app demonstrates how to use `AddRedirectToHttps` or `AddRedirectToHttpsPermanent`. Make an insecure HTTP request to the app at `http://redirect6.azurewebsites.net/iis-rules-rewrite/xyz`. When testing HTTP to HTTPS redirection with localhost: @@ -308,7 +308,7 @@ Use to impleme The sample app demonstrates a method that redirects requests for paths that end with `.xml`. When a request is made for `/file.xml`: * The request is redirected to `/xmlfiles/file.xml` -* The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, Static File Middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. +* The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, static file middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. @@ -316,7 +316,7 @@ The sample app demonstrates a method that redirects requests for paths that end [!code-csharp[](url-rewriting/samples/6.x/SampleApp/RewriteRules.cs?name=snippet_RedirectXmlFileRequests&highlight=15-19)] -This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static File Middleware serves the file based on the updated request path: +This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static file middleware serves the file based on the updated request path: [!code-csharp[](url-rewriting/samples/6.x/SampleApp/Program.cs?name=snippet_redirect2&highlight=20,27)] @@ -362,7 +362,7 @@ In most of the preceding regular expression samples, the literal `path` is used :::moniker range=">= aspnetcore-3.0 < aspnetcore-6.0" -This document introduces URL rewriting with instructions on how to use URL Rewriting Middleware in ASP.NET Core apps. +This document introduces URL rewriting with instructions on how to use URL rewriting middleware in ASP.NET Core apps. URL rewriting is the act of modifying request URLs based on one or more predefined rules. URL rewriting creates an abstraction between resource locations and their addresses so that the locations and addresses aren't tightly linked. URL rewriting is valuable in several scenarios to: @@ -381,7 +381,7 @@ URL rewriting is the act of modifying request URLs based on one or more predefin ## URL redirect and URL rewrite -The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL Rewriting Middleware is capable of meeting the need for both. +The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL rewriting middleware is capable of meeting the need for both. A *URL redirect* involves a client-side operation, where the client is instructed to access a resource at a different address than the client originally requested. This requires a round trip to the server. The redirect URL returned to the client appears in the browser's address bar when the client makes a new request for the resource. @@ -407,11 +407,11 @@ Although the client might be able to retrieve the resource at the rewritten URL, ## URL rewriting sample app -You can explore the features of the URL Rewriting Middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. +You can explore the features of the URL rewriting middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. ## When to use URL rewriting middleware -Use URL Rewriting Middleware when you're unable to use the following approaches: +Use URL rewriting middleware when you're unable to use the following approaches: * [URL Rewrite module with IIS on Windows Server](https://www.iis.net/downloads/microsoft/url-rewrite) * [Apache mod_rewrite module on Apache Server](https://httpd.apache.org/docs/2.4/rewrite/) @@ -430,11 +430,11 @@ The main reasons to use the server-based URL rewriting technologies in IIS, Apac ## Package -URL Rewriting Middleware is provided by the [Microsoft.AspNetCore.Rewrite](https://www.nuget.org/packages/Microsoft.AspNetCore.Rewrite) package, which is implicitly included in ASP.NET Core apps. +URL rewriting middleware is provided by the [Microsoft.AspNetCore.Rewrite](https://www.nuget.org/packages/Microsoft.AspNetCore.Rewrite) package, which is implicitly included in ASP.NET Core apps. ## Extension and options -Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of your rewrite rules. Chain multiple rules in the order that you would like them processed. The `RewriteOptions` are passed into the URL Rewriting Middleware as it's added to the request pipeline with : +Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of your rewrite rules. Chain multiple rules in the order that you would like them processed. The `RewriteOptions` are passed into the URL rewriting middleware as it's added to the request pipeline with : [!code-csharp[](url-rewriting/samples/3.x/SampleApp/Startup.cs?name=snippet1)] @@ -502,7 +502,7 @@ public void Configure(IApplicationBuilder app) ``` > [!NOTE] -> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware. For more information, see the [Enforce HTTPS](xref:security/enforcing-ssl#require-https) topic. +> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware. For more information, see the [Enforce HTTPS](xref:security/enforcing-ssl#require-https) topic. The sample app is capable of demonstrating how to use `AddRedirectToHttps` or `AddRedirectToHttpsPermanent`. Add the extension method to the `RewriteOptions`. Make an insecure request to the app at any URL. Dismiss the browser security warning that the self-signed certificate is untrusted or create an exception to trust the certificate. @@ -667,13 +667,13 @@ Use to impleme [!code-csharp[](url-rewriting/samples/3.x/SampleApp/Startup.cs?name=snippet1&highlight=14)] -The sample app demonstrates a method that redirects requests for paths that end with `.xml`. If a request is made for `/file.xml`, the request is redirected to `/xmlfiles/file.xml`. The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, Static File Middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. +The sample app demonstrates a method that redirects requests for paths that end with `.xml`. If a request is made for `/file.xml`, the request is redirected to `/xmlfiles/file.xml`. The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, static file middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. `RewriteRules.cs`: [!code-csharp[](url-rewriting/samples/3.x/SampleApp/RewriteRules.cs?name=snippet_RedirectXmlFileRequests&highlight=14-18)] -This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static File Middleware serves the file based on the updated request path: +This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static file middleware serves the file based on the updated request path: [!code-csharp[](url-rewriting/samples/3.x/SampleApp/Startup.cs?name=snippet1&highlight=15,22)] @@ -716,7 +716,7 @@ Original Request: `/image.jpg` :::moniker range="< aspnetcore-3.0" -This document introduces URL rewriting with instructions on how to use URL Rewriting Middleware in ASP.NET Core apps. +This document introduces URL rewriting with instructions on how to use URL rewriting middleware in ASP.NET Core apps. URL rewriting is the act of modifying request URLs based on one or more predefined rules. URL rewriting creates an abstraction between resource locations and their addresses so that the locations and addresses aren't tightly linked. URL rewriting is valuable in several scenarios to: @@ -735,7 +735,7 @@ URL rewriting is the act of modifying request URLs based on one or more predefin ## URL redirect and URL rewrite -The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL Rewriting Middleware is capable of meeting the need for both. +The difference in wording between *URL redirect* and *URL rewrite* is subtle but has important implications for providing resources to clients. ASP.NET Core's URL rewriting middleware is capable of meeting the need for both. A *URL redirect* involves a client-side operation, where the client is instructed to access a resource at a different address than the client originally requested. This requires a round trip to the server. The redirect URL returned to the client appears in the browser's address bar when the client makes a new request for the resource. @@ -761,11 +761,11 @@ Although the client might be able to retrieve the resource at the rewritten URL, ## URL rewriting sample app -You can explore the features of the URL Rewriting Middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. +You can explore the features of the URL rewriting middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/fundamentals/url-rewriting/samples/). The app applies redirect and rewrite rules and shows the redirected or rewritten URL for several scenarios. -## When to use URL Rewriting Middleware +## When to use URL rewriting middleware -Use URL Rewriting Middleware when you're unable to use the following approaches: +Use URL rewriting middleware when you're unable to use the following approaches: * [URL Rewrite module with IIS on Windows Server](https://www.iis.net/downloads/microsoft/url-rewrite) * [Apache mod_rewrite module on Apache Server](https://httpd.apache.org/docs/2.4/rewrite/) @@ -790,7 +790,7 @@ When not using the `Microsoft.AspNetCore.App` metapackage, add a project referen ## Extension and options -Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of your rewrite rules. Chain multiple rules in the order that you would like them processed. The `RewriteOptions` are passed into the URL Rewriting Middleware as it's added to the request pipeline with : +Establish URL rewrite and redirect rules by creating an instance of the [RewriteOptions](xref:Microsoft.AspNetCore.Rewrite.RewriteOptions) class with extension methods for each of your rewrite rules. Chain multiple rules in the order that you would like them processed. The `RewriteOptions` are passed into the URL rewriting middleware as it's added to the request pipeline with : [!code-csharp[](url-rewriting/samples/2.x/SampleApp/Startup.cs?name=snippet1)] @@ -858,7 +858,7 @@ public void Configure(IApplicationBuilder app) ``` > [!NOTE] -> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware. For more information, see the [Enforce HTTPS](xref:security/enforcing-ssl#require-https) topic. +> When redirecting to a secure endpoint without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware. For more information, see the [Enforce HTTPS](xref:security/enforcing-ssl#require-https) topic. The sample app is capable of demonstrating how to use `AddRedirectToHttps` or `AddRedirectToHttpsPermanent`. Add the extension method to the `RewriteOptions`. Make an insecure request to the app at any URL. Dismiss the browser security warning that the self-signed certificate is untrusted or create an exception to trust the certificate. @@ -1023,13 +1023,13 @@ Use to impleme [!code-csharp[](url-rewriting/samples/2.x/SampleApp/Startup.cs?name=snippet1&highlight=14)] -The sample app demonstrates a method that redirects requests for paths that end with `.xml`. If a request is made for `/file.xml`, the request is redirected to `/xmlfiles/file.xml`. The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, Static File Middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. +The sample app demonstrates a method that redirects requests for paths that end with `.xml`. If a request is made for `/file.xml`, the request is redirected to `/xmlfiles/file.xml`. The status code is set to `301 - Moved Permanently`. When the browser makes a new request for `/xmlfiles/file.xml`, static file middleware serves the file to the client from the *wwwroot/xmlfiles* folder. For a redirect, explicitly set the status code of the response. Otherwise, a *200 - OK* status code is returned, and the redirect doesn't occur on the client. `RewriteRules.cs`: [!code-csharp[](url-rewriting/samples/2.x/SampleApp/RewriteRules.cs?name=snippet_RedirectXmlFileRequests&highlight=14-18)] -This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static File Middleware serves the file based on the updated request path: +This approach can also rewrite requests. The sample app demonstrates rewriting the path for any text file request to serve the *file.txt* text file from the *wwwroot* folder. Static file middleware serves the file based on the updated request path: [!code-csharp[](url-rewriting/samples/2.x/SampleApp/Startup.cs?name=snippet1&highlight=15,22)] diff --git a/aspnetcore/fundamentals/url-rewriting/samples/2.x/SampleApp/README.md b/aspnetcore/fundamentals/url-rewriting/samples/2.x/SampleApp/README.md index c0ad6b43caf6..26ef0edb9475 100644 --- a/aspnetcore/fundamentals/url-rewriting/samples/2.x/SampleApp/README.md +++ b/aspnetcore/fundamentals/url-rewriting/samples/2.x/SampleApp/README.md @@ -1,8 +1,8 @@ # ASP.NET Core URL Rewriting Sample -This sample illustrates usage of ASP.NET Core URL Rewriting Middleware. The app demonstrates URL redirect and URL rewriting options. +This sample illustrates usage of ASP.NET Core URL rewriting middleware. The app demonstrates URL redirect and URL rewriting options. -When running the sample, non-file responses return the rewritten or redirected URL when one of the rules is applied to a request URL. For the XML and text file examples, Static File Middleware serves the file after the request URL is rewritten by the middleware. +When running the sample, non-file responses return the rewritten or redirected URL when one of the rules is applied to a request URL. For the XML and text file examples, static file middleware serves the file after the request URL is rewritten by the middleware. ## Examples in this sample diff --git a/aspnetcore/fundamentals/url-rewriting/samples/3.x/SampleApp/README.md b/aspnetcore/fundamentals/url-rewriting/samples/3.x/SampleApp/README.md index 53f4b87d7268..1b3614103572 100644 --- a/aspnetcore/fundamentals/url-rewriting/samples/3.x/SampleApp/README.md +++ b/aspnetcore/fundamentals/url-rewriting/samples/3.x/SampleApp/README.md @@ -1,11 +1,11 @@ # ASP.NET Core URL Rewriting Sample -This sample illustrates usage of ASP.NET Core URL Rewriting Middleware. The app demonstrates +This sample illustrates usage of ASP.NET Core URL rewriting middleware. The app demonstrates URL redirect and URL rewriting options. When running the sample, non-file responses return the rewritten or redirected URL when one of the rules is applied to a request URL. For the XML and text file examples, -Static File Middleware serves the file after the request URL is rewritten by the middleware. +Static file middleware serves the file after the request URL is rewritten by the middleware. ## Examples in this sample diff --git a/aspnetcore/fundamentals/url-rewriting/samples/6.x/SampleApp/README.md b/aspnetcore/fundamentals/url-rewriting/samples/6.x/SampleApp/README.md index e1add6f7bbfa..234b50a57a5e 100644 --- a/aspnetcore/fundamentals/url-rewriting/samples/6.x/SampleApp/README.md +++ b/aspnetcore/fundamentals/url-rewriting/samples/6.x/SampleApp/README.md @@ -1,11 +1,11 @@ # ASP.NET Core URL Rewriting Sample -This sample illustrates usage of ASP.NET Core URL Rewriting Middleware. The app demonstrates +This sample illustrates usage of ASP.NET Core URL rewriting middleware. The app demonstrates URL redirect and URL rewriting options. When running the sample, non-file responses return the rewritten or redirected URL when one of the rules is applied to a request URL. For the XML and text file examples, -Static File Middleware serves the file after the request URL is rewritten by the middleware. +Static file middleware serves the file after the request URL is rewritten by the middleware. ## Examples in this sample diff --git a/aspnetcore/grpc/configuration.md b/aspnetcore/grpc/configuration.md index c231facb0e98..877e079f844b 100644 --- a/aspnetcore/grpc/configuration.md +++ b/aspnetcore/grpc/configuration.md @@ -26,7 +26,7 @@ The following table describes options for configuring gRPC services: | `CompressionProviders` | gzip | A collection of compression providers used to compress and decompress messages. Custom compression providers can be created and added to the collection. The default configured providers support **gzip** compression. | | `ResponseCompressionAlgorithm` | `null` | The compression algorithm used to compress messages sent from the server. The algorithm must match a compression provider in `CompressionProviders`. For the algorithm to compress a response, the client must indicate it supports the algorithm by sending it in the **grpc-accept-encoding** header. | | `ResponseCompressionLevel` | `null` | The compress level used to compress messages sent from the server. | -| `Interceptors` | None | A collection of interceptors that are run with each gRPC call. Interceptors are run in the order they are registered. Globally configured interceptors are run before interceptors configured for a single service.

Interceptors have a per-request lifetime by default. The interceptor constructor is called and parameters are resolved from [dependency injection (DI)](xref:fundamentals/dependency-injection). An interceptor type can also be registered with DI to override how it is created and its lifetime.

Interceptors offer similar functionalities compared to ASP.NET Core middleware. For more information, see [gRPC Interceptors vs. Middleware](xref:grpc/migration#grpc-interceptors-vs-middleware). | +| `Interceptors` | None | A collection of interceptors that are run with each gRPC call. Interceptors are run in the order they are registered. Globally configured interceptors are run before interceptors configured for a single service.

Interceptors have a per-request lifetime by default. The interceptor constructor is called and parameters are resolved from [dependency injection (DI)](xref:fundamentals/dependency-injection). An interceptor type can also be registered with DI to override how it is created and its lifetime.

Interceptors offer similar functionalities compared to ASP.NET Core middleware. For more information, see [gRPC Interceptors vs. middleware](xref:grpc/migration#grpc-interceptors-vs-middleware). | | `IgnoreUnknownServices` | `false` | If `true`, calls to unknown services and methods don't return an **UNIMPLEMENTED** status, and the request passes to the next registered middleware in ASP.NET Core. | Options can be configured for all services by providing an options delegate to the `AddGrpc` call in `Startup.ConfigureServices`: diff --git a/aspnetcore/grpc/interceptors.md b/aspnetcore/grpc/interceptors.md index dafb30f4421d..e87f0b295486 100644 --- a/aspnetcore/grpc/interceptors.md +++ b/aspnetcore/grpc/interceptors.md @@ -268,7 +268,7 @@ public void ConfigureServices(IServiceCollection services) } ``` -### gRPC Interceptors versus Middleware +### gRPC Interceptors versus middleware ASP.NET Core [middleware](xref:fundamentals/middleware/index) offers similar functionalities compared to interceptors in C-core-based gRPC apps. ASP.NET Core middleware and interceptors are conceptually similar. Both: @@ -278,7 +278,7 @@ ASP.NET Core [middleware](xref:fundamentals/middleware/index) offers similar fun * In middleware, the `HttpContext` is a parameter. * In interceptors, the `HttpContext` can be accessed using the `ServerCallContext` parameter with the `ServerCallContext.GetHttpContext` extension method. This feature is specific to interceptors running in ASP.NET Core. -gRPC Interceptor differences from ASP.NET Core Middleware: +gRPC Interceptor differences from ASP.NET Core middleware: * Interceptors: * Operate on the gRPC layer of abstraction using the [`ServerCallContext`](https://grpc.io/grpc/csharp/api/Grpc.Core.ServerCallContext.html). diff --git a/aspnetcore/grpc/migration.md b/aspnetcore/grpc/migration.md index ce68ea96d578..b17534e3a3a7 100644 --- a/aspnetcore/grpc/migration.md +++ b/aspnetcore/grpc/migration.md @@ -127,7 +127,7 @@ C-core-based apps configure HTTPS through the [Server.Ports property](https://gr ASP.NET Core [middleware](xref:fundamentals/middleware/index) offers similar functionalities compared to interceptors in C-core-based gRPC apps. Both are supported by ASP.NET Core gRPC apps, so there's no need to rewrite interceptors. -For more information on how these features compare to each other, see [gRPC Interceptors versus Middleware](xref:grpc/interceptors#grpc-interceptors-versus-middleware). +For more information on how these features compare to each other, see [gRPC Interceptors versus middleware](xref:grpc/interceptors#grpc-interceptors-versus-middleware). ## Host gRPC in non-ASP.NET Core projects diff --git a/aspnetcore/host-and-deploy/aspnet-core-module.md b/aspnetcore/host-and-deploy/aspnet-core-module.md index 4373596f0a8f..eb8ea3677cef 100644 --- a/aspnetcore/host-and-deploy/aspnet-core-module.md +++ b/aspnetcore/host-and-deploy/aspnet-core-module.md @@ -363,7 +363,7 @@ Configure the managed stack size using the `stackSize` setting in bytes in `web. The proxy created between the ASP.NET Core Module and Kestrel uses the HTTP protocol. There's no risk of eavesdropping the traffic between the module and Kestrel from a location off of the server. -A pairing token is used to guarantee that IIS proxied the requests received by Kestrel and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware. +A pairing token is used to guarantee that IIS proxied the requests received by Kestrel and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS middleware. ## ASP.NET Core Module with an IIS Shared Configuration @@ -760,7 +760,7 @@ See [Configuration with web.config](#configuration-with-webconfig) for an exampl The proxy created between the ASP.NET Core Module and Kestrel uses the HTTP protocol. There's no risk of eavesdropping the traffic between the module and Kestrel from a location off of the server. -A pairing token is used to guarantee that the requests received by Kestrel were proxied by IIS and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware. +A pairing token is used to guarantee that the requests received by Kestrel were proxied by IIS and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS middleware. ## ASP.NET Core Module with an IIS Shared Configuration @@ -863,7 +863,7 @@ The following diagram illustrates the relationship between IIS, the ASP.NET Core Requests arrive from the web to the kernel-mode HTTP.sys driver. The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443. -The module specifies the port via an environment variable at startup, and the [IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. +The module specifies the port via an environment variable at startup, and the [IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. The middleware pipeline handles the request and passes it on as an `HttpContext` instance to the app's logic. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request. @@ -1002,7 +1002,7 @@ For more information on path formats, see [File path formats on Windows systems] The proxy created between the ASP.NET Core Module and Kestrel uses the HTTP protocol. There's no risk of eavesdropping the traffic between the module and Kestrel from a location off of the server. -A pairing token is used to guarantee that IIS proxied the requests received by Kestrel and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware. +A pairing token is used to guarantee that IIS proxied the requests received by Kestrel and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS middleware. ## ASP.NET Core Module with an IIS Shared Configuration diff --git a/aspnetcore/host-and-deploy/azure-apps/index.md b/aspnetcore/host-and-deploy/azure-apps/index.md index 5ea13b75ee83..34718aeb6b36 100644 --- a/aspnetcore/host-and-deploy/azure-apps/index.md +++ b/aspnetcore/host-and-deploy/azure-apps/index.md @@ -81,7 +81,7 @@ App settings in the Azure portal permit you to set environment variables for the ## Proxy server and load balancer scenarios -The [IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components), which configures Forwarded Headers Middleware when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). +The [IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components), which configures forwarded headers middleware when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). ## Monitoring and logging @@ -118,7 +118,7 @@ See the common deployment configuration errors for apps hosted by Azure App Serv [ASP.NET Core Data Protection keys](xref:security/data-protection/implementation/key-management#data-protection-implementation-key-management) are persisted to the *%HOME%\ASP.NET\DataProtection-Keys* folder. This folder is backed by network storage and is synchronized across all machines hosting the app. Keys aren't protected at rest. This folder supplies the key ring to all instances of an app in a single deployment slot. Separate deployment slots, such as Staging and Production, don't share a key ring. -When swapping between deployment slots, any system using data protection won't be able to decrypt stored data using the key ring inside the previous slot. ASP.NET Cookie Middleware uses data protection to protect its cookies. This leads to users being signed out of an app that uses the standard ASP.NET Cookie Middleware. For a slot-independent key ring solution, use an external key ring provider, such as: +When swapping between deployment slots, any system using data protection won't be able to decrypt stored data using the key ring inside the previous slot. ASP.NET cookie middleware uses data protection to protect its cookies. This leads to users being signed out of an app that uses the standard ASP.NET cookie middleware. For a slot-independent key ring solution, use an external key ring provider, such as: * Azure Blob Storage * Azure Key Vault diff --git a/aspnetcore/host-and-deploy/health-checks.md b/aspnetcore/host-and-deploy/health-checks.md index cf0ca1afebbb..f629c90468e5 100644 --- a/aspnetcore/host-and-deploy/health-checks.md +++ b/aspnetcore/host-and-deploy/health-checks.md @@ -17,7 +17,7 @@ By [Glenn Condron](https://github.com/glennc) and [Juergen Gutsch](https://twitt :::moniker range=">= aspnetcore-8.0" -ASP.NET Core offers Health Checks Middleware and libraries for reporting the health of app infrastructure components. +ASP.NET Core offers health checks middleware and libraries for reporting the health of app infrastructure components. Health checks are exposed by an app as HTTP endpoints. Health check endpoints can be configured for various real-time monitoring scenarios: @@ -31,7 +31,7 @@ Health checks are typically used with an external monitoring service or containe For many apps, a basic health probe configuration that reports the app's availability to process requests (*liveness*) is sufficient to discover the status of the app. -The basic configuration registers health check services and calls the Health Checks Middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes as a plaintext response to the client. The `HealthStatus` is , , or . +The basic configuration registers health check services and calls the health checks middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes as a plaintext response to the client. The `HealthStatus` is , , or . Register health check services with in `Program.cs`. Create a health check endpoint by calling . @@ -111,13 +111,13 @@ For more information, see [Host matching in routes with RequireHost](xref:fundam ### Require authorization -Call to run Authorization Middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used: +Call to run authorization middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used: :::code language="csharp" source="~/host-and-deploy/health-checks/samples/8.x/HealthChecksSample/Snippets/Program.cs" id="snippet_MapHealthChecksRequireAuthorization"::: ### Enable Cross-Origin Requests (CORS) -Although running health checks manually from a browser isn't a common scenario, CORS Middleware can be enabled by calling [`RequireCors`](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/CORS/src/Infrastructure/CorsEndpointConventionBuilderExtensions.cs#L20-#L40) on the health checks endpoints. The [`RequireCors`](/dotnet/api/microsoft.aspnetcore.builder.corsendpointconventionbuilderextensions.requirecors) overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. For more information, see . +Although running health checks manually from a browser isn't a common scenario, CORS middleware can be enabled by calling [`RequireCors`](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/CORS/src/Infrastructure/CorsEndpointConventionBuilderExtensions.cs#L20-#L40) on the health checks endpoints. The [`RequireCors`](/dotnet/api/microsoft.aspnetcore.builder.corsendpointconventionbuilderextensions.requirecors) overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. For more information, see . ## Health check options @@ -130,7 +130,7 @@ Although running health checks manually from a browser isn't a common scenario, ### Filter health checks -By default, the Health Checks Middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. +By default, the health checks middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. The following example filters the health checks so that only those tagged with `sample` run: @@ -144,7 +144,7 @@ Use controls whether the Health Checks Middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response: + controls whether the health checks middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response: :::code language="csharp" source="~/host-and-deploy/health-checks/samples/8.x/HealthChecksSample/Snippets/Program.cs" id="snippet_MapHealthChecksAllowCachingResponses"::: @@ -326,7 +326,7 @@ By using `MapHealthChecks` instead of `UseHealthChecks`, you can use endpoint aw : * Terminates the pipeline when a request matches the health check endpoint. [Short-circuiting](xref:fundamentals/middleware/index) is often desirable because it avoids unnecessary work, such as logging and other middleware. -* Is primarily used for configuring the health check middleware in the pipeline. +* Is primarily used for configuring the health checks middleware in the pipeline. * Can match any path on a port with a `null` or empty `PathString`. Allows performing a health check on any request made to the specified port. * [Source code](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HealthChecks/src/Builder/HealthCheckApplicationBuilderExtensions.cs) diff --git a/aspnetcore/host-and-deploy/health-checks/includes/health-checks5.md b/aspnetcore/host-and-deploy/health-checks/includes/health-checks5.md index 7371061ab06f..aa59738c6018 100644 --- a/aspnetcore/host-and-deploy/health-checks/includes/health-checks5.md +++ b/aspnetcore/host-and-deploy/health-checks/includes/health-checks5.md @@ -1,6 +1,6 @@ :::moniker range="= aspnetcore-5.0" -ASP.NET Core offers Health Checks Middleware and libraries for reporting the health of app infrastructure components. +ASP.NET Core offers health checks middleware and libraries for reporting the health of app infrastructure components. Health checks are exposed by an app as HTTP endpoints. Health check endpoints can be configured for various real-time monitoring scenarios: @@ -34,7 +34,7 @@ Another health check scenario demonstrates how to filter health checks to a mana For many apps, a basic health probe configuration that reports the app's availability to process requests (*liveness*) is sufficient to discover the status of the app. -The basic configuration registers health check services and calls the Health Checks Middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes the status () as a plaintext response back to the client, indicating either a , , or status. +The basic configuration registers health check services and calls the health checks middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes the status () as a plaintext response back to the client, indicating either a , , or status. Register health check services with in `Startup.ConfigureServices`. Create a health check endpoint by calling `MapHealthChecks` in `Startup.Configure`. @@ -193,7 +193,7 @@ For more information, see the [Filter by port](#filter-by-port) section. ### Require authorization -Call `RequireAuthorization` to run Authorization Middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used. +Call `RequireAuthorization` to run authorization middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used. ```csharp app.UseEndpoints(endpoints => @@ -204,7 +204,7 @@ app.UseEndpoints(endpoints => ### Enable Cross-Origin Requests (CORS) -Although running health checks manually from a browser isn't a common use scenario, CORS Middleware can be enabled by calling `RequireCors` on health checks endpoints. A `RequireCors` overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. If a policy isn't provided, the default CORS policy is used. For more information, see . +Although running health checks manually from a browser isn't a common use scenario, CORS middleware can be enabled by calling `RequireCors` on health checks endpoints. A `RequireCors` overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. If a policy isn't provided, the default CORS policy is used. For more information, see . ## Health check options @@ -217,7 +217,7 @@ Although running health checks manually from a browser isn't a common use scenar ### Filter health checks -By default, Health Checks Middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. In the following example, the `Bar` health check is filtered out by its tag (`bar_tag`) in the function's conditional statement, where `true` is only returned if the health check's property matches `foo_tag` or `baz_tag`: +By default, health checks middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. In the following example, the `Bar` health check is filtered out by its tag (`bar_tag`) in the function's conditional statement, where `true` is only returned if the health check's property matches `foo_tag` or `baz_tag`: In `Startup.ConfigureServices`: @@ -267,7 +267,7 @@ app.UseEndpoints(endpoints => ### Suppress cache headers - controls whether the Health Checks Middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response. + controls whether the health checks middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response. In `Startup.Configure`: @@ -752,7 +752,7 @@ In the sample app's `LivenessProbeStartup` example, the `StartupHostedService` r Use to conditionally branch the request pipeline for health check endpoints. -In the following example, `MapWhen` branches the request pipeline to activate Health Checks Middleware if a GET request is received for the `api/HealthCheck` endpoint: +In the following example, `MapWhen` branches the request pipeline to activate health checks middleware if a GET request is received for the `api/HealthCheck` endpoint: ```csharp app.MapWhen( @@ -772,7 +772,7 @@ For more information, see ) as a plaintext response back to the client, indicating either a , , or status. +The basic configuration registers health check services and calls the health checks middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes the status () as a plaintext response back to the client, indicating either a , , or status. Register health check services with in `Startup.ConfigureServices`. Create a health check endpoint by calling `MapHealthChecks` in `Startup.Configure`. @@ -962,7 +962,7 @@ For more information, see the [Filter by port](#filter-by-port) section. ### Require authorization -Call `RequireAuthorization` to run Authorization Middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used. +Call `RequireAuthorization` to run authorization middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used. ```csharp app.UseEndpoints(endpoints => @@ -973,7 +973,7 @@ app.UseEndpoints(endpoints => ### Enable Cross-Origin Requests (CORS) -Although running health checks manually from a browser isn't a common use scenario, CORS Middleware can be enabled by calling `RequireCors` on health checks endpoints. A `RequireCors` overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. If a policy isn't provided, the default CORS policy is used. For more information, see . +Although running health checks manually from a browser isn't a common use scenario, CORS middleware can be enabled by calling `RequireCors` on health checks endpoints. A `RequireCors` overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. If a policy isn't provided, the default CORS policy is used. For more information, see . ## Health check options @@ -986,7 +986,7 @@ Although running health checks manually from a browser isn't a common use scenar ### Filter health checks -By default, Health Checks Middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. In the following example, the `Bar` health check is filtered out by its tag (`bar_tag`) in the function's conditional statement, where `true` is only returned if the health check's property matches `foo_tag` or `baz_tag`: +By default, health checks middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. In the following example, the `Bar` health check is filtered out by its tag (`bar_tag`) in the function's conditional statement, where `true` is only returned if the health check's property matches `foo_tag` or `baz_tag`: In `Startup.ConfigureServices`: @@ -1036,7 +1036,7 @@ app.UseEndpoints(endpoints => ### Suppress cache headers - controls whether the Health Checks Middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response. + controls whether the health checks middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response. In `Startup.Configure`: @@ -1521,7 +1521,7 @@ In the sample app's `LivenessProbeStartup` example, the `StartupHostedService` r Use to conditionally branch the request pipeline for health check endpoints. -In the following example, `MapWhen` branches the request pipeline to activate Health Checks Middleware if a GET request is received for the `api/HealthCheck` endpoint: +In the following example, `MapWhen` branches the request pipeline to activate health checks middleware if a GET request is received for the `api/HealthCheck` endpoint: ```csharp app.MapWhen( diff --git a/aspnetcore/host-and-deploy/health-checks/includes/health-checks6-7.md b/aspnetcore/host-and-deploy/health-checks/includes/health-checks6-7.md index 80c6967f4ada..16812668468f 100644 --- a/aspnetcore/host-and-deploy/health-checks/includes/health-checks6-7.md +++ b/aspnetcore/host-and-deploy/health-checks/includes/health-checks6-7.md @@ -1,6 +1,6 @@ :::moniker range=">= aspnetcore-6.0 <= aspnetcore-7.0" -ASP.NET Core offers Health Checks Middleware and libraries for reporting the health of app infrastructure components. +ASP.NET Core offers health checks middleware and libraries for reporting the health of app infrastructure components. Health checks are exposed by an app as HTTP endpoints. Health check endpoints can be configured for various real-time monitoring scenarios: @@ -14,7 +14,7 @@ Health checks are typically used with an external monitoring service or containe For many apps, a basic health probe configuration that reports the app's availability to process requests (*liveness*) is sufficient to discover the status of the app. -The basic configuration registers health check services and calls the Health Checks Middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes as a plaintext response to the client. The `HealthStatus` is , , or . +The basic configuration registers health check services and calls the health checks middleware to respond at a URL endpoint with a health response. By default, no specific health checks are registered to test any particular dependency or subsystem. The app is considered healthy if it can respond at the health endpoint URL. The default response writer writes as a plaintext response to the client. The `HealthStatus` is , , or . Register health check services with in `Program.cs`. Create a health check endpoint by calling . @@ -94,13 +94,13 @@ For more information, see [Host matching in routes with RequireHost](xref:fundam ### Require authorization -Call to run Authorization Middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used: +Call to run authorization middleware on the health check request endpoint. A `RequireAuthorization` overload accepts one or more authorization policies. If a policy isn't provided, the default authorization policy is used: :::code language="csharp" source="~/host-and-deploy/health-checks/samples/6.x/HealthChecksSample/Snippets/Program.cs" id="snippet_MapHealthChecksRequireAuthorization"::: ### Enable Cross-Origin Requests (CORS) -Although running health checks manually from a browser isn't a common scenario, CORS Middleware can be enabled by calling [`RequireCors`](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/CORS/src/Infrastructure/CorsEndpointConventionBuilderExtensions.cs#L20-#L40) on the health checks endpoints. The [`RequireCors`](/dotnet/api/microsoft.aspnetcore.builder.corsendpointconventionbuilderextensions.requirecors) overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. For more information, see . +Although running health checks manually from a browser isn't a common scenario, CORS middleware can be enabled by calling [`RequireCors`](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/CORS/src/Infrastructure/CorsEndpointConventionBuilderExtensions.cs#L20-#L40) on the health checks endpoints. The [`RequireCors`](/dotnet/api/microsoft.aspnetcore.builder.corsendpointconventionbuilderextensions.requirecors) overload accepts a CORS policy builder delegate (`CorsPolicyBuilder`) or a policy name. For more information, see . ## Health check options @@ -113,7 +113,7 @@ Although running health checks manually from a browser isn't a common scenario, ### Filter health checks -By default, the Health Checks Middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. +By default, the health checks middleware runs all registered health checks. To run a subset of health checks, provide a function that returns a boolean to the option. The following example filters the health checks so that only those tagged with `sample` run: @@ -127,7 +127,7 @@ Use controls whether the Health Checks Middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response: + controls whether the health checks middleware adds HTTP headers to a probe response to prevent response caching. If the value is `false` (default), the middleware sets or overrides the `Cache-Control`, `Expires`, and `Pragma` headers to prevent response caching. If the value is `true`, the middleware doesn't modify the cache headers of the response: :::code language="csharp" source="~/host-and-deploy/health-checks/samples/6.x/HealthChecksSample/Snippets/Program.cs" id="snippet_MapHealthChecksAllowCachingResponses"::: @@ -301,7 +301,7 @@ The advantage of using `MapHealthChecks` over `UseHealthChecks` is the ability t : * Terminates the pipeline when a request matches the health check endpoint. [Short-circuiting](xref:fundamentals/middleware/index) is often desirable because it avoids unnecessary work, such as logging and other middleware. -* Is primarily used for configuring the health check middleware in the pipeline. +* Is primarily used for configuring the health checks middleware in the pipeline. * Can match any path on a port with a `null` or empty `PathString`. Allows performing a health check on any request made to the specified port. * [Source code](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HealthChecks/src/Builder/HealthCheckApplicationBuilderExtensions.cs) diff --git a/aspnetcore/host-and-deploy/health-checks/samples/3.x/HealthChecksSample/README.md b/aspnetcore/host-and-deploy/health-checks/samples/3.x/HealthChecksSample/README.md index 55b9cef03793..68cb4d8f0ef2 100644 --- a/aspnetcore/host-and-deploy/health-checks/samples/3.x/HealthChecksSample/README.md +++ b/aspnetcore/host-and-deploy/health-checks/samples/3.x/HealthChecksSample/README.md @@ -1,6 +1,6 @@ # ASP.NET Core Health Check Sample -This sample illustrates the use of Health Check Middleware and services. This sample demonstrates the scenario described in the [Health checks in ASP.NET Core](https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks) topic. +This sample illustrates the use of health checks middleware and services. This sample demonstrates the scenario described in the [Health checks in ASP.NET Core](https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks) topic. To run the sample app for a scenario described in the topic, use the [dotnet run](https://learn.microsoft.com/dotnet/core/tools/dotnet-run) command from the project's folder in a command shell. Pass a switch for the scenario that you're exploring. The app defaults to the `basic` configuration when a switch isn't provided to `dotnet run`. diff --git a/aspnetcore/host-and-deploy/health-checks/samples/5.x/HealthChecksSample/README.md b/aspnetcore/host-and-deploy/health-checks/samples/5.x/HealthChecksSample/README.md index 55b9cef03793..68cb4d8f0ef2 100644 --- a/aspnetcore/host-and-deploy/health-checks/samples/5.x/HealthChecksSample/README.md +++ b/aspnetcore/host-and-deploy/health-checks/samples/5.x/HealthChecksSample/README.md @@ -1,6 +1,6 @@ # ASP.NET Core Health Check Sample -This sample illustrates the use of Health Check Middleware and services. This sample demonstrates the scenario described in the [Health checks in ASP.NET Core](https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks) topic. +This sample illustrates the use of health checks middleware and services. This sample demonstrates the scenario described in the [Health checks in ASP.NET Core](https://learn.microsoft.com/aspnet/core/host-and-deploy/health-checks) topic. To run the sample app for a scenario described in the topic, use the [dotnet run](https://learn.microsoft.com/dotnet/core/tools/dotnet-run) command from the project's folder in a command shell. Pass a switch for the scenario that you're exploring. The app defaults to the `basic` configuration when a switch isn't provided to `dotnet run`. diff --git a/aspnetcore/host-and-deploy/iis/advanced.md b/aspnetcore/host-and-deploy/iis/advanced.md index 83996b4ed479..69074c92106e 100644 --- a/aspnetcore/host-and-deploy/iis/advanced.md +++ b/aspnetcore/host-and-deploy/iis/advanced.md @@ -79,7 +79,7 @@ The following example sets the delay to 5 seconds: The proxy created between the ASP.NET Core Module and Kestrel uses the HTTP protocol. There's no risk of eavesdropping the traffic between the module and Kestrel from a location off of the server. -A pairing token is used to guarantee that the requests received by Kestrel were proxied by IIS and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS Middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS Middleware. +A pairing token is used to guarantee that the requests received by Kestrel were proxied by IIS and didn't come from some other source. The pairing token is created and set into an environment variable (`ASPNETCORE_TOKEN`) by the module. The pairing token is also set into a header (`MS-ASPNETCORE-TOKEN`) on every proxied request. IIS middleware checks each request it receives to confirm that the pairing token header value matches the environment variable value. If the token values are mismatched, the request is logged and rejected. The pairing token environment variable and the traffic between the module and Kestrel aren't accessible from a location off of the server. Without knowing the pairing token value, a cyberattacker can't submit requests that bypass the check in the IIS middleware. ## ASP.NET Core Module with an IIS Shared Configuration @@ -196,12 +196,12 @@ Enable the **IIS Management Console** and **World Wide Web Services**. An ASP.NET Core app can be hosted as an [IIS sub-application (sub-app)](/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis#applications). The sub-app's path becomes part of the root app's URL. -Static asset links within the sub-app should use tilde-slash (`~/`) notation in MVC and Razor Pages. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's Static File Middleware doesn't process the static file request. The sub-app's Static File Middleware processes the request. +Static asset links within the sub-app should use tilde-slash (`~/`) notation in MVC and Razor Pages. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's static file middleware doesn't process the static file request. The sub-app's static file middleware processes the request. > [!NOTE] > Razor components (`.razor`) shouldn't use tilde-slash notation. For more information, see . -If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's Static File Middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. +If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's static file middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. To host an ASP.NET Core app as a sub-app under another ASP.NET Core app: diff --git a/aspnetcore/host-and-deploy/iis/development-time-iis-support.md b/aspnetcore/host-and-deploy/iis/development-time-iis-support.md index 54ff070dabcc..64967f3f0eda 100644 --- a/aspnetcore/host-and-deploy/iis/development-time-iis-support.md +++ b/aspnetcore/host-and-deploy/iis/development-time-iis-support.md @@ -61,11 +61,11 @@ IIS must have a website configured with the following: ### HTTPS redirection -For a new project that requires HTTPS, select the checkbox to **Configure for HTTPS** in the **Create a new ASP.NET Core Web Application** window. Selecting the checkbox adds [HTTPS Redirection and HSTS Middleware](xref:security/enforcing-ssl) to the app when it's created. +For a new project that requires HTTPS, select the checkbox to **Configure for HTTPS** in the **Create a new ASP.NET Core Web Application** window. Selecting the checkbox adds [HTTPS Redirection and HSTS middleware](xref:security/enforcing-ssl) to the app when it's created. -For an existing project that requires HTTPS, use HTTPS Redirection and HSTS Middleware in `Startup.Configure`. For more information, see . +For an existing project that requires HTTPS, use HTTPS Redirection and HSTS middleware in `Startup.Configure`. For more information, see . -For a project that uses HTTP, [HTTPS Redirection and HSTS Middleware](xref:security/enforcing-ssl) aren't added to the app. No app configuration is required. +For a project that uses HTTP, [HTTPS Redirection and HSTS middleware](xref:security/enforcing-ssl) aren't added to the app. No app configuration is required. ### IIS launch profile @@ -176,11 +176,11 @@ IIS must have a website configured with the following: ### HTTPS redirection -For a new project that requires HTTPS, select the checkbox to **Configure for HTTPS** in the **Create a new ASP.NET Core Web Application** window. Selecting the checkbox adds [HTTPS Redirection and HSTS Middleware](xref:security/enforcing-ssl) to the app when it's created. +For a new project that requires HTTPS, select the checkbox to **Configure for HTTPS** in the **Create a new ASP.NET Core Web Application** window. Selecting the checkbox adds [HTTPS Redirection and HSTS middleware](xref:security/enforcing-ssl) to the app when it's created. -For an existing project that requires HTTPS, use HTTPS Redirection and HSTS Middleware in `Startup.Configure`. For more information, see . +For an existing project that requires HTTPS, use HTTPS Redirection and HSTS middleware in `Startup.Configure`. For more information, see . -For a project that uses HTTP, [HTTPS Redirection and HSTS Middleware](xref:security/enforcing-ssl) aren't added to the app. No app configuration is required. +For a project that uses HTTP, [HTTPS Redirection and HSTS middleware](xref:security/enforcing-ssl) aren't added to the app. No app configuration is required. ### IIS launch profile diff --git a/aspnetcore/host-and-deploy/iis/index.md b/aspnetcore/host-and-deploy/iis/index.md index f5cf5089ec1e..5e0403c36c5c 100644 --- a/aspnetcore/host-and-deploy/iis/index.md +++ b/aspnetcore/host-and-deploy/iis/index.md @@ -212,18 +212,18 @@ services.Configure(options => | Option | Default | Setting | | ------------------------------ | :-----: | ------- | -| `AutomaticAuthentication` | `true` | If `true`, [IIS Integration Middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) article. | +| `AutomaticAuthentication` | `true` | If `true`, [IIS integration middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) article. | | `AuthenticationDisplayName` | `null` | Sets the display name shown to users on login pages. | | `ForwardClientCertificate` | `true` | If `true` and the `MS-ASPNETCORE-CLIENTCERT` request header is present, the `HttpContext.Connection.ClientCertificate` is populated. | ### Proxy server and load balancer scenarios -The [IIS Integration Middleware](#enable-the-iisintegration-components) and the ASP.NET Core Module are configured to forward the: +The [IIS integration middleware](#enable-the-iisintegration-components) and the ASP.NET Core Module are configured to forward the: * Scheme (HTTP/HTTPS). * Remote IP address where the request originated. -The [IIS Integration Middleware](#enable-the-iisintegration-components) configures Forwarded Headers Middleware. +The [IIS integration middleware](#enable-the-iisintegration-components) configures forwarded headers middleware. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). @@ -502,9 +502,9 @@ To configure data protection under IIS to persist the key ring, use **one** of t An ASP.NET Core app can be hosted as an [IIS sub-application (sub-app)](/iis/get-started/planning-your-iis-architecture/understanding-sites-applications-and-virtual-directories-on-iis#applications). The sub-app's path becomes part of the root app's URL. -Static asset links within the sub-app should use tilde-slash (`~/`) notation. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's Static File Middleware doesn't process the static file request. The sub-app's Static File Middleware processes the request. +Static asset links within the sub-app should use tilde-slash (`~/`) notation. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's static file middleware doesn't process the static file request. The sub-app's static file middleware processes the request. -If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's Static File Middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. +If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's static file middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. To host an ASP.NET Core app as a sub-app under another ASP.NET Core app: @@ -748,7 +748,7 @@ The following diagram illustrates the relationship between IIS, the ASP.NET Core Requests arrive from the web to the kernel-mode HTTP.sys driver. The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443. -The module specifies the port via an environment variable at startup, and the [IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. +The module specifies the port via an environment variable at startup, and the [IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) configures the server to listen on `http://localhost:{port}`. Additional checks are performed, and requests that don't originate from the module are rejected. The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS. After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. The middleware pipeline handles the request and passes it on as an `HttpContext` instance to the app's logic. Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request. @@ -798,13 +798,13 @@ services.Configure(options => | Option | Default | Setting | | ------------------------------ | :-----: | ------- | -| `AutomaticAuthentication` | `true` | If `true`, [IIS Integration Middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) article. | +| `AutomaticAuthentication` | `true` | If `true`, [IIS integration middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) article. | | `AuthenticationDisplayName` | `null` | Sets the display name shown to users on login pages. | | `ForwardClientCertificate` | `true` | If `true` and the `MS-ASPNETCORE-CLIENTCERT` request header is present, the `HttpContext.Connection.ClientCertificate` is populated. | ### Proxy server and load balancer scenarios -The [IIS Integration Middleware](#enable-the-iisintegration-components), which configures Forwarded Headers Middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). +The [IIS integration middleware](#enable-the-iisintegration-components), which configures forwarded headers middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). ### web.config file @@ -1103,9 +1103,9 @@ When hosting a non-ASP.NET Core sub-app underneath an ASP.NET Core app, explicit ``` -Static asset links within the sub-app should use tilde-slash (`~/`) notation. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's Static File Middleware doesn't process the static file request. The sub-app's Static File Middleware processes the request. +Static asset links within the sub-app should use tilde-slash (`~/`) notation. Tilde-slash notation triggers a [Tag Helper](xref:mvc/views/tag-helpers/intro) to prepend the sub-app's pathbase to the rendered relative link. For a sub-app at `/subapp_path`, an image linked with `src="~/image.png"` is rendered as `src="/subapp_path/image.png"`. The root app's static file middleware doesn't process the static file request. The sub-app's static file middleware processes the request. -If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's Static File Middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. +If a static asset's `src` attribute is set to an absolute path (for example, `src="/image.png"`), the link is rendered without the sub-app's pathbase. The root app's static file middleware attempts to serve the asset from the root app's [web root](xref:fundamentals/index#web-root), which results in a *404 - Not Found* response unless the static asset is available from the root app. To host an ASP.NET Core app as a sub-app under another ASP.NET Core app: diff --git a/aspnetcore/host-and-deploy/iis/modules.md b/aspnetcore/host-and-deploy/iis/modules.md index 7fc5a261f4e1..82fa899e9da6 100644 --- a/aspnetcore/host-and-deploy/iis/modules.md +++ b/aspnetcore/host-and-deploy/iis/modules.md @@ -25,29 +25,29 @@ The table indicates native IIS modules that are functional with ASP.NET Core app | **Client Certification Mapping Authentication**
`CertificateMappingAuthenticationModule` | Yes | | | **CGI**
`CgiModule` | No | | | **Configuration Validation**
`ConfigurationValidationModule` | Yes | | -| **HTTP Errors**
`CustomErrorModule` | No | [Status Code Pages Middleware](xref:fundamentals/error-handling#usestatuscodepages) | +| **HTTP Errors**
`CustomErrorModule` | No | [Status code pages middleware](xref:fundamentals/error-handling#usestatuscodepages) | | **Custom Logging**
`CustomLoggingModule` | Yes | | -| **Default Document**
`DefaultDocumentModule` | No | [Default Files Middleware](xref:fundamentals/static-files#serve-a-default-document) | +| **Default Document**
`DefaultDocumentModule` | No | [Default files middleware](xref:fundamentals/static-files#serve-a-default-document) | | **Digest Authentication**
`DigestAuthenticationModule` | Yes | | -| **Directory Browsing**
`DirectoryListingModule` | No | [Directory Browsing Middleware](xref:fundamentals/static-files#enable-directory-browsing) | -| **Dynamic Compression**
`DynamicCompressionModule` | Yes | [Response Compression Middleware](xref:performance/response-compression) | +| **Directory Browsing**
`DirectoryListingModule` | No | [Directory-browsing middleware](xref:fundamentals/static-files#enable-directory-browsing) | +| **Dynamic Compression**
`DynamicCompressionModule` | Yes | [Response compression middleware](xref:performance/response-compression) | | **Failed Requests Tracing**
`FailedRequestsTracingModule` | Yes | [ASP.NET Core Logging](xref:fundamentals/logging/index#dotnet-trace-tooling) | -| **File Caching**
`FileCacheModule` | No | [Response Caching Middleware](xref:performance/caching/middleware) | -| **HTTP Caching**
`HttpCacheModule` | No | [Response Caching Middleware](xref:performance/caching/middleware) | +| **File Caching**
`FileCacheModule` | No | [Response caching middleware](xref:performance/caching/middleware) | +| **HTTP Caching**
`HttpCacheModule` | No | [Response caching middleware](xref:performance/caching/middleware) | | **HTTP Logging**
`HttpLoggingModule` | Yes | [ASP.NET Core Logging](xref:fundamentals/logging/index) | -| **HTTP Redirection**
`HttpRedirectionModule` | Yes | [URL Rewriting Middleware](xref:fundamentals/url-rewriting) | +| **HTTP Redirection**
`HttpRedirectionModule` | Yes | [URL rewriting middleware](xref:fundamentals/url-rewriting) | | **HTTP Tracing**
`TracingModule` | Yes | | | **IIS Client Certificate Mapping Authentication**
`IISCertificateMappingAuthenticationModule` | Yes | | | **IP and Domain Restrictions**
`IpRestrictionModule` | Yes | | | **ISAPI Filters**
`IsapiFilterModule` | Yes | [Middleware](xref:fundamentals/middleware/index) | | **ISAPI**
`IsapiModule` | Yes | [Middleware](xref:fundamentals/middleware/index) | | **Protocol Support**
`ProtocolSupportModule` | Yes | | -| **Request Filtering**
`RequestFilteringModule` | Yes | [URL Rewriting Middleware `IRule`](xref:fundamentals/url-rewriting#irule-based-rule) | +| **Request Filtering**
`RequestFilteringModule` | Yes | [URL rewriting middleware `IRule`](xref:fundamentals/url-rewriting#irule-based-rule) | | **Request Monitor**
`RequestMonitorModule` | Yes | | -| **URL Rewriting**†
`RewriteModule` | Yes | [URL Rewriting Middleware](xref:fundamentals/url-rewriting) | +| **URL Rewriting**†
`RewriteModule` | Yes | [URL rewriting middleware](xref:fundamentals/url-rewriting) | | **Server-Side Includes**
`ServerSideIncludeModule` | No | | -| **Static Compression**
`StaticCompressionModule` | No | [Response Compression Middleware](xref:performance/response-compression) | -| **Static Content**
`StaticFileModule` | No | [Static File Middleware](xref:fundamentals/static-files) | +| **Static Compression**
`StaticCompressionModule` | No | [Response compression middleware](xref:performance/response-compression) | +| **Static Content**
`StaticFileModule` | No | [Static file middleware](xref:fundamentals/static-files) | | **Token Caching**
`TokenCacheModule` | Yes | | | **URI Caching**
`UriCacheModule` | Yes | | | **URL Authorization**
`UrlAuthorizationModule` | Yes | [ASP.NET Core Identity](xref:security/authentication/identity) | @@ -65,14 +65,14 @@ Managed modules are *not* functional with hosted ASP.NET Core apps when the app | AnonymousIdentification | | | DefaultAuthentication | | | FileAuthorization | | -| FormsAuthentication | [Cookie Authentication Middleware](xref:security/authentication/cookie) | -| OutputCache | [Response Caching Middleware](xref:performance/caching/middleware) | +| FormsAuthentication | [Cookie authentication middleware](xref:security/authentication/cookie) | +| OutputCache | [Response caching middleware](xref:performance/caching/middleware) | | Profile | | | RoleManager | | | ScriptModule-4.0 | | -| Session | [Session Middleware](xref:fundamentals/app-state) | +| Session | [Session middleware](xref:fundamentals/app-state) | | UrlAuthorization | | -| UrlMappingsModule | [URL Rewriting Middleware](xref:fundamentals/url-rewriting) | +| UrlMappingsModule | [URL rewriting middleware](xref:fundamentals/url-rewriting) | | UrlRoutingModule-4.0 | [ASP.NET Core Identity](xref:security/authentication/identity) | | WindowsAuthentication | | diff --git a/aspnetcore/host-and-deploy/iis/out-of-process-hosting.md b/aspnetcore/host-and-deploy/iis/out-of-process-hosting.md index 8afe5a04cd0d..ada379cc91ed 100644 --- a/aspnetcore/host-and-deploy/iis/out-of-process-hosting.md +++ b/aspnetcore/host-and-deploy/iis/out-of-process-hosting.md @@ -59,19 +59,19 @@ services.Configure(options => | Option | Default | Setting | | ------------------------------ | :-----: | ------- | -| `AutomaticAuthentication` | `true` | If `true`, [IIS Integration Middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) topic. | +| `AutomaticAuthentication` | `true` | If `true`, [IIS integration middleware](#enable-the-iisintegration-components) sets the `HttpContext.User` authenticated by [Windows Authentication](xref:security/authentication/windowsauth). If `false`, the middleware only provides an identity for `HttpContext.User` and responds to challenges when explicitly requested by the `AuthenticationScheme`. Windows Authentication must be enabled in IIS for `AutomaticAuthentication` to function. For more information, see the [Windows Authentication](xref:security/authentication/windowsauth) topic. | | `AuthenticationDisplayName` | `null` | Sets the display name shown to users on login pages. | | `ForwardClientCertificate` | `true` | If `true` and the `MS-ASPNETCORE-CLIENTCERT` request header is present, the `HttpContext.Connection.ClientCertificate` is populated. | ### Proxy server and load balancer scenarios -The [IIS Integration Middleware](#enable-the-iisintegration-components) and the ASP.NET Core Module are configured to forward the: +The [IIS integration middleware](#enable-the-iisintegration-components) and the ASP.NET Core Module are configured to forward the: * Scheme (HTTP/HTTPS). * Remote IP address where the request originated. -The [IIS Integration Middleware](#enable-the-iisintegration-components) configures Forwarded Headers Middleware. +The [IIS integration middleware](#enable-the-iisintegration-components) configures forwarded headers middleware. Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. For more information, see [Configure ASP.NET Core to work with proxy servers and load balancers](xref:host-and-deploy/proxy-load-balancer). diff --git a/aspnetcore/host-and-deploy/index.md b/aspnetcore/host-and-deploy/index.md index c587188c65da..a78823765954 100644 --- a/aspnetcore/host-and-deploy/index.md +++ b/aspnetcore/host-and-deploy/index.md @@ -107,7 +107,7 @@ For more information, see . ## Perform health checks -Use Health Check Middleware to perform health checks on an app and its dependencies. For more information, see . +Use health checks middleware to perform health checks on an app and its dependencies. For more information, see . ## Additional resources diff --git a/aspnetcore/host-and-deploy/linux-nginx.md b/aspnetcore/host-and-deploy/linux-nginx.md index 1150942a84fb..5cd49c5b4a80 100644 --- a/aspnetcore/host-and-deploy/linux-nginx.md +++ b/aspnetcore/host-and-deploy/linux-nginx.md @@ -61,7 +61,7 @@ If the app is run locally in the [`Development` environment](xref:fundamentals/e * Configure the app to run at the insecure endpoint: - * Deactivate HTTPS Redirection Middleware in the `Development` environment (`Program.cs`): + * Deactivate HTTPS redirection middleware in the `Development` environment (`Program.cs`): ```csharp if (!app.Environment.IsDevelopment()) @@ -104,9 +104,9 @@ Kestrel is great for serving dynamic content from ASP.NET Core. However, the web For the purposes of this guide, a single instance of Nginx is used. It runs on the same server, alongside the HTTP server. Based on requirements, a different setup may be chosen. -Because requests are forwarded by reverse proxy, use the [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package, which is automatically included in ASP.NET Core apps via the [shared framework's `Microsoft.AspNetCore.App` metapackage](xref:fundamentals/metapackage-app). The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. +Because requests are forwarded by reverse proxy, use the [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package, which is automatically included in ASP.NET Core apps via the [shared framework's `Microsoft.AspNetCore.App` metapackage](xref:fundamentals/metapackage-app). The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. -Forwarded Headers Middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run Forwarded Headers Middleware after Diagnostics and Error Handling Middleware, see [Forwarded Headers Middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). +Forwarded headers middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run forwarded headers middleware after diagnostics and error handling middleware, see [forwarded headers middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). Invoke the method before calling other middleware. Configure the middleware to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers: @@ -114,7 +114,7 @@ Invoke the are specified to the middleware, the default headers to forward are `None`. -Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address `10.0.0.100` to the Forwarded Headers Middleware `KnownProxies`: +Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address `10.0.0.100` to the forwarded headers middleware `KnownProxies`: :::code language="csharp" source="~/host-and-deploy/linux-nginx/sample7/Program.cs" id="snippet_all"::: @@ -465,12 +465,12 @@ Configure the app to use a certificate in development for the `dotnet run` comma * Harden the security by employing some of the practices depicted in the following */etc/nginx/nginx.conf* file. -* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS Redirection Middleware. For more information, see . +* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS redirection middleware. For more information, see . > [!NOTE] - > For development environments where the server configuration handles secure redirection instead of HTTPS Redirection Middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. + > For development environments where the server configuration handles secure redirection instead of HTTPS redirection middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. -* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . +* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . * If HTTPS will be disabled in the future, use one of the following approaches: diff --git a/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md b/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md index 94cdecc2ab1e..4e1fcc829d2d 100644 --- a/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md +++ b/aspnetcore/host-and-deploy/linux-nginx/includes/linux-nginx5.md @@ -34,7 +34,7 @@ If the app is run locally in the [`Development` environment](xref:fundamentals/e * Configure the app to run at the insecure endpoint: - * Deactivate HTTPS Redirection Middleware in the `Development` environment (`Program.cs`): + * Deactivate HTTPS redirection middleware in the `Development` environment (`Program.cs`): ```csharp if (!app.Environment.IsDevelopment()) @@ -77,9 +77,9 @@ Kestrel is great for serving dynamic content from ASP.NET Core. However, the web For the purposes of this guide, a single instance of Nginx is used. It runs on the same server, alongside the HTTP server. Based on requirements, a different setup may be chosen. -Because requests are forwarded by reverse proxy, use the [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package. The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. +Because requests are forwarded by reverse proxy, use the [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package. The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. -Forwarded Headers Middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run Forwarded Headers Middleware after Diagnostics and Error Handling Middleware, see [Forwarded Headers Middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). +Forwarded headers middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run forwarded headers middleware after diagnostics and error handling middleware, see [forwarded headers middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). Invoke the method at the top of `Program.cs` before calling other middleware. Configure the middleware to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers: @@ -95,7 +95,7 @@ app.UseAuthentication(); If no are specified to the middleware, the default headers to forward are `None`. -Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the Internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address 10.0.0.100 to the Forwarded Headers Middleware `KnownProxies` in `Program.cs`: +Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the Internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address 10.0.0.100 to the forwarded headers middleware `KnownProxies` in `Program.cs`: ```csharp using System.Net; @@ -366,12 +366,12 @@ Configure the app to use a certificate in development for the `dotnet run` comma * Harden the security by employing some of the practices depicted in the following */etc/nginx/nginx.conf* file. -* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS Redirection Middleware. For more information, see . +* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS redirection middleware. For more information, see . > [!NOTE] - > For development environments where the server configuration handles secure redirection instead of HTTPS Redirection Middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. + > For development environments where the server configuration handles secure redirection instead of HTTPS redirection middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. -* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . +* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . * If HTTPS will be disabled in the future, use one of the following approaches: @@ -477,7 +477,7 @@ If the app is run locally in the [`Development` environment](xref:fundamentals/e * Configure the app to run at the insecure endpoint: - * Deactivate HTTPS Redirection Middleware in the `Development` environment (`Program.cs`): + * Deactivate HTTPS redirection middleware in the `Development` environment (`Program.cs`): ```csharp if (!app.Environment.IsDevelopment()) @@ -520,9 +520,9 @@ Kestrel is great for serving dynamic content from ASP.NET Core. However, the web For the purposes of this guide, a single instance of Nginx is used. It runs on the same server, alongside the HTTP server. Based on requirements, a different setup may be chosen. -Because requests are forwarded by reverse proxy, use the [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package. The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. +Because requests are forwarded by reverse proxy, use the [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) from the [`Microsoft.AspNetCore.HttpOverrides`](https://www.nuget.org/packages/Microsoft.AspNetCore.HttpOverrides) package. The middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header, so that redirect URIs and other security policies work correctly. -Forwarded Headers Middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run Forwarded Headers Middleware after Diagnostics and Error Handling Middleware, see [Forwarded Headers Middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). +Forwarded headers middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. To run forwarded headers middleware after diagnostics and error handling middleware, see [forwarded headers middleware order](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-order). Invoke the method at the top of the request processing pipeline before calling other middleware. Configure the middleware to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers: @@ -541,7 +541,7 @@ app.UseAuthentication(); If no are specified to the middleware, the default headers to forward are `None`. -Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the Internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address 10.0.0.100 to the Forwarded Headers Middleware `KnownProxies` in `Startup.ConfigureServices`: +Proxies running on loopback addresses (`127.0.0.0/8`, `[::1]`), including the standard localhost address (`127.0.0.1`), are trusted by default. If other trusted proxies or networks within the organization handle requests between the Internet and the web server, add them to the list of or with . The following example adds a trusted proxy server at IP address 10.0.0.100 to the forwarded headers middleware `KnownProxies` in `Startup.ConfigureServices`: ```csharp using System.Net; @@ -813,12 +813,12 @@ Configure the app to use a certificate in development for the `dotnet run` comma * Harden the security by employing some of the practices depicted in the following */etc/nginx/nginx.conf* file. -* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS Redirection Middleware. For more information, see . +* The following example doesn't configure the server to redirect insecure requests. We recommend using HTTPS redirection middleware. For more information, see . > [!NOTE] - > For development environments where the server configuration handles secure redirection instead of HTTPS Redirection Middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. + > For development environments where the server configuration handles secure redirection instead of HTTPS redirection middleware, we recommend using temporary redirects (302) rather than permanent redirects (301). Link caching can cause unstable behavior in development environments. -* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . +* Adding a `Strict-Transport-Security` (HSTS) header ensures all subsequent requests made by the client are over HTTPS. For guidance on setting the `Strict-Transport-Security` header, see . * If HTTPS will be disabled in the future, use one of the following approaches: diff --git a/aspnetcore/host-and-deploy/proxy-load-balancer.md b/aspnetcore/host-and-deploy/proxy-load-balancer.md index 93de2b7f0198..ae1de286dccc 100644 --- a/aspnetcore/host-and-deploy/proxy-load-balancer.md +++ b/aspnetcore/host-and-deploy/proxy-load-balancer.md @@ -36,39 +36,39 @@ By convention, proxies forward information in HTTP headers. | [`X-Forwarded-Host`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host) (XFH) | The original value of the Host header field. Usually, proxies don't modify the Host header. See [Microsoft Security Advisory CVE-2018-0787](https://github.com/aspnet/Announcements/issues/295) for information on an elevation-of-privileges vulnerability that affects systems where the proxy doesn't validate or restrict Host headers to known good values. | | `X-Forwarded-Prefix` | The original base path requested by the client. This header can be useful for applications to correctly generate URLs, redirects, or links back to the client. | -The [Forwarded Headers Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs), , reads these headers and fills in the associated fields on . +The [forwarded headers middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs), , reads these headers and fills in the associated fields on . The middleware updates: -* [`HttpContext.Connection.RemoteIpAddress`](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress): Set using the `X-Forwarded-For` header value. Additional settings influence how the middleware sets `RemoteIpAddress`. For details, see the [Forwarded Headers Middleware options](#forwarded-headers-middleware-options). The consumed values are removed from `X-Forwarded-For`, and the old value of [`HttpContext.Connection.RemoteIpAddress`](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress) is persisted in `X-Original-For`. Note: This process might be repeated several times if there are multiple values in `X-Forwarded-For/Proto/Host/Prefix`, resulting in several values moved to `X-Original-*`, including the original `RemoteIpAddress/Host/Scheme/PathBase`. +* [`HttpContext.Connection.RemoteIpAddress`](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress): Set using the `X-Forwarded-For` header value. Additional settings influence how the middleware sets `RemoteIpAddress`. For details, see the [forwarded headers middleware options](#forwarded-headers-middleware-options). The consumed values are removed from `X-Forwarded-For`, and the old value of [`HttpContext.Connection.RemoteIpAddress`](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress) is persisted in `X-Original-For`. Note: This process might be repeated several times if there are multiple values in `X-Forwarded-For/Proto/Host/Prefix`, resulting in several values moved to `X-Original-*`, including the original `RemoteIpAddress/Host/Scheme/PathBase`. * [`HttpContext.Request.Scheme`](xref:Microsoft.AspNetCore.Http.HttpRequest.Scheme): Set using the [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) header value. The consumed value is removed from `X-Forwarded-Proto`, and the old value of [`HttpContext.Request.Scheme`](xref:Microsoft.AspNetCore.Http.HttpRequest.Scheme) is persisted in `X-Original-Proto`. * [`HttpContext.Request.Host`](xref:Microsoft.AspNetCore.Http.HttpRequest.Host): Set using the `X-Forwarded-Host` header value. The consumed value is removed from `X-Forwarded-Host`, and the old value of [`HttpContext.Request.Host`](xref:Microsoft.AspNetCore.Http.HttpRequest.Host) is persisted in `X-Original-Host`. * [`HttpContext.Request.PathBase`](xref:Microsoft.AspNetCore.Http.HttpRequest.PathBase): Set using the `X-Forwarded-Prefix` header value. The consumed value is removed from `X-Forwarded-Prefix`, and the old value of [`HttpContext.Request.PathBase`](xref:Microsoft.AspNetCore.Http.HttpRequest.PathBase) is persisted in `X-Original-Prefix`. For more information on the preceding, see [this GitHub issue](https://github.com/dotnet/AspNetCore.Docs/issues/21615). -Forwarded Headers Middleware [default settings](#forwarded-headers-middleware-options) can be configured. For the default settings: +Forwarded headers middleware [default settings](#forwarded-headers-middleware-options) can be configured. For the default settings: * There's only ***one proxy*** between the app and the source of the requests. * Only loopback addresses are configured for known proxies and known networks. * The forwarded headers are named [`X-Forwarded-For`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-For), [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto), [`X-Forwarded-Host`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Host) and `X-Forwarded-Prefix`. * The `ForwardedHeaders` value is `ForwardedHeaders.None`. The desired forwarders must be set here to enable the middleware. -Not all network appliances add the `X-Forwarded-For` and `X-Forwarded-Proto` headers without additional configuration. Consult your appliance manufacturer's guidance if proxied requests don't contain these headers when they reach the app. If the appliance uses different header names than `X-Forwarded-For` and `X-Forwarded-Proto`, set the and options to match the header names used by the appliance. For more information, see [Forwarded Headers Middleware options](#forwarded-headers-middleware-options) and [Configuration for a proxy that uses different header names](#configuration-for-a-proxy-that-uses-different-header-names). +Not all network appliances add the `X-Forwarded-For` and `X-Forwarded-Proto` headers without additional configuration. Consult your appliance manufacturer's guidance if proxied requests don't contain these headers when they reach the app. If the appliance uses different header names than `X-Forwarded-For` and `X-Forwarded-Proto`, set the and options to match the header names used by the appliance. For more information, see [forwarded headers middleware options](#forwarded-headers-middleware-options) and [Configuration for a proxy that uses different header names](#configuration-for-a-proxy-that-uses-different-header-names). ## IIS/IIS Express and ASP.NET Core Module -[IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) enables Forwarded Headers Middleware by default when the app is hosted [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model) behind IIS and the . Forwarded Headers Middleware is activated to run first in the middleware pipeline with a restricted configuration specific to the ASP.NET Core Module. The restricted configuration is due to trust concerns with forwarded headers, for example, [IP spoofing](https://www.iplocation.net/ip-spoofing). The middleware is configured to forward the [`X-Forwarded-For`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-For) and [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) headers and is restricted to a single localhost proxy. If additional configuration is required, see the [Forwarded Headers Middleware options](#forwarded-headers-middleware-options). +[IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) enables forwarded headers middleware by default when the app is hosted [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model) behind IIS and the . Forwarded headers middleware is activated to run first in the middleware pipeline with a restricted configuration specific to the ASP.NET Core Module. The restricted configuration is due to trust concerns with forwarded headers, for example, [IP spoofing](https://www.iplocation.net/ip-spoofing). The middleware is configured to forward the [`X-Forwarded-For`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-For) and [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) headers and is restricted to a single localhost proxy. If additional configuration is required, see the [forwarded headers middleware options](#forwarded-headers-middleware-options). ## Other proxy server and load balancer scenarios -Outside of using [IIS Integration](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), [Forwarded Headers Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs) isn't enabled by default. Forwarded Headers Middleware must be enabled for an app to process forwarded headers with . After enabling the middleware if no are specified to the middleware, the default [ForwardedHeadersOptions.ForwardedHeaders](xref:Microsoft.AspNetCore.Builder.ForwardedHeadersOptions.ForwardedHeaders) are [ForwardedHeaders.None](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders). +Outside of using [IIS Integration](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), [forwarded headers middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs) isn't enabled by default. Forwarded headers middleware must be enabled for an app to process forwarded headers with . After enabling the middleware if no are specified to the middleware, the default [ForwardedHeadersOptions.ForwardedHeaders](xref:Microsoft.AspNetCore.Builder.ForwardedHeadersOptions.ForwardedHeaders) are [ForwardedHeaders.None](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders). Configure the middleware with to forward the [`X-Forwarded-For`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-For) and [`X-Forwarded-Proto`](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/X-Forwarded-Proto) headers. -### Forwarded Headers Middleware order +### Forwarded headers middleware order -[Forwarded Headers Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs) should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. Forwarded Headers Middleware can run after diagnostics and error handling, but it must be run before calling : +[Forwarded headers middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs) should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. Forwarded headers middleware can run after diagnostics and error handling, but it must be run before calling : [!code-csharp[](~/host-and-deploy/proxy-load-balancer/6.1samples/WebPS/Program.cs?name=snippet1&highlight=6-10,17,23)] @@ -87,9 +87,9 @@ To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see control the behavior of the [Forwarded Headers Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs). The following example changes the default values: + control the behavior of the [forwarded headers middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/ForwardedHeadersOptions.cs). The following example changes the default values: * Limits the number of entries in the forwarded headers to `2`. * Adds a known proxy address of `127.0.10.1`. @@ -104,7 +104,7 @@ To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see | Identifies which forwarders should be processed. See the [ForwardedHeaders Enum](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders) for the list of fields that apply. Typical values assigned to this property are `ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto`.

The default value is [ForwardedHeaders.None](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders). | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XForwardedHostHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XForwardedHostHeaderName). This option is used when the proxy/forwarder doesn't use the `X-Forwarded-Host` header but uses some other header to forward the information.

The default is `X-Forwarded-Host`. | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XForwardedProtoHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XForwardedProtoHeaderName). This option is used when the proxy/forwarder doesn't use the `X-Forwarded-Proto` header but uses some other header to forward the information.

The default is `X-Forwarded-Proto`. | -| | Limits the number of entries in the headers that are processed. Set to `null` to disable the limit, but this should only be done if `KnownProxies` or `KnownNetworks` are configured. Setting a non-`null` value is a precaution (but not a guarantee) to protect against misconfigured proxies and malicious requests arriving from side-channels on the network.

Forwarded Headers Middleware processes headers in reverse order from right to left. If the default value (`1`) is used, only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased.

The default is `1`. | +| | Limits the number of entries in the headers that are processed. Set to `null` to disable the limit, but this should only be done if `KnownProxies` or `KnownNetworks` are configured. Setting a non-`null` value is a precaution (but not a guarantee) to protect against misconfigured proxies and malicious requests arriving from side-channels on the network.

Forwarded headers middleware processes headers in reverse order from right to left. If the default value (`1`) is used, only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased.

The default is `1`. | | | Address ranges of known networks to accept forwarded headers from. Provide IP ranges using Classless Interdomain Routing (CIDR) notation.

If the server is using dual-mode sockets, IPv4 addresses are supplied in an IPv6 format (for example, `10.0.0.1` in IPv4 represented in IPv6 as `::ffff:10.0.0.1`). See [IPAddress.MapToIPv6](xref:System.Net.IPAddress.MapToIPv6*). Determine if this format is required by looking at the [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress*).

The default is an `IList`\<> containing a single entry for `new IPNetwork(IPAddress.Loopback, 8)`. | | | Addresses of known proxies to accept forwarded headers from. Use `KnownProxies` to specify exact IP address matches.

If the server is using dual-mode sockets, IPv4 addresses are supplied in an IPv6 format (for example, `10.0.0.1` in IPv4 represented in IPv6 as `::ffff:10.0.0.1`). See [IPAddress.MapToIPv6](xref:System.Net.IPAddress.MapToIPv6*). Determine if this format is required by looking at the [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress*).

The default is an `IList`\<> containing a single entry for `IPAddress.IPv6Loopback`. | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XOriginalForHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XOriginalForHeaderName).

The default is `X-Original-For`. | @@ -173,9 +173,9 @@ If the proxy doesn't use headers named `X-Forwarded-For` and `X-Forwarded-Proto` ## Forward the scheme for Linux and non-IIS reverse proxies -Apps that call and put a site into an infinite loop if deployed to an Azure Linux App Service, Azure Linux virtual machine (VM), or behind any other reverse proxy besides IIS. The reverse proxy terminates TLS, and Kestrel isn't made aware of the correct request scheme. OAuth and OIDC also fail in this configuration because they generate incorrect redirects. adds and configures Forwarded Headers Middleware when running behind IIS, but there's no matching automatic configuration for Linux (Apache or Nginx integration). +Apps that call and put a site into an infinite loop if deployed to an Azure Linux App Service, Azure Linux virtual machine (VM), or behind any other reverse proxy besides IIS. The reverse proxy terminates TLS, and Kestrel isn't made aware of the correct request scheme. OAuth and OIDC also fail in this configuration because they generate incorrect redirects. adds and configures forwarded headers middleware when running behind IIS, but there's no matching automatic configuration for Linux (Apache or Nginx integration). -To forward the scheme from the proxy in non-IIS scenarios, enable the Forwarded Headers Middleware by setting `ASPNETCORE_FORWARDEDHEADERS_ENABLED` to `true`. Warning: This flag uses settings designed for cloud environments and doesn't enable features such as the [`KnownProxies option`](#forwarded-headers-middleware-options) to restrict which IPs forwarders are accepted from. +To forward the scheme from the proxy in non-IIS scenarios, enable the forwarded headers middleware by setting `ASPNETCORE_FORWARDEDHEADERS_ENABLED` to `true`. Warning: This flag uses settings designed for cloud environments and doesn't enable features such as the [`KnownProxies option`](#forwarded-headers-middleware-options) to restrict which IPs forwarders are accepted from. ## Certificate forwarding @@ -183,7 +183,7 @@ To forward the scheme from the proxy in non-IIS scenarios, enable the Forwarded To configure Azure App Service for certificate forwarding, see [Configure TLS mutual authentication for Azure App Service](/azure/app-service/app-service-web-configure-tls-mutual-auth). The following guidance pertains to configuring the ASP.NET Core app. -* Configure [Certificate Forwarding Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/CertificateForwardingMiddleware.cs) to specify the header name that Azure uses. Add the following code to configure the header from which the middleware builds a certificate. +* Configure [certificate-forwarding middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/CertificateForwardingMiddleware.cs) to specify the header name that Azure uses. Add the following code to configure the header from which the middleware builds a certificate. * Call before the call to . [!code-csharp[](~/host-and-deploy/proxy-load-balancer/6.1samples/WebPS/Program.cs?name=snippet_az&highlight=4-5,9,17,21)] @@ -192,7 +192,7 @@ To configure Azure App Service for certificate forwarding, see [Configure TLS mu If a proxy is used that isn't IIS or Azure App Service's Application Request Routing (ARR), configure the proxy to forward the certificate that it received in an HTTP header. -* Configure [Certificate Forwarding Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/CertificateForwardingMiddleware.cs) to specify the header name. Add the following code to configure the header from which the middleware builds a certificate. +* Configure [certificate-forwarding middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/HttpOverrides/src/CertificateForwardingMiddleware.cs) to specify the header name. Add the following code to configure the header from which the middleware builds a certificate. * Call before the call to . [!code-csharp[](~/host-and-deploy/proxy-load-balancer/6.1samples/WebPS/Program.cs?name=snippet_owp&highlight=4-5,9,17,21)] @@ -218,7 +218,7 @@ END of COMMENTED OUT --> [!code-csharp[](~/host-and-deploy/proxy-load-balancer/6.1samples/WebPS/Program.cs?name=snippet_trb22&highlight=8-11,21-31)] -If there are multiple values in a given header, Forwarded Headers Middleware processes headers in reverse order from right to left. The default `ForwardLimit` is `1` (one), so only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased. +If there are multiple values in a given header, forwarded headers middleware processes headers in reverse order from right to left. The default `ForwardLimit` is `1` (one), so only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased. The request's original remote IP must match an entry in the or lists before forwarded headers are processed. This limits header spoofing by not accepting forwarders from untrusted proxies. When an unknown proxy is detected, logging indicates the address of the proxy: @@ -226,7 +226,7 @@ The request's original remote IP must match an entry in the ), reads these headers and fills in the associated fields on . +The forwarded headers middleware (), reads these headers and fills in the associated fields on . The middleware updates: -* [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress): Set using the `X-Forwarded-For` header value. Additional settings influence how the middleware sets `RemoteIpAddress`. For details, see the [Forwarded Headers Middleware options](#forwarded-headers-middleware-options). The consumed values are removed from `X-Forwarded-For`, and the old values are persisted in `X-Original-For`. The same pattern is applied to the other headers, `Host` and `Proto`. +* [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress): Set using the `X-Forwarded-For` header value. Additional settings influence how the middleware sets `RemoteIpAddress`. For details, see the [forwarded headers middleware options](#forwarded-headers-middleware-options). The consumed values are removed from `X-Forwarded-For`, and the old values are persisted in `X-Original-For`. The same pattern is applied to the other headers, `Host` and `Proto`. * [HttpContext.Request.Scheme](xref:Microsoft.AspNetCore.Http.HttpRequest.Scheme): Set using the `X-Forwarded-Proto` header value. * [HttpContext.Request.Host](xref:Microsoft.AspNetCore.Http.HttpRequest.Host): Set using the `X-Forwarded-Host` header value. For more information on the preceding, see [this GitHub issue](https://github.com/dotnet/AspNetCore.Docs/issues/21615). -Forwarded Headers Middleware [default settings](#forwarded-headers-middleware-options) can be configured. For the default settings: +Forwarded headers middleware [default settings](#forwarded-headers-middleware-options) can be configured. For the default settings: * There's only *one proxy* between the app and the source of the requests. * Only loopback addresses are configured for known proxies and known networks. * The forwarded headers are named `X-Forwarded-For` and `X-Forwarded-Proto`. * The `ForwardedHeaders` value is `ForwardedHeaders.None`, the desired forwarders must be set here to enable the middleware. -Not all network appliances add the `X-Forwarded-For` and `X-Forwarded-Proto` headers without additional configuration. Consult your appliance manufacturer's guidance if proxied requests don't contain these headers when they reach the app. If the appliance uses different header names than `X-Forwarded-For` and `X-Forwarded-Proto`, set the and options to match the header names used by the appliance. For more information, see [Forwarded Headers Middleware options](#forwarded-headers-middleware-options) and [Configuration for a proxy that uses different header names](#configuration-for-a-proxy-that-uses-different-header-names). +Not all network appliances add the `X-Forwarded-For` and `X-Forwarded-Proto` headers without additional configuration. Consult your appliance manufacturer's guidance if proxied requests don't contain these headers when they reach the app. If the appliance uses different header names than `X-Forwarded-For` and `X-Forwarded-Proto`, set the and options to match the header names used by the appliance. For more information, see [Forwarded headers middleware options](#forwarded-headers-middleware-options) and [Configuration for a proxy that uses different header names](#configuration-for-a-proxy-that-uses-different-header-names). ## IIS/IIS Express and ASP.NET Core Module -[IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) enables Forwarded Headers Middleware by default when the app is hosted [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model) behind IIS and the ASP.NET Core Module. Forwarded Headers Middleware is activated to run first in the middleware pipeline with a restricted configuration specific to the ASP.NET Core Module due to trust concerns with forwarded headers (for example, [IP spoofing](https://www.iplocation.net/ip-spoofing)). The middleware is configured to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers and is restricted to a single localhost proxy. If additional configuration is required, see the [Forwarded Headers Middleware options](#forwarded-headers-middleware-options). +[IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) enables forwarded headers middleware by default when the app is hosted [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model) behind IIS and the ASP.NET Core Module. Forwarded headers middleware is activated to run first in the middleware pipeline with a restricted configuration specific to the ASP.NET Core Module due to trust concerns with forwarded headers (for example, [IP spoofing](https://www.iplocation.net/ip-spoofing)). The middleware is configured to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers and is restricted to a single localhost proxy. If additional configuration is required, see the [forwarded headers middleware options](#forwarded-headers-middleware-options). ## Other proxy server and load balancer scenarios -Outside of using [IIS Integration](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), Forwarded Headers Middleware isn't enabled by default. Forwarded Headers Middleware must be enabled for an app to process forwarded headers with . After enabling the middleware if no are specified to the middleware, the default [ForwardedHeadersOptions.ForwardedHeaders](xref:Microsoft.AspNetCore.Builder.ForwardedHeadersOptions.ForwardedHeaders) are [ForwardedHeaders.None](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders). +Outside of using [IIS Integration](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) when hosting [out-of-process](xref:host-and-deploy/iis/index#out-of-process-hosting-model), forwarded headers middleware isn't enabled by default. Forwarded headers middleware must be enabled for an app to process forwarded headers with . After enabling the middleware if no are specified to the middleware, the default [ForwardedHeadersOptions.ForwardedHeaders](xref:Microsoft.AspNetCore.Builder.ForwardedHeadersOptions.ForwardedHeaders) are [ForwardedHeaders.None](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeaders). Configure the middleware with to forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers in `Startup.ConfigureServices`. -### Forwarded Headers Middleware order +### Forwarded headers middleware order -Forwarded Headers Middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. Forwarded Headers Middleware can run after diagnostics and error handling, but it must be run before calling `UseHsts`: +Forwarded headers middleware should run before other middleware. This ordering ensures that the middleware relying on forwarded headers information can consume the header values for processing. Forwarded headers middleware can run after diagnostics and error handling, but it must be run before calling `UseHsts`: [!code-csharp[](~/host-and-deploy/proxy-load-balancer/3.1samples/Startup.cs?name=snippet&highlight=13-17,25,30)] @@ -316,9 +316,9 @@ To forward the `X-Forwarded-For` and `X-Forwarded-Proto` headers, see control the behavior of the Forwarded Headers Middleware. The following example changes the default values: + control the behavior of the forwarded headers middleware. The following example changes the default values: * Limit the number of entries in the forwarded headers to `2`. * Add a known proxy address of `127.0.10.1`. @@ -341,7 +341,7 @@ services.Configure(options => | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XForwardedHostHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XForwardedHostHeaderName). This option is used when the proxy/forwarder doesn't use the `X-Forwarded-Host` header but uses some other header to forward the information.

The default is `X-Forwarded-Host`. | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XForwardedProtoHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XForwardedProtoHeaderName). This option is used when the proxy/forwarder doesn't use the `X-Forwarded-Proto` header but uses some other header to forward the information.

The default is `X-Forwarded-Proto`. | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XForwardedPrefixHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XForwardedPrefixHeaderName). This option is used when the proxy/forwarder doesn't use the `X-Forwarded-Prefix` header but uses some other header to forward the information.

The default is `X-Forwarded-Prefix`. | -| | Limits the number of entries in the headers that are processed. Set to `null` to disable the limit, but this should only be done if `KnownProxies` or `KnownNetworks` are configured. Setting a non-`null` value is a precaution (but not a guarantee) to protect against misconfigured proxies and malicious requests arriving from side-channels on the network.

Forwarded Headers Middleware processes headers in reverse order from right to left. If the default value (`1`) is used, only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased.

The default is `1`. | +| | Limits the number of entries in the headers that are processed. Set to `null` to disable the limit, but this should only be done if `KnownProxies` or `KnownNetworks` are configured. Setting a non-`null` value is a precaution (but not a guarantee) to protect against misconfigured proxies and malicious requests arriving from side-channels on the network.

Forwarded headers middleware processes headers in reverse order from right to left. If the default value (`1`) is used, only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased.

The default is `1`. | | | Address ranges of known networks to accept forwarded headers from. Provide IP ranges using Classless Interdomain Routing (CIDR) notation.

If the server is using dual-mode sockets, IPv4 addresses are supplied in an IPv6 format (for example, `10.0.0.1` in IPv4 represented in IPv6 as `::ffff:10.0.0.1`). See [IPAddress.MapToIPv6](xref:System.Net.IPAddress.MapToIPv6*). Determine if this format is required by looking at the [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress*).

The default is an `IList`\<> containing a single entry for `new IPNetwork(IPAddress.Loopback, 8)`. | | | Addresses of known proxies to accept forwarded headers from. Use `KnownProxies` to specify exact IP address matches.

If the server is using dual-mode sockets, IPv4 addresses are supplied in an IPv6 format (for example, `10.0.0.1` in IPv4 represented in IPv6 as `::ffff:10.0.0.1`). See [IPAddress.MapToIPv6](xref:System.Net.IPAddress.MapToIPv6*). Determine if this format is required by looking at the [HttpContext.Connection.RemoteIpAddress](xref:Microsoft.AspNetCore.Http.ConnectionInfo.RemoteIpAddress*).

The default is an `IList`\<> containing a single entry for `IPAddress.IPv6Loopback`. | | | Use the header specified by this property instead of the one specified by [ForwardedHeadersDefaults.XOriginalForHeaderName](xref:Microsoft.AspNetCore.HttpOverrides.ForwardedHeadersDefaults.XOriginalForHeaderName).

The default is `X-Original-For`. | @@ -416,9 +416,9 @@ services.Configure(options => ## Forward the scheme for Linux and non-IIS reverse proxies -Apps that call and put a site into an infinite loop if deployed to an Azure Linux App Service, Azure Linux virtual machine (VM), or behind any other reverse proxy besides IIS. The reverse proxy terminates TLS, and Kestrel isn't made aware of the correct request scheme. OAuth and OIDC also fail in this configuration because they generate incorrect redirects. adds and configures Forwarded Headers Middleware when running behind IIS, but there's no matching automatic configuration for Linux (Apache or Nginx integration). +Apps that call and put a site into an infinite loop if deployed to an Azure Linux App Service, Azure Linux virtual machine (VM), or behind any other reverse proxy besides IIS. The reverse proxy terminates TLS, and Kestrel isn't made aware of the correct request scheme. OAuth and OIDC also fail in this configuration because they generate incorrect redirects. adds and configures forwarded headers middleware when running behind IIS, but there's no matching automatic configuration for Linux (Apache or Nginx integration). -To forward the scheme from the proxy in non-IIS scenarios, add and configure Forwarded Headers Middleware. In `Startup.ConfigureServices`, use the following code: +To forward the scheme from the proxy in non-IIS scenarios, add and configure forwarded headers middleware. In `Startup.ConfigureServices`, use the following code: ```csharp // using Microsoft.AspNetCore.HttpOverrides; @@ -452,7 +452,7 @@ In `Startup.Configure`, add the following code before the call to `app.UseAuthen app.UseCertificateForwarding(); ``` -Configure Certificate Forwarding Middleware to specify the header name that Azure uses. In `Startup.ConfigureServices`, add the following code to configure the header from which the middleware builds a certificate: +Configure certificate-forwarding middleware to specify the header name that Azure uses. In `Startup.ConfigureServices`, add the following code to configure the header from which the middleware builds a certificate: ```csharp services.AddCertificateForwarding(options => @@ -467,7 +467,7 @@ If a proxy is used that isn't IIS or Azure App Service's Application Request Rou app.UseCertificateForwarding(); ``` -Configure the Certificate Forwarding Middleware to specify the header name. In `Startup.ConfigureServices`, add the following code to configure the header from which the middleware builds a certificate: +Configure the certificate-forwarding middleware to specify the header name. In `Startup.ConfigureServices`, add the following code to configure the header from which the middleware builds a certificate: ```csharp services.AddCertificateForwarding(options => @@ -555,7 +555,7 @@ app.Use(async (context, next) => }); ``` -When processed, `X-Forwarded-{For|Proto|Host|Prefix}` values are moved to `X-Original-{For|Proto|Host|Prefix}`. If there are multiple values in a given header, Forwarded Headers Middleware processes headers in reverse order from right to left. The default `ForwardLimit` is `1` (one), so only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased. +When processed, `X-Forwarded-{For|Proto|Host|Prefix}` values are moved to `X-Original-{For|Proto|Host|Prefix}`. If there are multiple values in a given header, forwarded headers middleware processes headers in reverse order from right to left. The default `ForwardLimit` is `1` (one), so only the rightmost value from the headers is processed unless the value of `ForwardLimit` is increased. The request's original remote IP must match an entry in the `KnownProxies` or `KnownNetworks` lists before forwarded headers are processed. This limits header spoofing by not accepting forwarders from untrusted proxies. When an unknown proxy is detected, logging indicates the address of the proxy: @@ -563,7 +563,7 @@ The request's original remote IP must match an entry in the `KnownProxies` or `K September 20th 2018, 15:49:44.168 Unknown proxy: 10.0.0.100:54321 ``` -In the preceding example, 10.0.0.100 is a proxy server. If the server is a trusted proxy, add the server's IP address to `KnownProxies` (or add a trusted network to `KnownNetworks`) in `Startup.ConfigureServices`. For more information, see the [Forwarded Headers Middleware options](#forwarded-headers-middleware-options) section. +In the preceding example, 10.0.0.100 is a proxy server. If the server is a trusted proxy, add the server's IP address to `KnownProxies` (or add a trusted network to `KnownNetworks`) in `Startup.ConfigureServices`. For more information, see the [forwarded headers middleware options](#forwarded-headers-middleware-options) section. ```csharp services.Configure(options => diff --git a/aspnetcore/includes/scaffold-identity/hsts.md b/aspnetcore/includes/scaffold-identity/hsts.md index 359c0000fbbb..6dd6d3179fcf 100644 --- a/aspnetcore/includes/scaffold-identity/hsts.md +++ b/aspnetcore/includes/scaffold-identity/hsts.md @@ -1 +1 @@ -`UseHsts` is recommended but not required. For more information, see [HTTP Strict Transport Security Protocol](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts). +`UseHsts` is recommended but not required. For more information, see [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol). diff --git a/aspnetcore/migration/1x-to-2x/identity-2x.md b/aspnetcore/migration/1x-to-2x/identity-2x.md index b34a220c3b63..d159b7b02b29 100644 --- a/aspnetcore/migration/1x-to-2x/identity-2x.md +++ b/aspnetcore/migration/1x-to-2x/identity-2x.md @@ -20,7 +20,7 @@ In 2.0, the namespace became the new home f -## Authentication Middleware and services +## Authentication middleware and services In 1.x projects, authentication is configured via middleware. A middleware method is invoked for each authentication scheme you want to support. diff --git a/aspnetcore/migration/20-to-21.md b/aspnetcore/migration/20-to-21.md index a1ba0bc356e7..84ac00ad2c9b 100644 --- a/aspnetcore/migration/20-to-21.md +++ b/aspnetcore/migration/20-to-21.md @@ -114,7 +114,7 @@ The following code shows the changes to 2.1 template generated code. All changes The preceding code changes are detailed in: * [GDPR support in ASP.NET Core](xref:security/gdpr) for `CookiePolicyOptions` and `UseCookiePolicy`. -* [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) for `UseHsts`. +* [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) for `UseHsts`. * [Require HTTPS](xref:security/enforcing-ssl#require-https) for `UseHttpsRedirection`. * [SetCompatibilityVersion](xref:mvc/compatibility-version) for `SetCompatibilityVersion(CompatibilityVersion.Version_2_1)`. diff --git a/aspnetcore/migration/22-to-30.md b/aspnetcore/migration/22-to-30.md index c1bc3cde7fb4..c293054e6d01 100644 --- a/aspnetcore/migration/22-to-30.md +++ b/aspnetcore/migration/22-to-30.md @@ -361,11 +361,11 @@ public static void Main(string[] args) } ``` -### Connection Middleware replaces Connection Adapters +### Connection middleware replaces Connection Adapters -Connection Adapters (`Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter`) have been removed from Kestrel. Replace Connection Adapters with Connection Middleware. Connection Middleware is similar to HTTP Middleware in the ASP.NET Core pipeline but for lower-level connections. HTTPS and connection logging: +Connection Adapters (`Microsoft.AspNetCore.Server.Kestrel.Core.Adapter.Internal.IConnectionAdapter`) have been removed from Kestrel. Replace Connection Adapters with connection middleware. Connection middleware is similar to HTTP middleware in the ASP.NET Core pipeline but for lower-level connections. HTTPS and connection logging: -* Have been moved from Connection Adapters to Connection Middleware. +* Have been moved from Connection Adapters to connection middleware. * These extension methods work as in previous versions of ASP.NET Core. For more information, see [the TlsFilterConnectionHandler example in the ListenOptions.Protocols section of the Kestrel article](../fundamentals/servers/kestrel.md#listenoptionsprotocols). @@ -671,11 +671,11 @@ For more information, see . ### Security middleware guidance -Support for authorization and CORS is unified around the [middleware](xref:fundamentals/middleware/index) approach. This allows use of the same middleware and functionality across these scenarios. An updated authorization middleware is provided in this release, and CORS Middleware is enhanced so that it can understand the attributes used by MVC controllers. +Support for authorization and CORS is unified around the [middleware](xref:fundamentals/middleware/index) approach. This allows use of the same middleware and functionality across these scenarios. An updated authorization middleware is provided in this release, and CORS middleware is enhanced so that it can understand the attributes used by MVC controllers. #### CORS -Previously, CORS could be difficult to configure. Middleware was provided for use in some use cases, but MVC filters were intended to be used **without** the middleware in other use cases. With ASP.NET Core 3.0, we recommend that all apps that require CORS use the CORS Middleware in tandem with Endpoint Routing. `UseCors` can be provided with a default policy, and `[EnableCors]` and `[DisableCors]` attributes can be used to override the default policy where required. +Previously, CORS could be difficult to configure. Middleware was provided for use in some use cases, but MVC filters were intended to be used **without** the middleware in other use cases. With ASP.NET Core 3.0, we recommend that all apps that require CORS use the CORS middleware in tandem with Endpoint Routing. `UseCors` can be provided with a default policy, and `[EnableCors]` and `[DisableCors]` attributes can be used to override the default policy where required. In the following example: @@ -706,7 +706,7 @@ public class MyController : ControllerBase #### Authorization -In earlier versions of ASP.NET Core, authorization support was provided via the `[Authorize]` attribute. Authorization middleware wasn't available. In ASP.NET Core 3.0, authorization middleware is required. We recommend placing the ASP.NET Core Authorization Middleware (`UseAuthorization`) immediately after `UseAuthentication`. The Authorization Middleware can also be configured with a default policy, which can be overridden. +In earlier versions of ASP.NET Core, authorization support was provided via the `[Authorize]` attribute. Authorization middleware wasn't available. In ASP.NET Core 3.0, authorization middleware is required. We recommend placing the ASP.NET Core authorization middleware (`UseAuthorization`) immediately after `UseAuthentication`. The authorization middleware can also be configured with a default policy, which can be overridden. In ASP.NET Core 3.0 or later, `UseAuthorization` is called in `Startup.Configure`, and the following `HomeController` requires a signed in user: @@ -837,7 +837,7 @@ public void Configure(IApplicationBuilder app) } ``` -Protection is implemented for some scenarios. Endpoints Middleware throws an exception if an authorization or CORS policy is skipped due to missing middleware. Analyzer support to provide additional feedback about misconfiguration is in progress. +Protection is implemented for some scenarios. Endpoints middleware throws an exception if an authorization or CORS policy is skipped due to missing middleware. Analyzer support to provide additional feedback about misconfiguration is in progress. #### Custom authorization handlers @@ -993,7 +993,7 @@ public void Configure(IApplicationBuilder app) ### Use MVC without Endpoint Routing -Using MVC via `UseMvc` or `UseMvcWithDefaultRoute` in ASP.NET Core 3.0 requires an explicit opt-in inside `Startup.ConfigureServices`. This is required because MVC must know whether it can rely on the authorization and CORS Middleware during initialization. An analyzer is provided that warns if the app attempts to use an unsupported configuration. +Using MVC via `UseMvc` or `UseMvcWithDefaultRoute` in ASP.NET Core 3.0 requires an explicit opt-in inside `Startup.ConfigureServices`. This is required because MVC must know whether it can rely on the authorization and CORS middleware during initialization. An analyzer is provided that warns if the app attempts to use an unsupported configuration. If the app requires legacy `IRouter` support, disable `EnableEndpointRouting` using any of the following approaches in `Startup.ConfigureServices`: diff --git a/aspnetcore/migration/50-to-60-samples.md b/aspnetcore/migration/50-to-60-samples.md index 5576e57191b9..a2fd9cb72a9b 100644 --- a/aspnetcore/migration/50-to-60-samples.md +++ b/aspnetcore/migration/50-to-60-samples.md @@ -17,7 +17,7 @@ This article provides samples of code migrated to ASP.NET Core in .NET 6. ASP.NE ## Middleware -The following code adds the Static File Middleware to a .NET 5 app: +The following code adds the static file middleware to a .NET 5 app: ```csharp public class Startup @@ -29,7 +29,7 @@ public class Startup } ``` -The following code adds the Static File Middleware to an ASP.NET Core in .NET 6 app: +The following code adds the static file middleware to an ASP.NET Core in .NET 6 app: [!code-csharp[](50-to-60-samples/samples/Web6Samples/Program.cs?name=snippet_mid)] @@ -211,7 +211,7 @@ public static IHostBuilder CreateHostBuilder(string[] args) => ## Change the web root -By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the Static File Middleware looks for static files. Web root can be changed by setting the property on : +By default, the web root is relative to the content root in the `wwwroot` folder. Web root is where the static file middleware looks for static files. Web root can be changed by setting the property on : ### ASP.NET Core in .NET 5 diff --git a/aspnetcore/migration/70-to-80.md b/aspnetcore/migration/70-to-80.md index 53a484fbffd3..76482941f46c 100644 --- a/aspnetcore/migration/70-to-80.md +++ b/aspnetcore/migration/70-to-80.md @@ -275,13 +275,13 @@ Blazor Server apps are supported in .NET 8 without any code changes. Use the fol - app.MapFallbackToPage("/_Host"); ``` - Remove Routing Middleware: + Remove routing middleware: ```diff - app.UseRouting(); ``` - Add [Antiforgery Middleware](xref:blazor/security/index#antiforgery-support) to the request processing pipeline after the line that adds HTTPS Redirection Middleware (`app.UseHttpsRedirection`): + Add [antiforgery middleware](xref:blazor/security/index#antiforgery-support) to the request processing pipeline after the line that adds HTTPS redirection middleware (`app.UseHttpsRedirection`): ```csharp app.UseAntiforgery(); @@ -429,7 +429,7 @@ Blazor WebAssembly apps are supported in .NET 8 without any code changes. Use th .AddInteractiveWebAssemblyComponents(); ``` - Add [Antiforgery Middleware](xref:blazor/security/index#antiforgery-support) to the request processing pipeline. + Add [antiforgery middleware](xref:blazor/security/index#antiforgery-support) to the request processing pipeline. Place the following line after the call to `app.UseHttpsRedirection`. The call to `app.UseAntiforgery` must be placed after calls, if present, to `app.UseAuthentication` and `app.UseAuthorization`. There's no need to explicitly add antiforgery services (`builder.Services.AddAntiforgery`), as they're added automatically by , which was covered earlier. @@ -581,7 +581,7 @@ The `[Parameter]` attribute is no longer required when supplying a parameter fro ### Blazor Server script fallback policy authorization -In .NET 7, the Blazor Server script (`blazor.server.js`) is [served by Static File Middleware](https://github.com/dotnet/aspnetcore/blob/v7.0.16/src/Components/Server/src/DependencyInjection/ConfigureStaticFilesOptions.cs). Placing the call for Static File Middleware () in the request processing pipeline before the call to Authorization Middleware () is sufficient in .NET 7 apps to serve the Blazor script to anonymous users. +In .NET 7, the Blazor Server script (`blazor.server.js`) is [served by static file middleware](https://github.com/dotnet/aspnetcore/blob/v7.0.16/src/Components/Server/src/DependencyInjection/ConfigureStaticFilesOptions.cs). Placing the call for static file middleware () in the request processing pipeline before the call to authorization middleware () is sufficient in .NET 7 apps to serve the Blazor script to anonymous users. In .NET 8, the Blazor Server script is served [by its own endpoint](https://github.com/search?q=repo%3Adotnet%2Faspnetcore%20GetBlazorEndpoint&type=code), using endpoint routing. This change is introduced by [Fixed bug - Passing options to UseStaticFiles breaks Blazor Server (`dotnet/aspnetcore` #45897)](https://github.com/dotnet/aspnetcore/pull/45897). diff --git a/aspnetcore/migration/fx-to-core/areas/authentication.md b/aspnetcore/migration/fx-to-core/areas/authentication.md index 12c07a09e758..2a9695357a84 100644 --- a/aspnetcore/migration/fx-to-core/areas/authentication.md +++ b/aspnetcore/migration/fx-to-core/areas/authentication.md @@ -317,7 +317,7 @@ This remote authentication approach has a couple known limitations: ## Shared cookie authentication -If authentication in the ASP.NET app is done using `Microsoft.Owin` Cookie Authentication Middleware, an alternative solution to remote authentication is to configure the ASP.NET and ASP.NET Core apps so that they are able to share an authentication cookie. +If authentication in the ASP.NET app is done using `Microsoft.Owin` cookie authentication middleware, an alternative solution to remote authentication is to configure the ASP.NET and ASP.NET Core apps so that they are able to share an authentication cookie. ### How shared cookies work diff --git a/aspnetcore/migration/fx-to-core/areas/http-handlers.md b/aspnetcore/migration/fx-to-core/areas/http-handlers.md index bf2bd045c8cc..db6a7be074d9 100644 --- a/aspnetcore/migration/fx-to-core/areas/http-handlers.md +++ b/aspnetcore/migration/fx-to-core/areas/http-handlers.md @@ -50,7 +50,7 @@ Before proceeding to ASP.NET Core middleware, let's first recap how HTTP handler * Able to create their own HTTP response -![Authorization Middleware short-circuits a request for a user who isn't authorized. A request for the Index page is permitted and processed by MVC Middleware. A request for a sales report is permitted and processed by a custom report Middleware.](_static/middleware.png) +![Authorization middleware short-circuits a request for a user who isn't authorized. A request for the Index page is permitted and processed by MVC middleware. A request for a sales report is permitted and processed by a custom report middleware.](_static/middleware.png) ## Migrating handler code to middleware diff --git a/aspnetcore/migration/fx-to-core/areas/http-modules.md b/aspnetcore/migration/fx-to-core/areas/http-modules.md index 6fc5717a15d8..d37242fc00fd 100644 --- a/aspnetcore/migration/fx-to-core/areas/http-modules.md +++ b/aspnetcore/migration/fx-to-core/areas/http-modules.md @@ -74,7 +74,7 @@ In addition to modules, you can add handlers for the life cycle events to your ` * See [Create a middleware pipeline with IApplicationBuilder](xref:fundamentals/middleware/index#create-a-middleware-pipeline-with-iapplicationbuilder) -![Authorization Middleware short-circuits a request for a user who isn't authorized. A request for the Index page is permitted and processed by MVC Middleware. A request for a sales report is permitted and processed by a custom report Middleware.](_static/middleware.png) +![Authorization middleware short-circuits a request for a user who isn't authorized. A request for the Index page is permitted and processed by MVC middleware. A request for a sales report is permitted and processed by a custom report middleware.](_static/middleware.png) Note how in the image above, the authentication middleware short-circuited the request. diff --git a/aspnetcore/mvc/controllers/filters.md b/aspnetcore/mvc/controllers/filters.md index 39c48c7b2e8b..a70c7ca622ef 100644 --- a/aspnetcore/mvc/controllers/filters.md +++ b/aspnetcore/mvc/controllers/filters.md @@ -32,7 +32,7 @@ This document applies to Razor Pages, API controllers, and controllers with view Filters run within the *ASP.NET Core action invocation pipeline*, sometimes referred to as the *filter pipeline*. The filter pipeline runs after ASP.NET Core selects the action to execute: -:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through Other Middleware, Routing Middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, Routing Middleware, and various Other Middleware before becoming a response sent to the client."::: +:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through other middleware, routing middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, routing middleware, and various other middleware before becoming a response sent to the client."::: The following diagram shows the filter pipeline execution order for MVC and Razor Pages: diff --git a/aspnetcore/mvc/controllers/filters/includes/filters7.md b/aspnetcore/mvc/controllers/filters/includes/filters7.md index 53d85822eec4..be796edbf875 100644 --- a/aspnetcore/mvc/controllers/filters/includes/filters7.md +++ b/aspnetcore/mvc/controllers/filters/includes/filters7.md @@ -20,7 +20,7 @@ This document applies to Razor Pages, API controllers, and controllers with view Filters run within the *ASP.NET Core action invocation pipeline*, sometimes referred to as the *filter pipeline*. The filter pipeline runs after ASP.NET Core selects the action to execute: -:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through Other Middleware, Routing Middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, Routing Middleware, and various Other Middleware before becoming a response sent to the client."::: +:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through other middleware, routing middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, routing middleware, and various other middleware before becoming a response sent to the client."::: ### Filter types @@ -564,7 +564,7 @@ This document applies to Razor Pages, API controllers, and controllers with view Filters run within the *ASP.NET Core action invocation pipeline*, sometimes referred to as the *filter pipeline*. The filter pipeline runs after ASP.NET Core selects the action to execute. -:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through Other Middleware, Routing Middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, Routing Middleware, and various Other Middleware before becoming a response sent to the client."::: +:::image source="~/mvc/controllers/filters/_static/filter-pipeline-1.png" alt-text="The request is processed through other middleware, routing middleware, Action Selection, and the Action Invocation Pipeline. The request processing continues back through Action Selection, routing middleware, and various other middleware before becoming a response sent to the client."::: ### Filter types diff --git a/aspnetcore/mvc/controllers/routing.md b/aspnetcore/mvc/controllers/routing.md index 84505e167edf..ec94320d5920 100644 --- a/aspnetcore/mvc/controllers/routing.md +++ b/aspnetcore/mvc/controllers/routing.md @@ -2,7 +2,7 @@ title: Routing to controller actions in ASP.NET Core ai-usage: ai-assisted author: tdykstra -description: Learn how ASP.NET Core MVC uses Routing Middleware to match URLs of incoming requests and map them to actions. +description: Learn how ASP.NET Core MVC uses routing middleware to match URLs of incoming requests and map them to actions. ms.author: tdykstra ms.date: 02/25/2026 uid: mvc/controllers/routing diff --git a/aspnetcore/performance/caching/middleware.md b/aspnetcore/performance/caching/middleware.md index 78379b2a2db1..b34e703df567 100644 --- a/aspnetcore/performance/caching/middleware.md +++ b/aspnetcore/performance/caching/middleware.md @@ -1,26 +1,26 @@ --- -title: Response Caching Middleware in ASP.NET Core +title: Response caching middleware in ASP.NET Core author: tdykstra -description: Learn how to configure and use Response Caching Middleware in ASP.NET Core. +description: Learn how to configure and use response caching middleware in ASP.NET Core. monikerRange: '>= aspnetcore-3.1' ms.author: tdykstra ms.custom: mvc ms.date: 1/1/2022 uid: performance/caching/middleware --- -# Response Caching Middleware in ASP.NET Core +# Response caching middleware in ASP.NET Core By [John Luo](https://github.com/JunTaoLuo) and [Rick Anderson](https://twitter.com/RickAndMSFT) :::moniker range=">= aspnetcore-6.0" -This article explains how to configure [Response Caching Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching/src/ResponseCachingMiddleware.cs) in an ASP.NET Core app. The middleware determines when responses are cacheable, stores responses, and serves responses from cache. For an introduction to HTTP caching and the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute, see [Response Caching](xref:performance/caching/response). +This article explains how to configure [response caching middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching/src/ResponseCachingMiddleware.cs) in an ASP.NET Core app. The middleware determines when responses are cacheable, stores responses, and serves responses from cache. For an introduction to HTTP caching and the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute, see [Response Caching](xref:performance/caching/response). [!INCLUDE[](~/includes/response-caching-mid.md)] ## Configuration -In `Program.cs`, add the Response Caching Middleware services to the service collection and configure the app to use the middleware with the extension method. `UseResponseCaching` adds the middleware to the request processing pipeline: +In `Program.cs`, add the response caching middleware services to the service collection and configure the app to use the middleware with the extension method. `UseResponseCaching` adds the middleware to the request processing pipeline: [!code-csharp[](middleware/samples/6.x/ResponseCachingMiddleware/Program.cs?name=snippet2&highlight=3,12)] @@ -38,7 +38,7 @@ The preceding headers are not written to the response and are overridden when a * Has a [[ResponseCache]](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute. This applies even if a property isn't set. For example, omitting the [VaryByHeader](./response.md#vary) property will cause the corresponding header to be removed from the response. -Response Caching Middleware only caches server responses that result in a 200 (OK) status code. Any other responses, including [error pages](xref:fundamentals/error-handling), are ignored by the middleware. +Response caching middleware only caches server responses that result in a 200 (OK) status code. Any other responses, including [error pages](xref:fundamentals/error-handling), are ignored by the middleware. > [!WARNING] > Responses containing content for authenticated clients must be marked as not cacheable to prevent the middleware from storing and serving those responses. See [Conditions for caching](#conditions-for-caching) for details on how the middleware determines if a response is cacheable. @@ -79,7 +79,7 @@ if (responseCachingFeature != null) Using a single value equal to `*` in `VaryByQueryKeys` varies the cache by all request query parameters. -## HTTP headers used by Response Caching Middleware +## HTTP headers used by response caching middleware The following table provides information on HTTP headers that affect response caching. @@ -88,7 +88,7 @@ The following table provides information on HTTP headers that affect response ca | `Authorization` | The response isn't cached if the header exists. | | `Cache-Control` | The middleware only considers caching responses marked with the `public` cache directive. Control caching with the following parameters:
  • max-age
  • max-stale†
  • min-fresh
  • must-revalidate
  • no-cache
  • no-store
  • only-if-cached
  • private
  • public
  • s-maxage
  • proxy-revalidate‡
†If no limit is specified to `max-stale`, the middleware takes no action.
‡`proxy-revalidate` has the same effect as `must-revalidate`.

For more information, see [RFC 9111: Request Directives](https://www.rfc-editor.org/rfc/rfc9111.html#name-request-directives). | | `Pragma` | A `Pragma: no-cache` header in the request produces the same effect as `Cache-Control: no-cache`. This header is overridden by the relevant directives in the `Cache-Control` header, if present. Considered for backward compatibility with HTTP/1.0. | -| `Set-Cookie` | The response isn't cached if the header exists. Any middleware in the request processing pipeline that sets one or more cookies prevents the Response Caching Middleware from caching the response (for example, the [cookie-based TempData provider](xref:fundamentals/app-state#tempdata)). | +| `Set-Cookie` | The response isn't cached if the header exists. Any middleware in the request processing pipeline that sets one or more cookies prevents the response caching middleware from caching the response (for example, the [cookie-based TempData provider](xref:fundamentals/app-state#tempdata)). | | `Vary` | The `Vary` header is used to vary the cached response by another header. For example, cache responses by encoding by including the `Vary: Accept-Encoding` header, which caches responses for requests with headers `Accept-Encoding: gzip` and `Accept-Encoding: text/plain` separately. A response with a header value of `*` is never stored. | | `Expires` | A response deemed stale by this header isn't stored or retrieved unless overridden by other `Cache-Control` headers. | | `If-None-Match` | The full response is served from cache if the value isn't `*` and the `ETag` of the response doesn't match any of the values provided. Otherwise, a 304 (Not Modified) response is served. | @@ -110,7 +110,7 @@ For more control over caching behavior, explore other caching features of ASP.NE ## Troubleshooting -The [Response Caching Middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching/src/ResponseCachingMiddleware.cs) uses , which has a limited capacity. When the capacity is exceeded, the [memory cache is compacted (`TriggerOvercapacityCompaction`)](https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Caching.Memory/src/MemoryCache.cs). +The [response caching middleware](https://github.com/dotnet/aspnetcore/blob/main/src/Middleware/ResponseCaching/src/ResponseCachingMiddleware.cs) uses , which has a limited capacity. When the capacity is exceeded, the [memory cache is compacted (`TriggerOvercapacityCompaction`)](https://github.com/dotnet/runtime/blob/main/src/libraries/Microsoft.Extensions.Caching.Memory/src/MemoryCache.cs). [!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)] @@ -124,7 +124,7 @@ When testing and troubleshooting caching behavior, a browser typically sets requ * The request must result in a server response with a 200 (OK) status code. * The request method must be GET or HEAD. -* Response Caching Middleware must be placed before middleware that require caching. For more information, see . +* Response caching middleware must be placed before middleware that require caching. For more information, see . * The `Authorization` header must not be present. * `Cache-Control` header parameters must be valid, and the response must be marked `public` and not marked `private`. * The `Pragma: no-cache` header must not be present if the `Cache-Control` header isn't present, as the `Cache-Control` header overrides the `Pragma` header when present. @@ -157,15 +157,15 @@ When testing and troubleshooting caching behavior, a browser typically sets requ :::moniker range="< aspnetcore-6.0" -This article explains how to configure Response Caching Middleware in an ASP.NET Core app. The middleware determines when responses are cacheable, stores responses, and serves responses from cache. For an introduction to HTTP caching and the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute, see [Response Caching](xref:performance/caching/response). +This article explains how to configure response caching middleware in an ASP.NET Core app. The middleware determines when responses are cacheable, stores responses, and serves responses from cache. For an introduction to HTTP caching and the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute, see [Response Caching](xref:performance/caching/response). [View or download sample code](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/caching/middleware/samples) ([how to download](xref:fundamentals/index#how-to-download-a-sample)) ## Configuration -Response Caching Middleware is implicitly available for ASP.NET Core apps via the shared framework. +Response caching middleware is implicitly available for ASP.NET Core apps via the shared framework. -In `Startup.ConfigureServices`, add the Response Caching Middleware to the service collection: +In `Startup.ConfigureServices`, add the response caching middleware to the service collection: [!code-csharp[](middleware/samples/3.x/ResponseCachingMiddleware/Startup.cs?name=snippet1&highlight=3)] @@ -187,7 +187,7 @@ The preceding headers are not written to the response and are overridden when a * Has a [[ResponseCache]](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) attribute. This applies even if a property isn't set. For example, omitting the [VaryByHeader](./response.md#vary) property will cause the corresponding header to be removed from the response. -Response Caching Middleware only caches server responses that result in a 200 (OK) status code. Any other responses, including [error pages](xref:fundamentals/error-handling), are ignored by the middleware. +Response caching middleware only caches server responses that result in a 200 (OK) status code. Any other responses, including [error pages](xref:fundamentals/error-handling), are ignored by the middleware. > [!WARNING] > Responses containing content for authenticated clients must be marked as not cacheable to prevent the middleware from storing and serving those responses. See [Conditions for caching](#conditions-for-caching) for details on how the middleware determines if a response is cacheable. @@ -232,7 +232,7 @@ if (responseCachingFeature != null) Using a single value equal to `*` in `VaryByQueryKeys` varies the cache by all request query parameters. -## HTTP headers used by Response Caching Middleware +## HTTP headers used by response caching middleware The following table provides information on HTTP headers that affect response caching. @@ -241,7 +241,7 @@ The following table provides information on HTTP headers that affect response ca | `Authorization` | The response isn't cached if the header exists. | | `Cache-Control` | The middleware only considers caching responses marked with the `public` cache directive. Control caching with the following parameters:
  • max-age
  • max-stale†
  • min-fresh
  • must-revalidate
  • no-cache
  • no-store
  • only-if-cached
  • private
  • public
  • s-maxage
  • proxy-revalidate‡
†If no limit is specified to `max-stale`, the middleware takes no action.
‡`proxy-revalidate` has the same effect as `must-revalidate`.

For more information, see [RFC 9111: Request Directives](https://www.rfc-editor.org/rfc/rfc9111.html#name-request-directives). | | `Pragma` | A `Pragma: no-cache` header in the request produces the same effect as `Cache-Control: no-cache`. This header is overridden by the relevant directives in the `Cache-Control` header, if present. Considered for backward compatibility with HTTP/1.0. | -| `Set-Cookie` | The response isn't cached if the header exists. Any middleware in the request processing pipeline that sets one or more cookies prevents the Response Caching Middleware from caching the response (for example, the [cookie-based TempData provider](xref:fundamentals/app-state#tempdata)). | +| `Set-Cookie` | The response isn't cached if the header exists. Any middleware in the request processing pipeline that sets one or more cookies prevents the response caching middleware from caching the response (for example, the [cookie-based TempData provider](xref:fundamentals/app-state#tempdata)). | | `Vary` | The `Vary` header is used to vary the cached response by another header. For example, cache responses by encoding by including the `Vary: Accept-Encoding` header, which caches responses for requests with headers `Accept-Encoding: gzip` and `Accept-Encoding: text/plain` separately. A response with a header value of `*` is never stored. | | `Expires` | A response deemed stale by this header isn't stored or retrieved unless overridden by other `Cache-Control` headers. | | `If-None-Match` | The full response is served from cache if the value isn't `*` and the `ETag` of the response doesn't match any of the values provided. Otherwise, a 304 (Not Modified) response is served. | @@ -273,7 +273,7 @@ When testing and troubleshooting caching behavior, a browser may set request hea * The request must result in a server response with a 200 (OK) status code. * The request method must be GET or HEAD. -* In `Startup.Configure`, Response Caching Middleware must be placed before middleware that require caching. For more information, see . +* In `Startup.Configure`, response caching middleware must be placed before middleware that require caching. For more information, see . * The `Authorization` header must not be present. * `Cache-Control` header parameters must be valid, and the response must be marked `public` and not marked `private`. * The `Pragma: no-cache` header must not be present if the `Cache-Control` header isn't present, as the `Cache-Control` header overrides the `Pragma` header when present. diff --git a/aspnetcore/performance/caching/middleware/samples/2.x/ResponseCachingMiddleware/README.md b/aspnetcore/performance/caching/middleware/samples/2.x/ResponseCachingMiddleware/README.md index 8bab8926d39b..60bf9425d581 100644 --- a/aspnetcore/performance/caching/middleware/samples/2.x/ResponseCachingMiddleware/README.md +++ b/aspnetcore/performance/caching/middleware/samples/2.x/ResponseCachingMiddleware/README.md @@ -1,6 +1,6 @@ # ASP.NET Core Response Caching Sample -This sample illustrates the usage of ASP.NET Core [Response Caching Middleware](https://learn.microsoft.com/aspnet/core/performance/caching/middleware). +This sample illustrates the usage of ASP.NET Core [response caching middleware](https://learn.microsoft.com/aspnet/core/performance/caching/middleware). The app responds with its Index page, including a `Cache-Control` header to configure caching behavior. The app also sets the `Vary` header to configure the cache to serve the response only if the `Accept-Encoding` header of subsequent requests matches that from the original request. diff --git a/aspnetcore/performance/caching/middleware/samples/3.x/ResponseCachingMiddleware/README.md b/aspnetcore/performance/caching/middleware/samples/3.x/ResponseCachingMiddleware/README.md index 8bab8926d39b..60bf9425d581 100644 --- a/aspnetcore/performance/caching/middleware/samples/3.x/ResponseCachingMiddleware/README.md +++ b/aspnetcore/performance/caching/middleware/samples/3.x/ResponseCachingMiddleware/README.md @@ -1,6 +1,6 @@ # ASP.NET Core Response Caching Sample -This sample illustrates the usage of ASP.NET Core [Response Caching Middleware](https://learn.microsoft.com/aspnet/core/performance/caching/middleware). +This sample illustrates the usage of ASP.NET Core [response caching middleware](https://learn.microsoft.com/aspnet/core/performance/caching/middleware). The app responds with its Index page, including a `Cache-Control` header to configure caching behavior. The app also sets the `Vary` header to configure the cache to serve the response only if the `Accept-Encoding` header of subsequent requests matches that from the original request. diff --git a/aspnetcore/performance/caching/output.md b/aspnetcore/performance/caching/output.md index c28e5eb3d4bc..67c2623b19f8 100644 --- a/aspnetcore/performance/caching/output.md +++ b/aspnetcore/performance/caching/output.md @@ -256,7 +256,7 @@ The recommended approach is to use the built-in support for Redis or create a cu ## Related content * [Overview of caching in ASP.NET Core](xref:performance/caching/overview) -* [ASP.NET Core Middleware](xref:fundamentals/middleware/index) +* [ASP.NET Core middleware](xref:fundamentals/middleware/index) * * diff --git a/aspnetcore/performance/caching/response.md b/aspnetcore/performance/caching/response.md index b1775e239865..a7471aa72aed 100644 --- a/aspnetcore/performance/caching/response.md +++ b/aspnetcore/performance/caching/response.md @@ -19,7 +19,7 @@ Response caching reduces the number of requests a client or proxy makes to a web The [ResponseCache attribute](#responsecache-attribute) sets response caching headers. Clients and intermediate proxies should honor the headers for caching responses under the [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111) specification. -For server-side caching that follows the HTTP 1.1 Caching specification, use [Response Caching Middleware](xref:performance/caching/middleware). The middleware can use the properties to influence server-side caching behavior. +For server-side caching that follows the HTTP 1.1 Caching specification, use [response caching middleware](xref:performance/caching/middleware). The middleware can use the properties to influence server-side caching behavior. [!INCLUDE[](~/includes/response-caching-mid.md)] @@ -54,7 +54,7 @@ The [RFC 9111: HTTP Caching (Section 5.2. Cache-Control)](https://www.rfc-editor Always honoring client `Cache-Control` request headers makes sense if you consider the goal of HTTP caching. Under the official specification, caching is meant to reduce the latency and network overhead of satisfying requests across a network of clients, proxies, and servers. It isn't necessarily a way to control the load on an origin server. -There's no developer control over this caching behavior when using the [Response Caching Middleware](xref:performance/caching/middleware) because the middleware adheres to the official caching specification. .NET 7 and later includes support for *output caching* to better control server load. For more information, see [Output caching](xref:performance/caching/overview#output-caching). +There's no developer control over this caching behavior when using the [response caching middleware](xref:performance/caching/middleware) because the middleware adheres to the official caching specification. .NET 7 and later includes support for *output caching* to better control server load. For more information, see [Output caching](xref:performance/caching/overview#output-caching). ## ResponseCache attribute @@ -65,7 +65,7 @@ The class specifies the p The property varies the stored response by the values of the given list of query keys. When a single value of the wildcard asterisk (`*`) is provided, the middleware varies responses by all request query string parameters. -[Response Caching Middleware](xref:performance/caching/middleware) must be enabled to set the property. Otherwise, a runtime exception is thrown. There isn't a corresponding HTTP header for the property. The property is an HTTP feature handled by Response Caching Middleware. For the middleware to serve a cached response, the query string and query string value must match a previous request. For example, consider the sequence of requests and results shown in the following table: +[Response caching middleware](xref:performance/caching/middleware) must be enabled to set the property. Otherwise, a runtime exception is thrown. There isn't a corresponding HTTP header for the property. The property is an HTTP feature handled by response caching middleware. For the middleware to serve a cached response, the query string and query string value must match a previous request. For example, consider the sequence of requests and results shown in the following table: | Request | Returned from | | -------------------------------- | ------------------------- | @@ -94,7 +94,7 @@ Cache-Control: public,max-age=30 Vary: User-Agent ``` -The preceding code requires adding the Response Caching Middleware services method to the service collection. The code configures the app to use the middleware with the extension method. +The preceding code requires adding the response caching middleware services method to the service collection. The code configures the app to use the middleware with the extension method. [!code-csharp[](response/samples/6.x/WebRC/Program.cs?name=snippet&highlight=4,13)] @@ -140,11 +140,11 @@ To enable caching, the pro The property options of `Any` and `Client` translate into `Cache-Control` header values of `public` and `private`, respectively. As noted in the [NoStore and Location.None](#nostore-and-locationnone-properties) section, setting the property to `None` sets both the `Cache-Control` and `Pragma` headers to `no-cache`. -The `Location.Any` (`Cache-Control` set to `public`) property setting indicates that the *client or any intermediate proxy* can cache the value, including [Response Caching Middleware](xref:performance/caching/middleware). +The `Location.Any` (`Cache-Control` set to `public`) property setting indicates that the *client or any intermediate proxy* can cache the value, including [response caching middleware](xref:performance/caching/middleware). -The `Location.Client` (`Cache-Control` set to `private`) property setting indicates that *only the client* can cache the value. No intermediate cache should cache the value, including [Response Caching Middleware](xref:performance/caching/middleware). +The `Location.Client` (`Cache-Control` set to `private`) property setting indicates that *only the client* can cache the value. No intermediate cache should cache the value, including [response caching middleware](xref:performance/caching/middleware). -Cache control headers provide guidance to clients and intermediary proxies about when and how to cache responses. There's no guarantee that clients and proxies honor the [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111) specification. [Response Caching Middleware](xref:performance/caching/middleware) always follows the caching rules laid out by the specification. +Cache control headers provide guidance to clients and intermediary proxies about when and how to cache responses. There's no guarantee that clients and proxies honor the [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111) specification. [Response caching middleware](xref:performance/caching/middleware) always follows the caching rules laid out by the specification. The following example shows the headers produced by setting the property and leaving the default property value: @@ -200,7 +200,7 @@ Response caching reduces the number of requests a client or proxy makes to a web The [`[ResponseCache]`](#responsecache-attribute) participates in setting response caching headers. Clients and intermediate proxies should honor the headers for caching responses under [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111). -For server-side caching that follows the HTTP 1.1 Caching specification, use [Response Caching Middleware](xref:performance/caching/middleware). The middleware can use the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) properties to set server-side caching headers. +For server-side caching that follows the HTTP 1.1 Caching specification, use [response caching middleware](xref:performance/caching/middleware). The middleware can use the [`[ResponseCache]`](xref:Microsoft.AspNetCore.Mvc.ResponseCacheAttribute) properties to set server-side caching headers. ## HTTP-based response caching @@ -231,7 +231,7 @@ Other cache headers that play a role in caching are shown in the following table Always honoring client `Cache-Control` request headers makes sense if you consider the goal of HTTP caching. Under the official specification, caching is meant to reduce the latency and network overhead of satisfying requests across a network of clients, proxies, and servers. It isn't necessarily a way to control the load on an origin server. -There's no developer control over this caching behavior when using the [Response Caching Middleware](xref:performance/caching/middleware) because the middleware adheres to the official caching specification. Support for *output caching* to better control server load is a design proposal for a future release of ASP.NET Core. For more information, see [Add support for Output Caching (dotnet/aspnetcore #27387)](https://github.com/dotnet/aspnetcore/issues/27387). +There's no developer control over this caching behavior when using the [response caching middleware](xref:performance/caching/middleware) because the middleware adheres to the official caching specification. Support for *output caching* to better control server load is a design proposal for a future release of ASP.NET Core. For more information, see [Add support for Output Caching (dotnet/aspnetcore #27387)](https://github.com/dotnet/aspnetcore/issues/27387). ## Other caching technology in ASP.NET Core @@ -268,7 +268,7 @@ The specifies the paramet varies the stored response by the values of the given list of query keys. When a single value of `*` is provided, the middleware varies responses by all request query string parameters. -[Response Caching Middleware](xref:performance/caching/middleware) must be enabled to set the property. Otherwise, a runtime exception is thrown. There isn't a corresponding HTTP header for the property. The property is an HTTP feature handled by Response Caching Middleware. For the middleware to serve a cached response, the query string and query string value must match a previous request. For example, consider the sequence of requests and results shown in the following table. +[Response caching middleware](xref:performance/caching/middleware) must be enabled to set the property. Otherwise, a runtime exception is thrown. There isn't a corresponding HTTP header for the property. The property is an HTTP feature handled by response caching middleware. For the middleware to serve a cached response, the query string and query string value must match a previous request. For example, consider the sequence of requests and results shown in the following table. | Request | Result | | -------------------------------- | ------------------------- | @@ -339,11 +339,11 @@ To enable caching, must be 's options of `Any` and `Client` translate into `Cache-Control` header values of `public` and `private`, respectively. As noted in the [NoStore and Location.None](#nostore-and-locationnone) section, setting to `None` sets both `Cache-Control` and `Pragma` headers to `no-cache`. -`Location.Any` (`Cache-Control` set to `public`) indicates that the *client or any intermediate proxy* may cache the value, including [Response Caching Middleware](xref:performance/caching/middleware). +`Location.Any` (`Cache-Control` set to `public`) indicates that the *client or any intermediate proxy* may cache the value, including [response caching middleware](xref:performance/caching/middleware). -`Location.Client` (`Cache-Control` set to `private`) indicates that *only the client* may cache the value. No intermediate cache should cache the value, including [Response Caching Middleware](xref:performance/caching/middleware). +`Location.Client` (`Cache-Control` set to `private`) indicates that *only the client* may cache the value. No intermediate cache should cache the value, including [response caching middleware](xref:performance/caching/middleware). -Cache control headers merely provide guidance to clients and intermediary proxies when and how to cache responses. There's no guarantee that clients and proxies will honor [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111). [Response Caching Middleware](xref:performance/caching/middleware) always follows the caching rules laid out by the specification. +Cache control headers merely provide guidance to clients and intermediary proxies when and how to cache responses. There's no guarantee that clients and proxies will honor [RFC 9111: HTTP Caching](https://www.rfc-editor.org/rfc/rfc9111). [Response caching middleware](xref:performance/caching/middleware) always follows the caching rules laid out by the specification. The following example shows the Cache3 page model from the sample app and the headers produced by setting and leaving the default value: diff --git a/aspnetcore/performance/memory.md b/aspnetcore/performance/memory.md index bc1e4e275e00..71119b8f06c2 100644 --- a/aspnetcore/performance/memory.md +++ b/aspnetcore/performance/memory.md @@ -267,7 +267,7 @@ Comparing the two preceding charts: Temporary large objects are problematic because they cause Gen 2 collections. -For maximum performance, minimize the use of large objects. If possible, split up large objects. For example, [Response Caching Middleware](xref:performance/caching/response) in ASP.NET Core splits the cache entries into blocks less than 85,000 bytes. +For maximum performance, minimize the use of large objects. If possible, split up large objects. For example, [response caching middleware](xref:performance/caching/response) in ASP.NET Core splits the cache entries into blocks less than 85,000 bytes. The following links show the ASP.NET Core approach to keeping objects under the LOH limit: diff --git a/aspnetcore/performance/rate-limit.md b/aspnetcore/performance/rate-limit.md index 8aa7e97ad3d0..b8c82841cc60 100644 --- a/aspnetcore/performance/rate-limit.md +++ b/aspnetcore/performance/rate-limit.md @@ -48,7 +48,7 @@ When using a cloud hosting service, DDoS protection is usually available as part Implementing a commercial DDoS protection service in conjunction with rate limiting can provide a comprehensive defense strategy, ensuring the stability, security, and performance of an app. -## Use Rate Limiting Middleware +## Use rate-limiting middleware The following steps show how to use the rate limiting middleware in an ASP.NET Core app: diff --git a/aspnetcore/performance/response-compression.md b/aspnetcore/performance/response-compression.md index 7077d357354c..f1847ce7eeba 100644 --- a/aspnetcore/performance/response-compression.md +++ b/aspnetcore/performance/response-compression.md @@ -1,7 +1,7 @@ --- title: Response compression in ASP.NET Core author: tdykstra -description: Learn about response compression and how to use Response Compression Middleware in ASP.NET Core apps. +description: Learn about response compression and how to use response compression middleware in ASP.NET Core apps. ai-usage: ai-assisted monikerRange: '>= aspnetcore-3.1' ms.author: tdykstra @@ -9,13 +9,13 @@ ms.custom: mvc ms.date: 07/02/2026 uid: performance/response-compression -# customer intent: As an ASP.NET developer, I want to configure Response Compression Middleware in ASP.NET Core, so I use response compression in my apps. +# customer intent: As an ASP.NET developer, I want to configure response compression middleware in ASP.NET Core, so I use response compression in my apps. --- # Response compression in ASP.NET Core :::moniker range=">= aspnetcore-6.0" -Network bandwidth is a limited resource. Reducing the size of the response usually increases the responsiveness of an app, often dramatically. One way to reduce payload size is to compress the responses from an application. This article describes how to implement response compression for your apps by using Response Compression Middleware in ASP.NET Core. +Network bandwidth is a limited resource. Reducing the size of the response usually increases the responsiveness of an app, often dramatically. One way to reduce payload size is to compress the responses from an application. This article describes how to implement response compression for your apps by using response compression middleware in ASP.NET Core. ## Explore compression with HTTPS @@ -23,11 +23,11 @@ Compressed responses over secure connections can be controlled with the Middleware order](xref:fundamentals/middleware/index#middleware-order). +* The [app.UseResponseCompression](xref:Microsoft.AspNetCore.Builder.ResponseCompressionBuilderExtensions.UseResponseCompression%2A) method must be called ***before*** any middleware that compresses responses. For more information, see [ASP.NET Core middleware > Middleware order](xref:fundamentals/middleware/index#middleware-order). * Use a tool such as [Firefox Browser - Developer edition](https://www.firefox.com/channel/desktop/developer/) to set the `Accept-Encoding` request header and examine the response headers, size, and body. Submit a request to the sample app without the `Accept-Encoding` header and observe that the response is uncompressed. The `Content-Encoding` header isn't in the Response Headers collection. @@ -265,7 +265,7 @@ To disable IIS Dynamic Compression Module configured at the server level, see [D ## Troubleshoot response compression -Use a tool like [Firefox Browser - Developer edition](https://www.firefox.com/channel/desktop/developer/) that lets you set the `Accept-Encoding` request header and study the response headers, size, and body. By default, Response Compression Middleware compresses responses that meet the following conditions: +Use a tool like [Firefox Browser - Developer edition](https://www.firefox.com/channel/desktop/developer/) that lets you set the `Accept-Encoding` request header and study the response headers, size, and body. By default, response compression middleware compresses responses that meet the following conditions: :::moniker-end @@ -287,7 +287,7 @@ Use a tool like [Firefox Browser - Developer edition](https://www.firefox.com/ch * The request must not include the [Content-Range header](https://developer.mozilla.org/docs/Web/HTTP/Reference/Headers/Content-Range). -* The request must use the insecure hypertext protocol (http), unless the secure hypertext protocol (https) is configured in the Response Compression Middleware options. +* The request must use the insecure hypertext protocol (http), unless the secure hypertext protocol (https) is configured in the response compression middleware options. > [!IMPORTANT] > Review the risks associated with enabling secure content compression, as described in [Compression with HTTPS](#explore-compression-with-https) earlier in this article. @@ -315,11 +315,11 @@ Network bandwidth is a limited resource. Reducing the size of the response usual [View or download sample code](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples) ([how to download](xref:fundamentals/index#how-to-download-a-sample)) -## When to use Response Compression Middleware +## When to use response compression middleware Use server-based response compression technologies in IIS, Apache, or Nginx. The performance of the middleware probably won't match that of the server modules. [HTTP.sys](xref:fundamentals/servers/httpsys) server and [Kestrel](xref:fundamentals/servers/kestrel) server don't currently offer built-in compression support. -Use Response Compression Middleware when you're: +Use response compression middleware when you're: * Unable to use the following server-based compression technologies: * [IIS Dynamic Compression module](https://www.iis.net/overview/reliability/dynamiccachingandcompression) @@ -335,7 +335,7 @@ Usually, any response not natively compressed can benefit from response compress When a client can process compressed content, the client must inform the server of its capabilities by sending the `Accept-Encoding` header with the request. When a server sends compressed content, it must include information in the `Content-Encoding` header on how the compressed response is encoded. Content encoding designations supported by the middleware are shown in the following table. -| `Accept-Encoding` header values | Middleware Supported | Description | +| `Accept-Encoding` header values | Middleware supported | Description | | ------------------------------- | :------------------: | ----------- | | `br` | Yes (default) | [Brotli compressed data format](https://tools.ietf.org/html/rfc7932) | | `deflate` | No | [DEFLATE compressed data format](https://tools.ietf.org/html/rfc1951) | @@ -364,14 +364,14 @@ The headers involved in requesting, sending, caching, and receiving compressed c | `Content-Type` | Specifies the MIME type of the content. Every response should specify its `Content-Type`. The middleware checks this value to determine if the response should be compressed. The middleware specifies a set of [default MIME types](#review-the-mime-types) that it can encode, but you can replace or add MIME types. | | `Vary` | When sent by the server with a value of `Accept-Encoding` to clients and proxies, the `Vary` header indicates to the client or proxy that it should cache (vary) responses based on the value of the `Accept-Encoding` header of the request. The result of returning content with the `Vary: Accept-Encoding` header is that both compressed and uncompressed responses are cached separately. | -Explore the features of the Response Compression Middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples). The sample illustrates: +Explore the features of the response compression middleware with the [sample app](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples). The sample illustrates: * The compression of app responses using Gzip and custom compression providers. * How to add a MIME type to the default list of MIME types for compression. ## Configuration -The following code shows how to enable the Response Compression Middleware for default MIME types and compression providers ([Brotli](#brotli-compression-provider) and [Gzip](#gzip-compression-provider)): +The following code shows how to enable the response compression middleware for default MIME types and compression providers ([Brotli](#brotli-compression-provider) and [Gzip](#gzip-compression-provider)): ```csharp public class Startup @@ -511,7 +511,7 @@ The middleware specifies a default set of MIME types for compression: * `text/plain` * `text/xml` -Replace or append MIME types with the Response Compression Middleware options. Note that wildcard MIME types, such as `text/*` aren't supported. The sample app adds a MIME type for `image/svg+xml` and compresses and serves the ASP.NET Core banner image (*banner.svg*). +Replace or append MIME types with the response compression middleware options. Note that wildcard MIME types, such as `text/*` aren't supported. The sample app adds a MIME type for `image/svg+xml` and compresses and serves the ASP.NET Core banner image (*banner.svg*). [!code-csharp[](response-compression/samples/3.x/SampleApp/Startup.cs?name=snippet1&highlight=8-10)] @@ -521,7 +521,7 @@ Replace or append MIME types with the Response Compression Middleware options. N Compressed responses over secure connections can be controlled with the `EnableForHttps` option, which is disabled by default. Using compression with dynamically generated pages can lead to security problems such as the [CRIME](https://wikipedia.org/wiki/CRIME_(security_exploit)) and [BREACH](https://wikipedia.org/wiki/BREACH_(security_exploit)) attacks. -## Adding the Vary header +## Add the Vary header When compressing responses based on the `Accept-Encoding` header, there are potentially multiple compressed versions of the response and an uncompressed version. In order to instruct client and proxy caches that multiple versions exist and should be stored, the `Vary` header is added with an `Accept-Encoding` value. In ASP.NET Core 2.0 or later, the middleware adds the `Vary` header automatically when the response is compressed. @@ -535,12 +535,12 @@ If you have an active IIS Dynamic Compression Module configured at the server le ## Troubleshooting -Use a tool like [Fiddler](https://www.telerik.com/fiddler) or [Firefox Browser Developer](https://www.mozilla.org/firefox/developer/), which allow you to set the `Accept-Encoding` request header and study the response headers, size, and body. By default, Response Compression Middleware compresses responses that meet the following conditions: +Use a tool like [Fiddler](https://www.telerik.com/fiddler) or [Firefox Browser Developer](https://www.mozilla.org/firefox/developer/), which allow you to set the `Accept-Encoding` request header and study the response headers, size, and body. By default, response compression middleware compresses responses that meet the following conditions: * The `Accept-Encoding` header is present with a value of `br`, `gzip`, `*`, or custom encoding that matches a custom compression provider that you've established. The value must not be `identity` or have a quality value (qvalue, `q`) setting of 0 (zero). * The MIME type (`Content-Type`) must be set and must match a MIME type configured on the . * The request must not include the `Content-Range` header. -* The request must use insecure protocol (http), unless secure protocol (https) is configured in the Response Compression Middleware options. *Note the danger [described above](#risk) when enabling secure content compression.* +* The request must use insecure protocol (http), unless secure protocol (https) is configured in the response compression middleware options. *Note the danger [described above](#risk) when enabling secure content compression.* ## Additional resources diff --git a/aspnetcore/performance/response-compression/samples/2.x/SampleApp/README.md b/aspnetcore/performance/response-compression/samples/2.x/SampleApp/README.md index 77285478f25c..5086998c41c0 100644 --- a/aspnetcore/performance/response-compression/samples/2.x/SampleApp/README.md +++ b/aspnetcore/performance/response-compression/samples/2.x/SampleApp/README.md @@ -1,6 +1,6 @@ # Response compression sample application (ASP.NET Core 2.x) -This sample illustrates the use of ASP.NET Core 2.x Response Compression Middleware to compress HTTP responses. The sample demonstrates Gzip, Brotli, and custom compression providers for text and image responses and shows how to add a MIME type for compression. For the ASP.NET Core 1.x sample, see [Response compression sample application (ASP.NET Core 1.x)](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples/1.x). +This sample illustrates the use of ASP.NET Core 2.x response compression middleware to compress HTTP responses. The sample demonstrates Gzip, Brotli, and custom compression providers for text and image responses and shows how to add a MIME type for compression. For the ASP.NET Core 1.x sample, see [Response compression sample application (ASP.NET Core 1.x)](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples/1.x). ## Examples in this sample diff --git a/aspnetcore/performance/response-compression/samples/3.x/SampleApp/README.md b/aspnetcore/performance/response-compression/samples/3.x/SampleApp/README.md index c1419b71e72a..81ad95ec37e8 100644 --- a/aspnetcore/performance/response-compression/samples/3.x/SampleApp/README.md +++ b/aspnetcore/performance/response-compression/samples/3.x/SampleApp/README.md @@ -1,6 +1,6 @@ # Response compression sample application (ASP.NET Core 3.x) -This sample illustrates the use of ASP.NET Core 3.x Response Compression Middleware to compress HTTP responses. The sample demonstrates Gzip, Brotli, and custom compression providers for text and image responses and shows how to add a MIME type for compression. For the ASP.NET Core 2.x sample, see [Response compression sample application (ASP.NET Core 2.x)](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples/2.x). +This sample illustrates the use of ASP.NET Core 3.x response compression middleware to compress HTTP responses. The sample demonstrates Gzip, Brotli, and custom compression providers for text and image responses and shows how to add a MIME type for compression. For the ASP.NET Core 2.x sample, see [Response compression sample application (ASP.NET Core 2.x)](https://github.com/dotnet/AspNetCore.Docs/tree/main/aspnetcore/performance/response-compression/samples/2.x). ## Examples in this sample diff --git a/aspnetcore/release-notes/aspnetcore-1.1.md b/aspnetcore/release-notes/aspnetcore-1.1.md index 2c1eccd3ce98..7c9ea7f2cc28 100644 --- a/aspnetcore/release-notes/aspnetcore-1.1.md +++ b/aspnetcore/release-notes/aspnetcore-1.1.md @@ -11,8 +11,8 @@ uid: aspnetcore-1.1 ASP.NET Core 1.1 includes the following new features: -* [URL Rewriting Middleware](xref:fundamentals/url-rewriting) -* [Response Caching Middleware](xref:performance/caching/middleware) +* [URL rewriting middleware](xref:fundamentals/url-rewriting) +* [Response caching middleware](xref:performance/caching/middleware) * [View Components as Tag Helpers](xref:mvc/views/view-components#invoking-a-view-component-as-a-tag-helper) * [Middleware as MVC filters](xref:mvc/controllers/filters#using-middleware-in-the-filter-pipeline) * [Cookie-based TempData provider](xref:fundamentals/app-state#tempdata) diff --git a/aspnetcore/release-notes/aspnetcore-10/includes/blazor.md b/aspnetcore/release-notes/aspnetcore-10/includes/blazor.md index 15c5512a0224..1e7cc064f065 100644 --- a/aspnetcore/release-notes/aspnetcore-10/includes/blazor.md +++ b/aspnetcore/release-notes/aspnetcore-10/includes/blazor.md @@ -438,7 +438,7 @@ If the MSBuild property is used, code that relied on (described in the next section) is invoked by passing a page type to the `Router` component using the `NotFoundPage` parameter. The feature supports routing, works across Status Code Pages Re-execution Middleware, and is compatible even with non-Blazor scenarios. +Blazor now provides an improved way to display a "Not Found" page when navigating to a non-existent page. You can specify a page to render when (described in the next section) is invoked by passing a page type to the `Router` component using the `NotFoundPage` parameter. The feature supports routing, works across status code pages re-execution middleware, and is compatible even with non-Blazor scenarios. The [`NotFound` render fragment](xref:Microsoft.AspNetCore.Components.Routing.Router.NotFound%2A) (`...`) isn't supported in .NET 10 or later. @@ -466,16 +466,16 @@ The now includes a ). `DefaultNotFound` 404 content ("`Not found`" plain text) doesn't have a route, so it can't be used during streaming rendering. +Streaming rendering can only render components that have a route, such as a [`NotFoundPage` assignment](#blazor-router-has-a-notfoundpage-parameter) (`NotFoundPage="..."`) or a [status code pages re-execution middleware page assignment](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) (). `DefaultNotFound` 404 content ("`Not found`" plain text) doesn't have a route, so it can't be used during streaming rendering. content rendering uses the following, regardless if the response has started or not (in order): * If is set, render the contents of the assigned page. * If `Router.NotFoundPage` is set, render the assigned page. -* A Status Code Pages Re-execution Middleware page, if configured. +* A status code pages re-execution middleware page, if configured. * No action if none of the preceding approaches are adopted. -[Status Code Pages Re-execution Middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. +[Status code pages re-execution middleware](xref:fundamentals/error-handling#usestatuscodepageswithreexecute) with takes precedence for browser-based address routing problems, such as an incorrect URL typed into the browser's address bar or selecting a link that has no endpoint in the app. You can use the event for notifications when is invoked. diff --git a/aspnetcore/release-notes/aspnetcore-2.1.md b/aspnetcore/release-notes/aspnetcore-2.1.md index 7e73323786a6..35f18b77e25a 100644 --- a/aspnetcore/release-notes/aspnetcore-2.1.md +++ b/aspnetcore/release-notes/aspnetcore-2.1.md @@ -60,7 +60,7 @@ Run `dotnet dev-certs https --trust` to trust the certificate. Web apps typically need to listen on both HTTP and HTTPS, but then redirect all HTTP traffic to HTTPS. In 2.1, specialized HTTPS redirection middleware that intelligently redirects based on the presence of configuration or bound server ports has been introduced. -Use of HTTPS can be further enforced using [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts). HSTS instructs browsers to always access the site via HTTPS. ASP.NET Core 2.1 adds HSTS middleware that supports options for max age, subdomains, and the HSTS preload list. +Use of HTTPS can be further enforced using [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol). HSTS instructs browsers to always access the site via HTTPS. ASP.NET Core 2.1 adds HSTS middleware that supports options for max age, subdomains, and the HSTS preload list. ### Configuration for production diff --git a/aspnetcore/release-notes/aspnetcore-2.2.md b/aspnetcore/release-notes/aspnetcore-2.2.md index 617e93601b91..ddd1c8f53d0c 100644 --- a/aspnetcore/release-notes/aspnetcore-2.2.md +++ b/aspnetcore/release-notes/aspnetcore-2.2.md @@ -81,15 +81,15 @@ For more information, see [ASP.NET Core SignalR Java client](../signalr/java-cli ## CORS improvements -In earlier versions of ASP.NET Core, CORS Middleware allows `Accept`, `Accept-Language`, `Content-Language`, and `Origin` headers to be sent regardless of the values configured in `CorsPolicy.Headers`. In 2.2, a CORS Middleware policy match is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. +In earlier versions of ASP.NET Core, CORS middleware allows `Accept`, `Accept-Language`, `Content-Language`, and `Origin` headers to be sent regardless of the values configured in `CorsPolicy.Headers`. In 2.2, a CORS middleware policy match is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. -For more information, see [CORS Middleware](xref:security/cors?view=aspnetcore-2.2#set-the-allowed-request-headers). +For more information, see [CORS middleware](xref:security/cors?view=aspnetcore-2.2#set-the-allowed-request-headers). ## Response compression ASP.NET Core 2.2 can compress responses with the [Brotli compression format](https://tools.ietf.org/html/rfc7932). -For more information, see [Response Compression Middleware supports Brotli compression](xref:performance/response-compression?view=aspnetcore-2.2#brotli-compression-provider). +For more information, see [response compression middleware supports Brotli compression](xref:performance/response-compression?view=aspnetcore-2.2#brotli-compression-provider). ## Project templates diff --git a/aspnetcore/release-notes/aspnetcore-3.0.md b/aspnetcore/release-notes/aspnetcore-3.0.md index a52d6b46d3f7..b3b4ef029f71 100644 --- a/aspnetcore/release-notes/aspnetcore-3.0.md +++ b/aspnetcore/release-notes/aspnetcore-3.0.md @@ -416,7 +416,7 @@ All services can still be injected directly as arguments to the `Startup.Configu ## Kestrel * Kestrel configuration has been updated for the migration to the Generic Host. In 3.0, Kestrel is configured on the web host builder provided by `ConfigureWebHostDefaults`. -* Connection Adapters have been removed from Kestrel and replaced with Connection Middleware, which is similar to HTTP Middleware in the ASP.NET Core pipeline but for lower-level connections. +* Connection Adapters have been removed from Kestrel and replaced with connection middleware, which is similar to HTTP middleware in the ASP.NET Core pipeline but for lower-level connections. * The Kestrel transport layer has been exposed as a public interface in `Connections.Abstractions`. * Ambiguity between headers and trailers has been resolved by moving trailing headers to a new collection. * Synchronous I/O APIs, such as `HttpRequest.Body.Read`, are a common source of thread starvation leading to app crashes. In 3.0, `AllowSynchronousIO` is disabled by default. @@ -489,11 +489,11 @@ For more information, see: * * -## Forwarded Headers Middleware improvements +## Forwarded headers middleware improvements In previous versions of ASP.NET Core, calling and were problematic when deployed to an Azure Linux or behind any reverse proxy other than IIS. The fix for previous versions is documented in [Forward the scheme for Linux and non-IIS reverse proxies](xref:host-and-deploy/proxy-load-balancer#forward-the-scheme-for-linux-and-non-iis-reverse-proxies). -This scenario is fixed in ASP.NET Core 3.0. The host enables the [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-options) when the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` environment variable is set to `true`. `ASPNETCORE_FORWARDEDHEADERS_ENABLED` is set to `true` in our container images. +This scenario is fixed in ASP.NET Core 3.0. The host enables the [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer#forwarded-headers-middleware-options) when the `ASPNETCORE_FORWARDEDHEADERS_ENABLED` environment variable is set to `true`. `ASPNETCORE_FORWARDEDHEADERS_ENABLED` is set to `true` in our container images. ## Performance improvements diff --git a/aspnetcore/release-notes/aspnetcore-5.0.md b/aspnetcore/release-notes/aspnetcore-5.0.md index f37f2e8ec496..a033e2a158d4 100644 --- a/aspnetcore/release-notes/aspnetcore-5.0.md +++ b/aspnetcore/release-notes/aspnetcore-5.0.md @@ -357,7 +357,7 @@ The `AllowAnonymous` extension method allows anonymous access to an endpoint: ### Custom handling of authorization failures -Custom handling of authorization failures is now easier with the new interface that is invoked by the [Authorization Middleware (`UseAuthorization`)](xref:Microsoft.AspNetCore.Builder.AuthorizationAppBuilderExtensions.UseAuthorization%2A). The default implementation remains the same, but a custom handler can be registered with dependency injection, which allows custom HTTP responses based on an authorization failure. See [`SampleAuthorizationMiddlewareResultHandler.cs` (reference source)](https://github.com/dotnet/aspnetcore/blob/main/src/Security/samples/CustomAuthorizationFailureResponse/Authorization/SampleAuthorizationMiddlewareResultHandler.cs) for a demonstration of `IAuthorizationMiddlewareResultHandler`. +Custom handling of authorization failures is now easier with the new interface that is invoked by the [authorization middleware (`UseAuthorization`)](xref:Microsoft.AspNetCore.Builder.AuthorizationAppBuilderExtensions.UseAuthorization%2A). The default implementation remains the same, but a custom handler can be registered with dependency injection, which allows custom HTTP responses based on an authorization failure. See [`SampleAuthorizationMiddlewareResultHandler.cs` (reference source)](https://github.com/dotnet/aspnetcore/blob/main/src/Security/samples/CustomAuthorizationFailureResponse/Authorization/SampleAuthorizationMiddlewareResultHandler.cs) for a demonstration of `IAuthorizationMiddlewareResultHandler`. [!INCLUDE[](~/includes/aspnetcore-repo-ref-source-links.md)] diff --git a/aspnetcore/release-notes/aspnetcore-6.0.md b/aspnetcore/release-notes/aspnetcore-6.0.md index c61d6daca6be..a20f12be9b04 100644 --- a/aspnetcore/release-notes/aspnetcore-6.0.md +++ b/aspnetcore/release-notes/aspnetcore-6.0.md @@ -488,7 +488,7 @@ The following changes were made to both `appsettings.json` and `appsettings.Deve The change from `"Microsoft": "Warning"` to `"Microsoft.AspNetCore": "Warning"` results in logging all informational messages from the `Microsoft` namespace ***except*** `Microsoft.AspNetCore`. For example, `Microsoft.EntityFrameworkCore` is now logged at the informational level. -### Developer exception page Middleware added automatically +### Developer exception page middleware added automatically In the [development environment](xref:fundamentals/environments), the is added by default. It's no longer necessary to add the following code to web UI apps: diff --git a/aspnetcore/release-notes/aspnetcore-8.0.md b/aspnetcore/release-notes/aspnetcore-8.0.md index cb466308b854..95388c2dcb09 100644 --- a/aspnetcore/release-notes/aspnetcore-8.0.md +++ b/aspnetcore/release-notes/aspnetcore-8.0.md @@ -157,7 +157,7 @@ For more information, see property. +When a user authenticates using their username and password they're issued a token containing an authentication ticket. The token can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed with the cookie authentication middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. ### Token-based authentication @@ -628,7 +628,7 @@ The antiforgery token is only validated if: * The HTTP method associated with the endpoint is a relevant [HTTP method](https://developer.mozilla.org/docs/Web/HTTP/Methods) of type POST, PUT, or PATCH. * The request is associated with a valid endpoint. -Antiforgery Middleware doesn't short-circuit the request pipeline. Endpoint code always runs, even if token validation fails. To observe the outcome of the token validation, resolve the from and inspect its property or the property for failure details. This approach is useful when endpoints require custom handling for failed antiforgery validation. +Antiforgery middleware doesn't short-circuit the request pipeline. Endpoint code always runs, even if token validation fails. To observe the outcome of the token validation, resolve the from and inspect its property or the property for failure details. This approach is useful when endpoints require custom handling for failed antiforgery validation. ***Note:*** When enabled manually, the antiforgery middleware must run after the authentication and authorization middleware to prevent reading form data when the user is unauthenticated. @@ -750,7 +750,7 @@ CSRF attacks are possible against web apps that use cookies for authentication b However, CSRF attacks aren't limited to exploiting cookies. For example, Basic and Digest authentication are also vulnerable. After a user signs in with Basic or Digest authentication, the browser automatically sends the credentials until the session ends. -In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core Session Middleware](xref:fundamentals/app-state). +In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core session middleware](xref:fundamentals/app-state). Users can protect against CSRF vulnerabilities by taking precautions: @@ -765,7 +765,7 @@ Cookie-based authentication is a popular form of authentication. Token-based aut ### Cookie-based authentication -When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the Cookie Authentication Middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. +When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the cookie authentication middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. ### Token-based authentication @@ -1040,7 +1040,7 @@ CSRF attacks are possible against web apps that use cookies for authentication b However, CSRF attacks aren't limited to exploiting cookies. For example, Basic and Digest authentication are also vulnerable. After a user signs in with Basic or Digest authentication, the browser automatically sends the credentials until the session ends. -In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core Session Middleware](xref:fundamentals/app-state). +In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core session middleware](xref:fundamentals/app-state). Users can protect against CSRF vulnerabilities by taking precautions: @@ -1055,7 +1055,7 @@ Cookie-based authentication is a popular form of authentication. Token-based aut ### Cookie-based authentication -When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the Cookie Authentication Middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. +When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the cookie authentication middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. ### Token-based authentication @@ -1306,7 +1306,7 @@ CSRF attacks are possible against web apps that use cookies for authentication b However, CSRF attacks aren't limited to exploiting cookies. For example, Basic and Digest authentication are also vulnerable. After a user signs in with Basic or Digest authentication, the browser automatically sends the credentials until the session ends. -In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core Session Middleware](xref:fundamentals/app-state). +In this context, *session* refers to the client-side session during which the user is authenticated. It's unrelated to server-side sessions or [ASP.NET Core session middleware](xref:fundamentals/app-state). Users can protect against CSRF vulnerabilities by taking precautions: @@ -1321,7 +1321,7 @@ Cookie-based authentication is a popular form of authentication. Token-based aut ### Cookie-based authentication -When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the Cookie Authentication Middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. +When a user authenticates using their username and password, they're issued a token, containing an authentication ticket that can be used for authentication and authorization. The token is stored as a cookie that's sent with every request the client makes. Generating and validating this cookie is performed by the cookie authentication middleware. The [middleware](xref:fundamentals/middleware/index) serializes a user principal into an encrypted cookie. On subsequent requests, the middleware validates the cookie, recreates the principal, and assigns the principal to the property. ### Token-based authentication diff --git a/aspnetcore/security/authentication/certauth.md b/aspnetcore/security/authentication/certauth.md index 17aa696b6690..3f4aea892650 100644 --- a/aspnetcore/security/authentication/certauth.md +++ b/aspnetcore/security/authentication/certauth.md @@ -158,10 +158,10 @@ For more information on how to configure the certificate forwarding middleware, ### Certificate authentication in Azure Web Apps -No forwarding configuration is required for Azure. The Certificate Forwarding Middleware sets up the configuration. +No forwarding configuration is required for Azure. The certificate-forwarding middleware sets up the configuration. > [!NOTE] -> Certificate Forwarding Middleware is required for this scenario. +> Certificate-forwarding middleware is required for this scenario. For more information, see [Use TLS/SSL certificates in your app code (Azure documentation)](/azure/app-service/configure-ssl-certificate-in-code). @@ -636,10 +636,10 @@ See the [host and deploy documentation](xref:host-and-deploy/proxy-load-balancer ### Use certificate authentication in Azure Web Apps -No forwarding configuration is required for Azure. Forwarding configuration is set up by the Certificate Forwarding Middleware. +No forwarding configuration is required for Azure. Forwarding configuration is set up by the certificate-forwarding middleware. > [!NOTE] -> Certificate Forwarding Middleware is required for this scenario. +> Certificate-forwarding middleware is required for this scenario. For more information, see [Use a TLS/SSL certificate in your code in Azure App Service (Azure documentation)](/azure/app-service/configure-ssl-certificate-in-code). @@ -1294,10 +1294,10 @@ See the [host and deploy documentation](xref:host-and-deploy/proxy-load-balancer ### Use certificate authentication in Azure Web Apps -No forwarding configuration is required for Azure. Forwarding configuration is set up by the Certificate Forwarding Middleware. +No forwarding configuration is required for Azure. Forwarding configuration is set up by the certificate-forwarding middleware. > [!NOTE] -> Certificate Forwarding Middleware is required for this scenario. +> Certificate-forwarding middleware is required for this scenario. For more information, see [Use a TLS/SSL certificate in your code in Azure App Service (Azure documentation)](/azure/app-service/configure-ssl-certificate-in-code). diff --git a/aspnetcore/security/authentication/cookie.md b/aspnetcore/security/authentication/cookie.md index 435924dd7770..f7fd9b6458bb 100644 --- a/aspnetcore/security/authentication/cookie.md +++ b/aspnetcore/security/authentication/cookie.md @@ -27,8 +27,8 @@ For demonstration purposes in the sample app, the user account for the hypotheti :::moniker range=">= aspnetcore-6.0" ## Add cookie authentication -* Add the Authentication Middleware services with the and methods. -* Call and to set the `HttpContext.User` property and run the Authorization Middleware for requests. `UseAuthentication` and `UseAuthorization` must be called before `Map` methods such as and +* Add the authentication middleware services with the and methods. +* Call and to set the `HttpContext.User` property and run the authorization middleware for requests. `UseAuthentication` and `UseAuthorization` must be called before `Map` methods such as and [!code-csharp[](cookie/samples/6.x/CookieSample/Program.cs?name=snippet1&highlight=8-9,24-28)] @@ -44,20 +44,20 @@ Configure enables cookie policy capabilities. Middleware is processed in the order it's added, and Cookie Policy Middleware should be added before cookie authentication middleware. +[Cookie policy middleware (GitHub Source)](https://github.com/dotnet/aspnetcore/blob/main/src/Security/CookiePolicy/src/CookiePolicyMiddleware.cs) enables cookie policy capabilities. Middleware is processed in the order it's added, and cookie policy middleware should be added before cookie authentication middleware. -Use provided to the Cookie Policy Middleware to control global characteristics of cookie processing and hook into cookie processing handlers when cookies are appended or deleted. +Use provided to the cookie policy middleware to control global characteristics of cookie processing and hook into cookie processing handlers when cookies are appended or deleted. The default value is `SameSiteMode.Lax` to permit OAuth2 authentication. To strictly enforce a same-site policy of `SameSiteMode.Strict`, set the `MinimumSameSitePolicy`. Although this setting breaks OAuth2 and other cross-origin authentication schemes, it elevates the level of cookie security for other types of apps that don't rely on cross-origin request processing. -The following example shows how to configure cookie authentication with Cookie Policy Middleware: +The following example shows how to configure cookie authentication with cookie policy middleware: :::code language="csharp" source="cookie/snippets/6.0/Program.cs" id="snippet_policy" highlight="3-5,9"::: -The Cookie Policy Middleware setting for `MinimumSameSitePolicy` can affect the setting of `Cookie.SameSite` in `CookieAuthenticationOptions` settings according to the matrix below. +The cookie policy middleware setting for `MinimumSameSitePolicy` can affect the setting of `Cookie.SameSite` in `CookieAuthenticationOptions` settings according to the matrix below. | MinimumSameSitePolicy | Cookie.SameSite | Resultant Cookie.SameSite setting | | --------------------- | --------------- | --------------------------------- | @@ -187,7 +187,7 @@ For demonstration purposes in the sample app, the user account for the hypotheti ## Configuration -In the `Startup.ConfigureServices` method, create the Authentication Middleware services with the and methods: +In the `Startup.ConfigureServices` method, create the authentication middleware services with the and methods: [!code-csharp[](cookie/samples/3.x/CookieSample/Startup.cs?name=snippet1)] @@ -197,7 +197,7 @@ The app's authentication scheme is different from the app's cookie authenticatio The authentication cookie's property is set to `true` by default. Authentication cookies are allowed when a site visitor hasn't consented to data collection. For more information, see . -In `Startup.Configure`, call `UseAuthentication` and `UseAuthorization` to set the `HttpContext.User` property and run Authorization Middleware for requests. Call the `UseAuthentication` and `UseAuthorization` methods before calling `UseEndpoints`: +In `Startup.Configure`, call `UseAuthentication` and `UseAuthorization` to set the `HttpContext.User` property and run authorization middleware for requests. Call the `UseAuthentication` and `UseAuthorization` methods before calling `UseEndpoints`: [!code-csharp[](cookie/samples/3.x/CookieSample/Startup.cs?name=snippet2)] @@ -213,19 +213,19 @@ services.AddAuthentication(CookieAuthenticationDefaults.AuthenticationScheme) }); ``` -## Cookie Policy Middleware +## Cookie policy middleware -[Cookie Policy Middleware](xref:Microsoft.AspNetCore.CookiePolicy.CookiePolicyMiddleware) enables cookie policy capabilities. Adding the middleware to the app processing pipeline is order sensitive—it only affects downstream components registered in the pipeline, and Cookie Policy Middleware should be added before cookie authentication middleware. +[Cookie policy middleware](xref:Microsoft.AspNetCore.CookiePolicy.CookiePolicyMiddleware) enables cookie policy capabilities. Adding the middleware to the app processing pipeline is order sensitive—it only affects downstream components registered in the pipeline, and cookie policy middleware should be added before cookie authentication middleware. -Use provided to the Cookie Policy Middleware to control global characteristics of cookie processing and hook into cookie processing handlers when cookies are appended or deleted. +Use provided to the cookie policy middleware to control global characteristics of cookie processing and hook into cookie processing handlers when cookies are appended or deleted. The default value is `SameSiteMode.Lax` to permit OAuth2 authentication. To strictly enforce a same-site policy of `SameSiteMode.Strict`, set the `MinimumSameSitePolicy`. Although this setting breaks OAuth2 and other cross-origin authentication schemes, it elevates the level of cookie security for other types of apps that don't rely on cross-origin request processing. -The following example shows how to configure cookie authentication with Cookie Policy Middleware: +The following example shows how to configure cookie authentication with cookie policy middleware: :::code language="csharp" source="cookie/snippets/3.x/Startup.cs" id="snippet_policy" highlight="3-5,9"::: -The Cookie Policy Middleware setting for `MinimumSameSitePolicy` can affect the setting of `Cookie.SameSite` in `CookieAuthenticationOptions` settings according to the matrix below. +The cookie policy middleware setting for `MinimumSameSitePolicy` can affect the setting of `Cookie.SameSite` in `CookieAuthenticationOptions` settings according to the matrix below. | MinimumSameSitePolicy | Cookie.SameSite | Resultant Cookie.SameSite setting | | --------------------- | --------------- | --------------------------------- | diff --git a/aspnetcore/security/authentication/passkeys/index.md b/aspnetcore/security/authentication/passkeys/index.md index a786afb6dac9..501d38cf5216 100644 --- a/aspnetcore/security/authentication/passkeys/index.md +++ b/aspnetcore/security/authentication/passkeys/index.md @@ -106,7 +106,7 @@ For example: All passkey operations require HTTPS. The implementation stores authentication data in encrypted and signed cookies that could be intercepted over unencrypted connections. -**Requirement**: Always use HTTPS in production. Configure [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) to prevent protocol downgrade attacks. +**Requirement**: Always use HTTPS in production. Configure [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) to prevent protocol downgrade attacks. ### Account recovery diff --git a/aspnetcore/security/authentication/social/additional-claims.md b/aspnetcore/security/authentication/social/additional-claims.md index 265a28d54184..36a9da377c94 100644 --- a/aspnetcore/security/authentication/social/additional-claims.md +++ b/aspnetcore/security/authentication/social/additional-claims.md @@ -74,7 +74,7 @@ By default, a user's claims are stored in the authentication cookie. If the auth If a large amount of user data is required for processing user requests: * Limit the number and size of user claims for request processing to only what the app requires. -* Use a custom for the Cookie Authentication Middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. +* Use a custom for the cookie authentication middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. ## Save the access token @@ -242,7 +242,7 @@ By default, a user's claims are stored in the authentication cookie. If the auth If a large amount of user data is required for processing user requests: * Limit the number and size of user claims for request processing to only what the app requires. -* Use a custom for the Cookie Authentication Middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. +* Use a custom for the cookie authentication middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. ## Save the access token @@ -510,7 +510,7 @@ By default, a user's claims are stored in the authentication cookie. If the auth If a large amount of user data is required for processing user requests: * Limit the number and size of user claims for request processing to only what the app requires. -* Use a custom for the Cookie Authentication Middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. +* Use a custom for the cookie authentication middleware's to store identity across requests. Preserve large quantities of identity information on the server while only sending a small session identifier key to the client. ## Save the access token diff --git a/aspnetcore/security/authentication/social/includes/forwarded-headers-middleware.md b/aspnetcore/security/authentication/social/includes/forwarded-headers-middleware.md index ace9f7647a77..b65f7143c54b 100644 --- a/aspnetcore/security/authentication/social/includes/forwarded-headers-middleware.md +++ b/aspnetcore/security/authentication/social/includes/forwarded-headers-middleware.md @@ -4,6 +4,6 @@ If the app is deployed behind a proxy server or load balancer, some of the origi The scheme is used in link generation that affects the authentication flow with external providers. Losing the secure scheme (`https`) results in the app generating incorrect insecure redirect URLs. -Use Forwarded Headers Middleware to make the original request information available to the app for request processing. +Use forwarded headers middleware to make the original request information available to the app for request processing. For more information, see . diff --git a/aspnetcore/security/authentication/social/social-without-identity.md b/aspnetcore/security/authentication/social/social-without-identity.md index 222378656c5f..c092625d81ea 100644 --- a/aspnetcore/security/authentication/social/social-without-identity.md +++ b/aspnetcore/security/authentication/social/social-without-identity.md @@ -40,7 +40,7 @@ The call to ("Cookies") configures the app to use Cookies as the default scheme for these extension methods. Setting the app's to `Google.Apis.Auth.AspNetCore3.GoogleOpenIdConnectDefaults.AuthenticationScheme` ("`GoogleOpenIdConnect`") configures the app to use Google as the default scheme for calls to `ChallengeAsync`. `DefaultChallengeScheme` overrides `DefaultScheme`. See for more properties that override `DefaultScheme` when set. -In `Program.cs`, call and . This middleware combination sets the property and runs the Authorization Middleware for requests: +In `Program.cs`, call and . This middleware combination sets the property and runs the authorization middleware for requests: :::code language="csharp" source="social-without-identity/samples/6.x/SocialWithoutIdentitySample/Program.cs" id="snippet_UseAuthentication" highlight="4-5"::: @@ -108,7 +108,7 @@ The call to ("Cookies") configures the app to use Cookies as the default scheme for these extension methods. Setting the app's to ("Google") configures the app to use Google as the default scheme for calls to `ChallengeAsync`. `DefaultChallengeScheme` overrides `DefaultScheme`. See for more properties that override `DefaultScheme` when set. -In `Startup.Configure`, call and between calling and . This middleware combination sets the property and runs the Authorization Middleware for requests: +In `Startup.Configure`, call and between calling and . This middleware combination sets the property and runs the authorization middleware for requests: :::code language="csharp" source="social-without-identity/samples_snapshot/3.x/Startup.cs" id="snippet_UseAuthentication" highlight="3-4"::: diff --git a/aspnetcore/security/authentication/windowsauth.md b/aspnetcore/security/authentication/windowsauth.md index 5106c9c5c66c..96ce106cfb27 100644 --- a/aspnetcore/security/authentication/windowsauth.md +++ b/aspnetcore/security/authentication/windowsauth.md @@ -137,7 +137,7 @@ If you haven't already done so, enable IIS to host ASP.NET Core apps. For more i Enable the IIS Role Service for Windows Authentication. For more information, see [Enable Windows Authentication in IIS Role Services (see Step 2)](xref:host-and-deploy/iis/advanced#iis-configuration). -[IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) is configured to automatically authenticate requests by default. For more information, see [Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication)](xref:host-and-deploy/iis/index#iis-options). +[IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) is configured to automatically authenticate requests by default. For more information, see [Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication)](xref:host-and-deploy/iis/index#iis-options). The ASP.NET Core Module is configured to forward the Windows Authentication token to the app by default. For more information, see [ASP.NET Core Module configuration reference: Attributes of the aspNetCore element](xref:host-and-deploy/aspnet-core-module#attributes-of-the-aspnetcore-element). @@ -290,7 +290,7 @@ When Windows Authentication is enabled and anonymous access is disabled, the [`[ When both Windows Authentication and anonymous access are enabled, use the [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) and [`[AllowAnonymous]`](xref:Microsoft.AspNetCore.Authorization.AllowAnonymousAttribute) attributes. The [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) attribute allows you to secure endpoints of the app which require authentication. The [`[AllowAnonymous]`](xref:Microsoft.AspNetCore.Authorization.AllowAnonymousAttribute) attribute overrides the [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) attribute in apps that allow anonymous access. For attribute usage details, see . > [!NOTE] -> By default, users who lack authorization to access a page are presented with an empty HTTP 403 response. The [StatusCodePages Middleware](xref:fundamentals/error-handling#usestatuscodepages) can be configured to provide users with a better "Access Denied" experience. +> By default, users who lack authorization to access a page are presented with an empty HTTP 403 response. The [status code pages middleware](xref:fundamentals/error-handling#usestatuscodepages) can be configured to provide users with a better "Access Denied" experience. ## Impersonation @@ -445,7 +445,7 @@ If you haven't already done so, enable IIS to host ASP.NET Core apps. For more i Enable the IIS Role Service for Windows Authentication. For more information, see [Enable Windows Authentication in IIS Role Services (see Step 2)](xref:host-and-deploy/iis/index#iis-configuration). -[IIS Integration Middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) is configured to automatically authenticate requests by default. For more information, see [Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication)](xref:host-and-deploy/iis/index#iis-options). +[IIS integration middleware](xref:host-and-deploy/iis/index#enable-the-iisintegration-components) is configured to automatically authenticate requests by default. For more information, see [Host ASP.NET Core on Windows with IIS: IIS options (AutomaticAuthentication)](xref:host-and-deploy/iis/index#iis-options). The ASP.NET Core Module is configured to forward the Windows Authentication token to the app by default. For more information, see [ASP.NET Core Module configuration reference: Attributes of the aspNetCore element](xref:host-and-deploy/aspnet-core-module#attributes-of-the-aspnetcore-element). @@ -495,7 +495,7 @@ services.AddAuthentication(NegotiateDefaults.AuthenticationScheme) .AddNegotiate(); ``` -Add Authentication Middleware by calling in `Startup.Configure`: +Add authentication middleware by calling in `Startup.Configure`: ```csharp app.UseAuthentication(); @@ -596,7 +596,7 @@ When Windows Authentication is enabled and anonymous access is disabled, the [`[ When both Windows Authentication and anonymous access are enabled, use the [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) and [`[AllowAnonymous]`](xref:Microsoft.AspNetCore.Authorization.AllowAnonymousAttribute) attributes. The [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) attribute allows you to secure endpoints of the app which require authentication. The [`[AllowAnonymous]`](xref:Microsoft.AspNetCore.Authorization.AllowAnonymousAttribute) attribute overrides the [`[Authorize]`](xref:Microsoft.AspNetCore.Authorization.AuthorizeAttribute) attribute in apps that allow anonymous access. For attribute usage details, see . > [!NOTE] -> By default, users who lack authorization to access a page are presented with an empty HTTP 403 response. The [StatusCodePages Middleware](xref:fundamentals/error-handling#usestatuscodepages) can be configured to provide users with a better "Access Denied" experience. +> By default, users who lack authorization to access a page are presented with an empty HTTP 403 response. The [status code pages middleware](xref:fundamentals/error-handling#usestatuscodepages) can be configured to provide users with a better "Access Denied" experience. ## Impersonation diff --git a/aspnetcore/security/authorization/iauthorizationpolicyprovider.md b/aspnetcore/security/authorization/iauthorizationpolicyprovider.md index e4151e1f12b4..47a8cc097f10 100644 --- a/aspnetcore/security/authorization/iauthorizationpolicyprovider.md +++ b/aspnetcore/security/authorization/iauthorizationpolicyprovider.md @@ -41,7 +41,7 @@ The `IAuthorizationPolicyProvider` interface contains three APIs: * The method returns an authorization policy for a given name. * The method returns the default authorization policy, which is the policy used for `[Authorize]` attributes without a policy specified. -* The method returns the fallback authorization policy, which is the policy used by the Authorization Middleware when no policy is specified. +* The method returns the fallback authorization policy, which is the policy used by the authorization middleware when no policy is specified. By implementing these APIs, you can customize how authorization policies are provided. @@ -167,7 +167,7 @@ As with all aspects of a custom `IAuthorizationPolicyProvider`, you can make cus ## Fallback policy -A custom `IAuthorizationPolicyProvider` can optionally implement the `GetFallbackPolicyAsync` method to provide a policy to use when [combining policies](xref:Microsoft.AspNetCore.Authorization.AuthorizationPolicy.Combine%2A) and when no policies are specified. If the `GetFallbackPolicyAsync` method returns a non-null policy, the returned policy is used by the Authorization Middleware when no policies are specified for the request. +A custom `IAuthorizationPolicyProvider` can optionally implement the `GetFallbackPolicyAsync` method to provide a policy to use when [combining policies](xref:Microsoft.AspNetCore.Authorization.AuthorizationPolicy.Combine%2A) and when no policies are specified. If the `GetFallbackPolicyAsync` method returns a non-null policy, the returned policy is used by the authorization middleware when no policies are specified for the request. If no fallback policy is required, the provider can return `null` or defer to the fallback provider: diff --git a/aspnetcore/security/authorization/policies.md b/aspnetcore/security/authorization/policies.md index 29008a4951a7..0c6ae279062f 100644 --- a/aspnetcore/security/authorization/policies.md +++ b/aspnetcore/security/authorization/policies.md @@ -230,7 +230,7 @@ For example, the previous `BadgeEntryHandler` could be rewritten as follows: The `HandleRequirementAsync` method has two parameters: an `AuthorizationHandlerContext` and the `TRequirement` being handled. Frameworks such as MVC or SignalR are free to add any object to the `Resource` property on the `AuthorizationHandlerContext` to pass extra information. -When using endpoint routing, authorization is typically handled by the Authorization Middleware. In this case, the `Resource` property is an instance of . The context can be used to access the current endpoint, which can be used to probe the underlying resource to which you're routing. For example: +When using endpoint routing, authorization is typically handled by the authorization middleware. In this case, the `Resource` property is an instance of . The context can be used to access the current endpoint, which can be used to probe the underlying resource to which you're routing. For example: ```csharp if (context.Resource is HttpContext httpContext) diff --git a/aspnetcore/security/authorization/policies/includes/policies5.md b/aspnetcore/security/authorization/policies/includes/policies5.md index 7f25640e8cf2..d64cd7cbde3e 100644 --- a/aspnetcore/security/authorization/policies/includes/policies5.md +++ b/aspnetcore/security/authorization/policies/includes/policies5.md @@ -214,7 +214,7 @@ For example, the previous `BadgeEntryHandler` could be rewritten as follows: The `HandleRequirementAsync` method you implement in an authorization handler has two parameters: an `AuthorizationHandlerContext` and the `TRequirement` you are handling. Frameworks such as MVC or SignalR are free to add any object to the `Resource` property on the `AuthorizationHandlerContext` to pass extra information. -When using endpoint routing, authorization is typically handled by the Authorization Middleware. In this case, the `Resource` property is an instance of . The context can be used to access the current endpoint, which can be used to probe the underlying resource to which you're routing. For example: +When using endpoint routing, authorization is typically handled by the authorization middleware. In this case, the `Resource` property is an instance of . The context can be used to access the current endpoint, which can be used to probe the underlying resource to which you're routing. For example: ```csharp if (context.Resource is HttpContext httpContext) diff --git a/aspnetcore/security/cookie-sharing.md b/aspnetcore/security/cookie-sharing.md index 1b75a0642562..c4a123e63cdc 100644 --- a/aspnetcore/security/cookie-sharing.md +++ b/aspnetcore/security/cookie-sharing.md @@ -24,7 +24,7 @@ In the examples that follow: * `Identity.Application` is used as the authentication scheme. Whatever scheme is used, it must be used consistently *within and across* the shared cookie apps either as the default scheme or by explicitly setting it. The scheme is used when encrypting and decrypting cookies, so a consistent scheme must be used across apps. * A common [data protection key](xref:security/data-protection/implementation/key-management) storage location is used. * In ASP.NET Core apps, is used to set the key storage location. - * In .NET Framework apps, Cookie Authentication Middleware uses an implementation of . `DataProtectionProvider` provides data protection services for the encryption and decryption of authentication cookie payload data. The `DataProtectionProvider` instance is isolated from the data protection system used by other parts of the app. [DataProtectionProvider.Create(System.IO.DirectoryInfo, Action\)](xref:Microsoft.AspNetCore.DataProtection.DataProtectionProvider.Create*) accepts a to specify the location for data protection key storage. + * In .NET Framework apps, cookie authentication middleware uses an implementation of . `DataProtectionProvider` provides data protection services for the encryption and decryption of authentication cookie payload data. The `DataProtectionProvider` instance is isolated from the data protection system used by other parts of the app. [DataProtectionProvider.Create(System.IO.DirectoryInfo, Action\)](xref:Microsoft.AspNetCore.DataProtection.DataProtectionProvider.Create*) accepts a to specify the location for data protection key storage. * `DataProtectionProvider` requires the [Microsoft.AspNetCore.DataProtection.Extensions](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.Extensions/) NuGet package: * In .NET Framework apps, add a package reference to [Microsoft.AspNetCore.DataProtection.Extensions](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.Extensions/). * sets the common app name. @@ -83,12 +83,12 @@ When the Identity schema is different among apps, usually because apps are using ## Share authentication cookies between ASP.NET 4.x and ASP.NET Core apps -ASP.NET 4.x apps that use Microsoft.Owin Cookie Authentication Middleware can be configured to generate authentication cookies that are compatible with the ASP.NET Core Cookie Authentication Middleware. This can be useful if a web application consists of both ASP.NET 4.x apps and ASP.NET Core apps that must share a single sign-on experience. A specific example of such a scenario is [incrementally migrating](xref:migration/fx-to-core/index) a web app from ASP.NET to ASP.NET Core. In such scenarios, it's common for some parts of an app to be served by the original ASP.NET app while others are served by the new ASP.NET Core app. Users should only have to sign in once, though. This can be accomplished by either of the following approaches: +ASP.NET 4.x apps that use Microsoft.Owin cookie authentication middleware can be configured to generate authentication cookies that are compatible with the ASP.NET Core cookie authentication middleware. This can be useful if a web application consists of both ASP.NET 4.x apps and ASP.NET Core apps that must share a single sign-on experience. A specific example of such a scenario is [incrementally migrating](xref:migration/fx-to-core/index) a web app from ASP.NET to ASP.NET Core. In such scenarios, it's common for some parts of an app to be served by the original ASP.NET app while others are served by the new ASP.NET Core app. Users should only have to sign in once, though. This can be accomplished by either of the following approaches: * Using the System.Web adapters' [remote authentication](xref:migration/fx-to-core/areas/authentication#remote-authentication) feature, which uses the ASP.NET app to sign users in. -* Configuring the ASP.NET app to use Microsoft.Owin Cookie Authentication Middleware so that authentication cookies are shared with the ASP.NET Core app. +* Configuring the ASP.NET app to use Microsoft.Owin cookie authentication middleware so that authentication cookies are shared with the ASP.NET Core app. -To configure ASP.NET Microsoft.Owin Cookie Authentication Middleware to share cookies with an ASP.NET Core app, follow the preceding instructions to configure the ASP.NET Core app to use a specific cookie name, app name, and to persist data protection keys to a well-known location. See [Configure ASP.NET Core Data Protection](xref:security/data-protection/configuration/overview) for more information on persisting data protection keys. +To configure ASP.NET Microsoft.Owin cookie authentication middleware to share cookies with an ASP.NET Core app, follow the preceding instructions to configure the ASP.NET Core app to use a specific cookie name, app name, and to persist data protection keys to a well-known location. See [Configure ASP.NET Core Data Protection](xref:security/data-protection/configuration/overview) for more information on persisting data protection keys. In the ASP.NET app, install the [`Microsoft.Owin.Security.Interop`](https://www.nuget.org/packages/Microsoft.Owin.Security.Interop/) package. @@ -116,7 +116,7 @@ Note that because there are differences between ASP.NET Identity and ASP.NET Cor * * [A primer on OWIN cookie authentication middleware for the ASP.NET developer](https://brockallen.com/2013/10/24/a-primer-on-owin-cookie-authentication-middleware-for-the-asp-net-developer/) by [Brock Allen](https://brockallen.com/) -* [OWIN Authentication Middleware Architecture](https://brockallen.com/2013/08/07/owin-authentication-middleware-architecture/) by [Brock Allen](https://brockallen.com/) +* [OWIN authentication middleware Architecture](https://brockallen.com/2013/08/07/owin-authentication-middleware-architecture/) by [Brock Allen](https://brockallen.com/) * [Posts from the ‘OWIN / Katana’ Category](https://brockallen.com/category/owin-katana/) by [Brock Allen](https://brockallen.com/) :::moniker-end @@ -131,7 +131,7 @@ In the examples that follow: * `Identity.Application` is used as the authentication scheme. Whatever scheme is used, it must be used consistently *within and across* the shared cookie apps either as the default scheme or by explicitly setting it. The scheme is used when encrypting and decrypting cookies, so a consistent scheme must be used across apps. * A common [data protection key](xref:security/data-protection/implementation/key-management) storage location is used. * In ASP.NET Core apps, is used to set the key storage location. - * In .NET Framework apps, Cookie Authentication Middleware uses an implementation of . `DataProtectionProvider` provides data protection services for the encryption and decryption of authentication cookie payload data. The `DataProtectionProvider` instance is isolated from the data protection system used by other parts of the app. [DataProtectionProvider.Create(System.IO.DirectoryInfo, Action\)](xref:Microsoft.AspNetCore.DataProtection.DataProtectionProvider.Create*) accepts a to specify the location for data protection key storage. + * In .NET Framework apps, cookie authentication middleware uses an implementation of . `DataProtectionProvider` provides data protection services for the encryption and decryption of authentication cookie payload data. The `DataProtectionProvider` instance is isolated from the data protection system used by other parts of the app. [DataProtectionProvider.Create(System.IO.DirectoryInfo, Action\)](xref:Microsoft.AspNetCore.DataProtection.DataProtectionProvider.Create*) accepts a to specify the location for data protection key storage. * `DataProtectionProvider` requires the [Microsoft.AspNetCore.DataProtection.Extensions](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.Extensions/) NuGet package: * In ASP.NET Core 2.x apps, reference the [Microsoft.AspNetCore.App metapackage](xref:fundamentals/metapackage-app). * In .NET Framework apps, add a package reference to [Microsoft.AspNetCore.DataProtection.Extensions](https://www.nuget.org/packages/Microsoft.AspNetCore.DataProtection.Extensions/). @@ -213,7 +213,7 @@ services.AddDataProtection() ## Share authentication cookies between ASP.NET 4.x and ASP.NET Core apps -ASP.NET 4.x apps that use Katana Cookie Authentication Middleware can be configured to generate authentication cookies that are compatible with the ASP.NET Core Cookie Authentication Middleware. For more information, see [Share authentication cookies between ASP.NET 4.x and ASP.NET Core apps (dotnet/AspNetCore.Docs #21987)](https://github.com/dotnet/AspNetCore.Docs/issues/21987). +ASP.NET 4.x apps that use Katana cookie authentication middleware can be configured to generate authentication cookies that are compatible with the ASP.NET Core cookie authentication middleware. For more information, see [Share authentication cookies between ASP.NET 4.x and ASP.NET Core apps (dotnet/AspNetCore.Docs #21987)](https://github.com/dotnet/AspNetCore.Docs/issues/21987). ## Use a common user database diff --git a/aspnetcore/security/cors.md b/aspnetcore/security/cors.md index 71d4f6de436b..f45f3505a2a0 100644 --- a/aspnetcore/security/cors.md +++ b/aspnetcore/security/cors.md @@ -64,7 +64,7 @@ Each approach is detailed in the following sections. ## CORS with named policy and middleware -CORS Middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: +CORS middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: [!code-csharp[](~/security/cors/8.0sample/Cors/Web2API/Program.cs?name=snippet&highlight=1,5-13,24)] @@ -74,7 +74,7 @@ The preceding code: * Calls the extension method and specifies the `_myAllowSpecificOrigins` CORS policy. `UseCors` adds the CORS middleware. The call to `UseCors` must be placed after `UseRouting`, but before `UseAuthorization`. For more information, see [Middleware order](xref:fundamentals/middleware/index#middleware-order). * Calls with a [lambda expression](/dotnet/csharp/programming-guide/statements-expressions-operators/lambda-expressions). The lambda takes a object. [Configuration options](#cors-policy-options), such as `WithOrigins`, are described later in this article. * Enables the `_myAllowSpecificOrigins` CORS policy for all controller endpoints. See [endpoint routing](#ecors6) to apply a CORS policy to specific endpoints. -* When using [Response Caching Middleware](xref:performance/caching/middleware), call before . +* When using [response caching middleware](xref:performance/caching/middleware), call before . With endpoint routing, the CORS middleware **must** be configured to execute between the calls to `UseRouting` and `UseEndpoints`. @@ -233,7 +233,7 @@ To allow all author request headers, call policy.WithHeaders(HeaderNames.CacheControl)); ``` -CORS Middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: +CORS middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: ``` Access-Control-Request-Headers: Cache-Control, Content-Language @@ -573,7 +573,7 @@ Using a browser with the F12 tools: CORS-enabled endpoints can be tested with a tool, such as [curl](https://curl.haxx.se/) or [Fiddler](https://www.telerik.com/fiddler). When using a tool, the origin of the request specified by the `Origin` header must differ from the host receiving the request. If the request isn't *cross-origin* based on the value of the `Origin` header: -* There's no need for CORS Middleware to process the request. +* There's no need for CORS middleware to process the request. * CORS headers aren't returned in the response. The following command uses `curl` to issue an OPTIONS request with information: diff --git a/aspnetcore/security/cors/includes/cors56.md b/aspnetcore/security/cors/includes/cors56.md index c13a0d4b68a8..083c1915a3fe 100644 --- a/aspnetcore/security/cors/includes/cors56.md +++ b/aspnetcore/security/cors/includes/cors56.md @@ -51,7 +51,7 @@ Each approach is detailed in the following sections. ## CORS with named policy and middleware -CORS Middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: +CORS middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: [!code-csharp[](~/security/cors/6.0sample/Cors/WebAPI/Program.cs?name=snippet&highlight=1,5-13,24)] @@ -61,7 +61,7 @@ The preceding code: * Calls the extension method and specifies the `_myAllowSpecificOrigins` CORS policy. `UseCors` adds the CORS middleware. The call to `UseCors` must be placed after `UseRouting`, but before `UseAuthorization`. For more information, see [Middleware order](xref:fundamentals/middleware/index#middleware-order). * Calls with a [lambda expression](/dotnet/csharp/programming-guide/statements-expressions-operators/lambda-expressions). The lambda takes a object. [Configuration options](#cors-policy-options), such as `WithOrigins`, are described later in this article. * Enables the `_myAllowSpecificOrigins` CORS policy for all controller endpoints. See [endpoint routing](#ecors6) to apply a CORS policy to specific endpoints. -* When using [Response Caching Middleware](xref:performance/caching/middleware), call before . +* When using [response caching middleware](xref:performance/caching/middleware), call before . With endpoint routing, the CORS middleware **must** be configured to execute between the calls to `UseRouting` and `UseEndpoints`. @@ -227,7 +227,7 @@ To allow all [author request headers](https://www.w3.org/TR/cors/#author-request `AllowAnyHeader` affects preflight requests and the [Access-Control-Request-Headers](https://developer.mozilla.org/docs/Web/HTTP/Headers/Access-Control-Request-Method) header. For more information, see the [Preflight requests](#preflight-requests) section. -A CORS Middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. +A CORS middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. For instance, consider an app configured as follows: @@ -235,7 +235,7 @@ For instance, consider an app configured as follows: app.UseCors(policy => policy.WithHeaders(HeaderNames.CacheControl)); ``` -CORS Middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: +CORS middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: ``` Access-Control-Request-Headers: Cache-Control, Content-Language @@ -575,7 +575,7 @@ Using a browser with the F12 tools: CORS-enabled endpoints can be tested with a tool, such as [curl](https://curl.haxx.se/) or [Fiddler](https://www.telerik.com/fiddler). When using a tool, the origin of the request specified by the `Origin` header must differ from the host receiving the request. If the request isn't *cross-origin* based on the value of the `Origin` header: -* There's no need for CORS Middleware to process the request. +* There's no need for CORS middleware to process the request. * CORS headers aren't returned in the response. The following command uses `curl` to issue an OPTIONS request with information: @@ -677,7 +677,7 @@ Each approach is detailed in the following sections. ## CORS with named policy and middleware -CORS Middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: +CORS middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: [!code-csharp[](~/security/cors/3.1sample/Cors/WebAPI/Startup.cs?name=snippet&highlight=3,9,32)] @@ -687,7 +687,7 @@ The preceding code: * Calls the extension method and specifies the `_myAllowSpecificOrigins` CORS policy. `UseCors` adds the CORS middleware. The call to `UseCors` must be placed after `UseRouting`, but before `UseAuthorization`. For more information, see [Middleware order](xref:fundamentals/middleware/index#middleware-order). * Calls with a [lambda expression](/dotnet/csharp/programming-guide/statements-expressions-operators/lambda-expressions). The lambda takes a object. [Configuration options](#cors-policy-options), such as `WithOrigins`, are described later in this article. * Enables the `_myAllowSpecificOrigins` CORS policy for all controller endpoints. See [endpoint routing](#ecors) to apply a CORS policy to specific endpoints. -* When using [Response Caching Middleware](xref:performance/caching/middleware), call before . +* When using [response caching middleware](xref:performance/caching/middleware), call before . With endpoint routing, the CORS middleware **must** be configured to execute between the calls to `UseRouting` and `UseEndpoints`. @@ -844,13 +844,13 @@ To allow all [author request headers](https://www.w3.org/TR/cors/#author-request `AllowAnyHeader` affects preflight requests and the [Access-Control-Request-Headers](https://developer.mozilla.org/docs/Web/HTTP/Headers/Access-Control-Request-Method) header. For more information, see the [Preflight requests](#preflight-requests) section. -A CORS Middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. +A CORS middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. For instance, consider an app configured as follows: [!code-csharp[](~/security/cors/3.1sample/Cors/WebAPI/StartupAllowSubdomain.cs?name=snippet4)] -CORS Middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: +CORS middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: ``` Access-Control-Request-Headers: Cache-Control, Content-Language @@ -1181,7 +1181,7 @@ Using a browser with the F12 tools: CORS-enabled endpoints can be tested with a tool, such as [curl](https://curl.haxx.se/) or [Fiddler](https://www.telerik.com/fiddler). When using a tool, the origin of the request specified by the `Origin` header must differ from the host receiving the request. If the request isn't *cross-origin* based on the value of the `Origin` header: -* There's no need for CORS Middleware to process the request. +* There's no need for CORS middleware to process the request. * CORS headers aren't returned in the response. The following command uses `curl` to issue an OPTIONS request with information: diff --git a/aspnetcore/security/cors/includes/cors7.md b/aspnetcore/security/cors/includes/cors7.md index 6d8165294d6b..e3a99fdc622d 100644 --- a/aspnetcore/security/cors/includes/cors7.md +++ b/aspnetcore/security/cors/includes/cors7.md @@ -50,7 +50,7 @@ Each approach is detailed in the following sections. ## CORS with named policy and middleware -CORS Middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: +CORS middleware handles cross-origin requests. The following code applies a CORS policy to all the app's endpoints with the specified origins: [!code-csharp[](~/security/cors/8.0sample/Cors/Web2API/Program.cs?name=snippet&highlight=1,5-13,24)] @@ -60,7 +60,7 @@ The preceding code: * Calls the extension method and specifies the `_myAllowSpecificOrigins` CORS policy. `UseCors` adds the CORS middleware. The call to `UseCors` must be placed after `UseRouting`, but before `UseAuthorization`. For more information, see [Middleware order](xref:fundamentals/middleware/index#middleware-order). * Calls with a [lambda expression](/dotnet/csharp/programming-guide/statements-expressions-operators/lambda-expressions). The lambda takes a object. [Configuration options](#cors-policy-options), such as `WithOrigins`, are described later in this article. * Enables the `_myAllowSpecificOrigins` CORS policy for all controller endpoints. See [endpoint routing](#ecors6) to apply a CORS policy to specific endpoints. -* When using [Response Caching Middleware](xref:performance/caching/middleware), call before . +* When using [response caching middleware](xref:performance/caching/middleware), call before . With endpoint routing, the CORS middleware **must** be configured to execute between the calls to `UseRouting` and `UseEndpoints`. @@ -228,7 +228,7 @@ To allow all [author request headers](https://www.w3.org/TR/cors/#author-request `AllowAnyHeader` affects preflight requests and the [Access-Control-Request-Headers](https://developer.mozilla.org/docs/Web/HTTP/Headers/Access-Control-Request-Method) header. For more information, see the [Preflight requests](#preflight-requests) section. -A CORS Middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. +A CORS middleware policy match to specific headers specified by `WithHeaders` is only possible when the headers sent in `Access-Control-Request-Headers` exactly match the headers stated in `WithHeaders`. For instance, consider an app configured as follows: @@ -236,7 +236,7 @@ For instance, consider an app configured as follows: app.UseCors(policy => policy.WithHeaders(HeaderNames.CacheControl)); ``` -CORS Middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: +CORS middleware declines a preflight request with the following request header because `Content-Language` ([HeaderNames.ContentLanguage](xref:Microsoft.Net.Http.Headers.HeaderNames.ContentLanguage)) isn't listed in `WithHeaders`: ``` Access-Control-Request-Headers: Cache-Control, Content-Language @@ -567,7 +567,7 @@ Using a browser with the F12 tools: CORS-enabled endpoints can be tested with a tool, such as [curl](https://curl.haxx.se/) or [Fiddler](https://www.telerik.com/fiddler). When using a tool, the origin of the request specified by the `Origin` header must differ from the host receiving the request. If the request isn't *cross-origin* based on the value of the `Origin` header: -* There's no need for CORS Middleware to process the request. +* There's no need for CORS middleware to process the request. * CORS headers aren't returned in the response. The following command uses `curl` to issue an OPTIONS request with information: diff --git a/aspnetcore/security/enforcing-ssl.md b/aspnetcore/security/enforcing-ssl.md index 8c67bbfac88a..be0d8ed8b68c 100644 --- a/aspnetcore/security/enforcing-ssl.md +++ b/aspnetcore/security/enforcing-ssl.md @@ -41,7 +41,7 @@ To disable HTTP redirection in an API, set the `ASPNETCORE_URLS` environment var ### HSTS and API projects -The secure approach for [HTTP Strict Transport Security Protocol (HSTS)](#hsts) is to configure API projects to only listen to and respond over HTTPS. +The secure approach for [HTTP Strict Transport Security (HSTS) protocol](#hsts) is to configure API projects to only listen to and respond over HTTPS. > [!WARNING] > The default API projects don't include [HSTS](https://developer.mozilla.org/docs/Web/HTTP/Headers/Strict-Transport-Security) because it's generally a browser only instruction. Other callers, such as phone or desktop apps, do **not** obey the instruction. Even within browsers, a single authenticated call to an API over HTTP has risks on insecure networks. @@ -56,12 +56,12 @@ API projects can reject HTTP requests rather than use the `UseHttpsRedirection` For production ASP.NET Core web apps, the following approach is recommended: -* To redirect HTTP requests to HTTPS, use HTTPS Redirection Middleware (). +* To redirect HTTP requests to HTTPS, use HTTPS redirection middleware (). -* To send HSTS headers to clients, use HSTS Middleware via the [UseHsts](#hsts) method. +* To send HSTS headers to clients, use HSTS middleware via the [UseHsts](#hsts) method. > [!NOTE] -> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS Redirection Middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in Internet Information Services (IIS) 10.0 version 1709 or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), then the app doesn't require HSTS Middleware. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). +> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS redirection middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in Internet Information Services (IIS) 10.0 version 1709 or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), then the app doesn't require HSTS middleware. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). ### UseHttpsRedirection @@ -115,7 +115,7 @@ For more information, see [Kestrel endpoint configuration](xref:fundamentals/ser Any firewall between the client and server must also have communication ports open for traffic. -If requests are forwarded in a reverse proxy configuration, use [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS Redirection Middleware. Forwarded Headers Middleware updates the `Request.Scheme` by using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When Forwarded Headers Middleware isn't used, the back-end app might not receive the correct scheme and get caught in a redirect loop. A common end user error message is there are too many redirects. +If requests are forwarded in a reverse proxy configuration, use [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS redirection middleware. Forwarded headers middleware updates the `Request.Scheme` by using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When forwarded headers middleware isn't used, the back-end app might not receive the correct scheme and get caught in a redirect loop. A common end user error message is there are too many redirects. When deploying to Azure App Service, follow the guidance in [Enable HTTPS for a custom domain in Azure App Service](/azure/app-service/configure-ssl-bindings). @@ -140,15 +140,13 @@ The following code shows configuration of services in the _Program.cs_ file: [!code-csharp[](enforcing-ssl/sample-snapshot/6.x/Program3.cs?highlight=7-14)] -## HTTPS Redirection Middleware alternative approach +## HTTPS redirection middleware alternative approach -An alternative to using HTTPS Redirection Middleware (with the `UseHttpsRedirection` method) is to use URL Rewriting Middleware (via the `AddRedirectToHttps` method). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL Rewriting Middleware](xref:fundamentals/url-rewriting). +An alternative to using HTTPS redirection middleware (with the `UseHttpsRedirection` method) is to use URL rewriting middleware (via the `AddRedirectToHttps` method). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL rewriting middleware](xref:fundamentals/url-rewriting). -When the app redirects to HTTPS without the requirement for other redirect rules, the recommendation is to use HTTPS Redirection Middleware (`UseHttpsRedirection`) as described in this article. +When the app redirects to HTTPS without the requirement for other redirect rules, the recommendation is to use HTTPS redirection middleware (`UseHttpsRedirection`) as described in this article. - - -## HTTP Strict Transport Security Protocol (HSTS) +## HTTP Strict Transport Security (HSTS) protocol Per [OWASP](https://owasp.org/about/), [HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) is an opt-in security enhancement specified by a web app via a response header. When a [browser that supports HSTS](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html#browser-support) receives this header: diff --git a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl6.md b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl6.md index b549b96914eb..2fec25104b63 100644 --- a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl6.md +++ b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl6.md @@ -29,11 +29,11 @@ API projects can reject HTTP requests rather than use `UseHttpsRedirection` to r We recommend that production ASP.NET Core web apps use: -* HTTPS Redirection Middleware () to redirect HTTP requests to HTTPS. -* HSTS Middleware ([UseHsts](#http-strict-transport-security-protocol-hsts)) to send HTTP Strict Transport Security Protocol (HSTS) headers to clients. +* HTTPS redirection middleware () to redirect HTTP requests to HTTPS. +* HSTS middleware ([UseHsts](#http-strict-transport-security-hsts-protocol)) to send HTTP Strict Transport Security (HSTS) protocol headers to clients. > [!NOTE] -> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS Redirection Middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS Middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). +> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS redirection middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). ### UseHttpsRedirection @@ -46,7 +46,7 @@ The preceding highlighted code: * Uses the default (). * Uses the default (null) unless overridden by the `ASPNETCORE_HTTPS_PORT` environment variable or . -We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-protocol-hsts) to signal to clients that only secure resource requests should be sent to the app (only in production). +We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-hsts-protocol) to signal to clients that only secure resource requests should be sent to the app (only in production). ### Port configuration @@ -88,7 +88,7 @@ For more information, see [Kestrel endpoint configuration](xref:fundamentals/ser Any firewall between the client and server must also have communication ports open for traffic. -If requests are forwarded in a reverse proxy configuration, use [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS Redirection Middleware. Forwarded Headers Middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When Forwarded Headers Middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. +If requests are forwarded in a reverse proxy configuration, use [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS redirection middleware. Forwarded headers middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When forwarded headers middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. When deploying to Azure App Service, follow the guidance in [Tutorial: Bind an existing custom SSL certificate to Azure Web Apps](/azure/app-service/app-service-web-tutorial-custom-ssl). @@ -113,15 +113,15 @@ When configuring services in `Program.cs`: [!code-csharp[](~/security/enforcing-ssl/sample-snapshot/6.x/Program3.cs?highlight=7-14)] -## HTTPS Redirection Middleware alternative approach +## HTTPS redirection middleware alternative approach -An alternative to using HTTPS Redirection Middleware (`UseHttpsRedirection`) is to use URL Rewriting Middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL Rewriting Middleware](xref:fundamentals/url-rewriting). +An alternative to using HTTPS redirection middleware (`UseHttpsRedirection`) is to use URL rewriting middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL rewriting middleware](xref:fundamentals/url-rewriting). -When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware (`UseHttpsRedirection`) described in this article. +When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware (`UseHttpsRedirection`) described in this article. -## HTTP Strict Transport Security Protocol (HSTS) +## HTTP Strict Transport Security (HSTS) protocol Per [OWASP](https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project), [HTTP Strict Transport Security (HSTS)](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) is an opt-in security enhancement that's specified by a web app through the use of a response header. When a [browser that supports HSTS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#browser-support) receives this header: @@ -159,7 +159,7 @@ The following highlighted code: ## Opt-out of HTTPS/HSTS on project creation -In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-protocol-hsts). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. +In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-hsts-protocol). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. To opt-out of HTTPS/HSTS: @@ -691,11 +691,11 @@ In some cases, group policy may prevent self-signed certificates from being trus We recommend that production ASP.NET Core web apps use: -* HTTPS Redirection Middleware () to redirect HTTP requests to HTTPS. -* HSTS Middleware ([UseHsts](#http-strict-transport-security-protocol-hsts)) to send HTTP Strict Transport Security Protocol (HSTS) headers to clients. +* HTTPS redirection middleware () to redirect HTTP requests to HTTPS. +* HSTS middleware ([UseHsts](#http-strict-transport-security-hsts-protocol)) to send HTTP Strict Transport Security (HSTS) protocol headers to clients. > [!NOTE] -> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS Redirection Middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS Middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). +> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS redirection middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). ### UseHttpsRedirection @@ -708,7 +708,7 @@ The preceding highlighted code: * Uses the default (). * Uses the default (null) unless overridden by the `ASPNETCORE_HTTPS_PORT` environment variable or . -We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-protocol-hsts) to signal to clients that only secure resource requests should be sent to the app (only in production). +We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-hsts-protocol) to signal to clients that only secure resource requests should be sent to the app (only in production). ### Port configuration @@ -751,7 +751,7 @@ For more information, see [Kestrel endpoint configuration](xref:fundamentals/ser Any firewall between the client and server must also have communication ports open for traffic. -If requests are forwarded in a reverse proxy configuration, use [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS Redirection Middleware. Forwarded Headers Middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When Forwarded Headers Middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. +If requests are forwarded in a reverse proxy configuration, use [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS redirection middleware. Forwarded headers middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When forwarded headers middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. When deploying to Azure App Service, follow the guidance in [Tutorial: Bind an existing custom SSL certificate to Azure Web Apps](/azure/app-service/app-service-web-tutorial-custom-ssl). @@ -789,15 +789,15 @@ public void ConfigureServices(IServiceCollection services) } ``` -## HTTPS Redirection Middleware alternative approach +## HTTPS redirection middleware alternative approach -An alternative to using HTTPS Redirection Middleware (`UseHttpsRedirection`) is to use URL Rewriting Middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL Rewriting Middleware](xref:fundamentals/url-rewriting). +An alternative to using HTTPS redirection middleware (`UseHttpsRedirection`) is to use URL rewriting middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL rewriting middleware](xref:fundamentals/url-rewriting). -When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware (`UseHttpsRedirection`) described in this article. +When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware (`UseHttpsRedirection`) described in this article. -## HTTP Strict Transport Security Protocol (HSTS) +## HTTP Strict Transport Security (HSTS) protocol Per [OWASP](https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project), [HTTP Strict Transport Security (HSTS)](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) is an opt-in security enhancement that's specified by a web app through the use of a response header. When a [browser that supports HSTS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#browser-support) receives this header: @@ -835,7 +835,7 @@ The following code: ## Opt-out of HTTPS/HSTS on project creation -In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-protocol-hsts). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. +In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-hsts-protocol). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. To opt-out of HTTPS/HSTS: diff --git a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl7.md b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl7.md index 18395226fd41..701847e7525c 100644 --- a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl7.md +++ b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl7.md @@ -29,11 +29,11 @@ API projects can reject HTTP requests rather than use `UseHttpsRedirection` to r We recommend that production ASP.NET Core web apps use: -* HTTPS Redirection Middleware () to redirect HTTP requests to HTTPS. -* HSTS Middleware ([UseHsts](#http-strict-transport-security-protocol-hsts)) to send HTTP Strict Transport Security Protocol (HSTS) headers to clients. +* HTTPS redirection middleware () to redirect HTTP requests to HTTPS. +* HSTS middleware ([UseHsts](#http-strict-transport-security-hsts-protocol)) to send HTTP Strict Transport Security (HSTS) protocol headers to clients. > [!NOTE] -> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS Redirection Middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS Middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). +> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS redirection middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). ### UseHttpsRedirection @@ -46,7 +46,7 @@ The preceding highlighted code: * Uses the default (). * Uses the default (null) unless overridden by the `ASPNETCORE_HTTPS_PORT` environment variable or . -We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-protocol-hsts) to signal to clients that only secure resource requests should be sent to the app (only in production). +We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-hsts-protocol) to signal to clients that only secure resource requests should be sent to the app (only in production). ### Port configuration @@ -88,7 +88,7 @@ For more information, see [Kestrel endpoint configuration](xref:fundamentals/ser Any firewall between the client and server must also have communication ports open for traffic. -If requests are forwarded in a reverse proxy configuration, use [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS Redirection Middleware. Forwarded Headers Middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When Forwarded Headers Middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. +If requests are forwarded in a reverse proxy configuration, use [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS redirection middleware. Forwarded headers middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When forwarded headers middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. When deploying to Azure App Service, follow the guidance in [Tutorial: Bind an existing custom SSL certificate to Azure Web Apps](/azure/app-service/app-service-web-tutorial-custom-ssl). @@ -113,15 +113,15 @@ When configuring services in `Program.cs`: [!code-csharp[](~/security/enforcing-ssl/sample-snapshot/6.x/Program3.cs?highlight=7-14)] -## HTTPS Redirection Middleware alternative approach +## HTTPS redirection middleware alternative approach -An alternative to using HTTPS Redirection Middleware (`UseHttpsRedirection`) is to use URL Rewriting Middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL Rewriting Middleware](xref:fundamentals/url-rewriting). +An alternative to using HTTPS redirection middleware (`UseHttpsRedirection`) is to use URL rewriting middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL rewriting middleware](xref:fundamentals/url-rewriting). -When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware (`UseHttpsRedirection`) described in this article. +When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware (`UseHttpsRedirection`) described in this article. -## HTTP Strict Transport Security Protocol (HSTS) +## HTTP Strict Transport Security (HSTS) protocol Per [OWASP](https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project), [HTTP Strict Transport Security (HSTS)](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) is an opt-in security enhancement that's specified by a web app through the use of a response header. When a [browser that supports HSTS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#browser-support) receives this header: @@ -159,7 +159,7 @@ The following highlighted code: ## Opt-out of HTTPS/HSTS on project creation -In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-protocol-hsts). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. +In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-hsts-protocol). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. To opt-out of HTTPS/HSTS: diff --git a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl8.md b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl8.md index 44538e9680a0..7c1c6551301a 100644 --- a/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl8.md +++ b/aspnetcore/security/enforcing-ssl/includes/enforcing-ssl8.md @@ -29,11 +29,11 @@ API projects can reject HTTP requests rather than use `UseHttpsRedirection` to r We recommend that production ASP.NET Core web apps use: -* HTTPS Redirection Middleware () to redirect HTTP requests to HTTPS. -* HSTS Middleware ([UseHsts](#http-strict-transport-security-protocol-hsts)) to send HTTP Strict Transport Security Protocol (HSTS) headers to clients. +* HTTPS redirection middleware () to redirect HTTP requests to HTTPS. +* HSTS middleware ([UseHsts](#http-strict-transport-security-hsts-protocol)) to send HTTP Strict Transport Security (HSTS) protocol headers to clients. > [!NOTE] -> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS Redirection Middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS Middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). +> Apps deployed in a reverse proxy configuration allow the proxy to handle connection security (HTTPS). If the proxy also handles HTTPS redirection, there's no need to use HTTPS redirection middleware. If the proxy server also handles writing HSTS headers (for example, [native HSTS support in IIS 10.0 (1709) or later](/iis/get-started/whats-new-in-iis-10-version-1709/iis-10-version-1709-hsts#iis-100-version-1709-native-hsts-support)), HSTS middleware isn't required by the app. For more information, see [Opt-out of HTTPS/HSTS on project creation](#opt-out-of-httpshsts-on-project-creation). ### UseHttpsRedirection @@ -46,7 +46,7 @@ The preceding highlighted code: * Uses the default (). * Uses the default (null) unless overridden by the `ASPNETCORE_HTTPS_PORT` environment variable or . -We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-protocol-hsts) to signal to clients that only secure resource requests should be sent to the app (only in production). +We recommend using temporary redirects rather than permanent redirects. Link caching can cause unstable behavior in development environments. If you prefer to send a permanent redirect status code when the app is in a non-`Development` environment, see the [Configure permanent redirects in production](#configure-permanent-redirects-in-production) section. We recommend using [HSTS](#http-strict-transport-security-hsts-protocol) to signal to clients that only secure resource requests should be sent to the app (only in production). ### Port configuration @@ -88,7 +88,7 @@ For more information, see [Kestrel endpoint configuration](xref:fundamentals/ser Any firewall between the client and server must also have communication ports open for traffic. -If requests are forwarded in a reverse proxy configuration, use [Forwarded Headers Middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS Redirection Middleware. Forwarded Headers Middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When Forwarded Headers Middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. +If requests are forwarded in a reverse proxy configuration, use [forwarded headers middleware](xref:host-and-deploy/proxy-load-balancer) before calling HTTPS redirection middleware. Forwarded headers middleware updates the `Request.Scheme`, using the `X-Forwarded-Proto` header. The middleware permits redirect URIs and other security policies to work correctly. When forwarded headers middleware isn't used, the backend app might not receive the correct scheme and end up in a redirect loop. A common end user error message is that too many redirects have occurred. When deploying to Azure App Service, follow the guidance in [Tutorial: Bind an existing custom SSL certificate to Azure Web Apps](/azure/app-service/app-service-web-tutorial-custom-ssl). @@ -113,15 +113,15 @@ When configuring services in `Program.cs`: [!code-csharp[](~/security/enforcing-ssl/sample-snapshot/6.x/Program3.cs?highlight=7-14)] -## HTTPS Redirection Middleware alternative approach +## HTTPS redirection middleware alternative approach -An alternative to using HTTPS Redirection Middleware (`UseHttpsRedirection`) is to use URL Rewriting Middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL Rewriting Middleware](xref:fundamentals/url-rewriting). +An alternative to using HTTPS redirection middleware (`UseHttpsRedirection`) is to use URL rewriting middleware (`AddRedirectToHttps`). `AddRedirectToHttps` can also set the status code and port when the redirect is executed. For more information, see [URL rewriting middleware](xref:fundamentals/url-rewriting). -When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS Redirection Middleware (`UseHttpsRedirection`) described in this article. +When redirecting to HTTPS without the requirement for additional redirect rules, we recommend using HTTPS redirection middleware (`UseHttpsRedirection`) described in this article. -## HTTP Strict Transport Security Protocol (HSTS) +## HTTP Strict Transport Security (HSTS) protocol Per [OWASP](https://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project), [HTTP Strict Transport Security (HSTS)](https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html) is an opt-in security enhancement that's specified by a web app through the use of a response header. When a [browser that supports HSTS](https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#browser-support) receives this header: @@ -159,7 +159,7 @@ The following highlighted code: ## Opt-out of HTTPS/HSTS on project creation -In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-protocol-hsts). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. +In some backend service scenarios where connection security is handled at the public-facing edge of the network, configuring connection security at each node isn't required. Web apps that are generated from the templates in Visual Studio or from the [dotnet new](/dotnet/core/tools/dotnet-new) command enable [HTTPS redirection](#require-https) and [HSTS](#http-strict-transport-security-hsts-protocol). For deployments that don't require these scenarios, you can opt-out of HTTPS/HSTS when the app is created from the template. To opt-out of HTTPS/HSTS: diff --git a/aspnetcore/test/integration-tests.md b/aspnetcore/test/integration-tests.md index fba32f6560af..6a9f5eb90663 100644 --- a/aspnetcore/test/integration-tests.md +++ b/aspnetcore/test/integration-tests.md @@ -294,7 +294,7 @@ Create the `WebApplicationFactoryClientOptions` class and pass it to the Swashbuckle relies on MVC's to discover the routes and endpoints. If the project calls , routes and endpoints are discovered automatically. When calling , the method must be explicitly called. For more information, see [Swashbuckle, ApiExplorer, and Routing](https://github.com/domaindrivendev/Swashbuckle.AspNetCore#swashbuckle-apiexplorer-and-routing). In development, the preceding `UseSwaggerUI` method call enables an embedded version of the Swagger UI tool. This depends on -the [Static File Middleware](xref:fundamentals/static-files). If targeting .NET Framework or .NET Core 1.x, add the [Microsoft.AspNetCore.StaticFiles](https://www.nuget.org/packages/Microsoft.AspNetCore.StaticFiles/) NuGet package to the project. +the [static file middleware](xref:fundamentals/static-files). If targeting .NET Framework or .NET Core 1.x, add the [Microsoft.AspNetCore.StaticFiles](https://www.nuget.org/packages/Microsoft.AspNetCore.StaticFiles/) NuGet package to the project. Launch the app, and navigate to `http://localhost:/swagger/v1/swagger.json`. The generated document describing the endpoints appears as shown in [OpenAPI specification (openapi.json)](xref:tutorials/web-api-help-pages-using-swagger#openapi-specification-openapijson). @@ -531,7 +531,7 @@ If targeting .NET Framework or .NET Core 1.x, add the [Microsoft.AspNetCore.Stat The preceding NuGet package is already installed if targeting .NET Core 2.x and using the [metapackage](xref:fundamentals/metapackage). -Enable Static File Middleware: +Enable static file middleware: :::code language="csharp" source="~/tutorials/web-api-help-pages-using-swagger/samples/3.x/TodoApi.Swashbuckle/Startup.cs" id="snippet_Configure" highlight="3"::: diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field3.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field3.md index f2f4df8735d8..656ba882a5d8 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field3.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field3.md @@ -14,7 +14,7 @@ When using EF Code First to automatically create a database, Code First: Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field5.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field5.md index aa3726419813..c3a088fa13dc 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field5.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field5.md @@ -14,7 +14,7 @@ When using EF Code First to automatically create a database, Code First: Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field6.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field6.md index abf64d78b338..9d713addd1b7 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field6.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field6.md @@ -12,7 +12,7 @@ When using EF Code First to automatically create and track a database, Code Firs Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/sample/RazorPagesMovie60/Models/MovieDateRating.cs?highlight=13&name=snippet)] diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field7.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field7.md index 7f0cf96092a2..9598b56444dc 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field7.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field7.md @@ -12,7 +12,7 @@ When using EF Code First to automatically create and track a database, Code Firs Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field8.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field8.md index bef4db6d2b70..2f4fe5d15b9a 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field8.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field8.md @@ -13,7 +13,7 @@ When using EF Code First to automatically create and track a database, Code Firs Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: diff --git a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field9.md b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field9.md index 00e96d456c59..42713f35cd73 100644 --- a/aspnetcore/tutorials/razor-pages/new-field/includes/new-field9.md +++ b/aspnetcore/tutorials/razor-pages/new-field/includes/new-field9.md @@ -14,7 +14,7 @@ Using EF Code to automatically create and track a database: Automatic verification that the schema and model are in sync makes it easier to find inconsistent database code issues. -## Adding a Rating Property to the Movie Model +## Add a `Rating` property to the `Movie` model 1. Open the `Models/Movie.cs` file and add a `Rating` property: diff --git a/aspnetcore/tutorials/razor-pages/razor-pages-start.md b/aspnetcore/tutorials/razor-pages/razor-pages-start.md index 582122666212..5296f68141aa 100644 --- a/aspnetcore/tutorials/razor-pages/razor-pages-start.md +++ b/aspnetcore/tutorials/razor-pages/razor-pages-start.md @@ -169,7 +169,7 @@ The following lines of code in this file create a `WebApplicationBuilder` with p The developer exception page is enabled by default and provides helpful information on exceptions. Don't run production apps in development mode because the developer exception page can leak sensitive information. -The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) when the app is ***not*** running in development mode: +The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) when the app is ***not*** running in development mode: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/snapshot-sample10/Program1Snip.cs?name=snippet_env)] diff --git a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start6.md b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start6.md index a5d7cfe04bc8..c183596142bd 100644 --- a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start6.md +++ b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start6.md @@ -175,7 +175,7 @@ The following lines of code in this file create a `WebApplicationBuilder` with p The developer exception page is enabled by default and provides helpful information on exceptions. Production apps should not be run in development mode because the developer exception page can leak sensitive information. -The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) when the app is ***not*** running in development mode: +The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) when the app is ***not*** running in development mode: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/sample/RazorPagesMovie60/Program1Snip.cs?name=snippet_env)] diff --git a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start7.md b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start7.md index 6fe24d71d4a8..5d1bbd704d78 100644 --- a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start7.md +++ b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start7.md @@ -179,7 +179,7 @@ The following lines of code in this file create a `WebApplicationBuilder` with p The developer exception page is enabled by default and provides helpful information on exceptions. Production apps should not be run in development mode because the developer exception page can leak sensitive information. -The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) when the app is ***not*** running in development mode: +The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) when the app is ***not*** running in development mode: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/sample/RazorPagesMovie70/Program1Snip.cs?name=snippet_env)] diff --git a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start8.md b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start8.md index 6fd572ee9ac1..bdb7ff648d0e 100644 --- a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start8.md +++ b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start8.md @@ -150,7 +150,7 @@ The following lines of code in this file create a `WebApplicationBuilder` with p The developer exception page is enabled by default and provides helpful information on exceptions. Production apps should not be run in development mode because the developer exception page can leak sensitive information. -The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) when the app is ***not*** running in development mode: +The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) when the app is ***not*** running in development mode: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/sample/RazorPagesMovie80/Program1Snip.cs?name=snippet_env)] diff --git a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start9.md b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start9.md index c43b72c8a91d..e71de39513a3 100644 --- a/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start9.md +++ b/aspnetcore/tutorials/razor-pages/razor-pages-start/includes/razor-pages-start9.md @@ -152,7 +152,7 @@ The following lines of code in this file create a `WebApplicationBuilder` with p The developer exception page is enabled by default and provides helpful information on exceptions. Production apps should not be run in development mode because the developer exception page can leak sensitive information. -The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security Protocol (HSTS)](xref:security/enforcing-ssl#http-strict-transport-security-protocol-hsts) when the app is ***not*** running in development mode: +The following code sets the exception endpoint to `/Error` and enables [HTTP Strict Transport Security (HSTS) protocol](xref:security/enforcing-ssl#http-strict-transport-security-hsts-protocol) when the app is ***not*** running in development mode: [!code-csharp[](~/tutorials/razor-pages/razor-pages-start/snapshot_sample9/Program1Snip.cs?name=snippet_env)] diff --git a/aspnetcore/tutorials/web-api-help-pages-using-swagger/samples/3.x/TodoApi.Swashbuckle/readme.md b/aspnetcore/tutorials/web-api-help-pages-using-swagger/samples/3.x/TodoApi.Swashbuckle/readme.md index 031aaa8ed4d2..5404543cebc1 100644 --- a/aspnetcore/tutorials/web-api-help-pages-using-swagger/samples/3.x/TodoApi.Swashbuckle/readme.md +++ b/aspnetcore/tutorials/web-api-help-pages-using-swagger/samples/3.x/TodoApi.Swashbuckle/readme.md @@ -56,7 +56,7 @@ public void Configure(IApplicationBuilder app, IWebHostEnvironment env) } ``` -The preceding `UseSwaggerUI` method call enables an embedded version of the Swagger UI tool. It depends on the [Static File Middleware](https://learn.microsoft.com/aspnet/core/fundamentals/static-files). If targeting .NET Framework or .NET Core 1.x, add the [Microsoft.AspNetCore.StaticFiles](https://www.nuget.org/packages/Microsoft.AspNetCore.StaticFiles/) NuGet package to the project. +The preceding `UseSwaggerUI` method call enables an embedded version of the Swagger UI tool. It depends on the [static file middleware](https://learn.microsoft.com/aspnet/core/fundamentals/static-files). If targeting .NET Framework or .NET Core 1.x, add the [Microsoft.AspNetCore.StaticFiles](https://www.nuget.org/packages/Microsoft.AspNetCore.StaticFiles/) NuGet package to the project. Launch the app, and navigate to `http://localhost:/swagger/v1/swagger.json`. The generated document describing the endpoints appears as shown in [Swagger specification (swagger.json)](https://learn.microsoft.com/aspnet/core/tutorials/web-api-help-pages-using-swagger#swagger-specification-swaggerjson).