Apply suggestions from code review

Author: guardrex

aspnetcore/data/scaffold_RP.md

@@ -75,6 +75,7 @@ dotnet ef database update
 ```
 
 In  The preceding commands:
+
 * `dotnet tool uninstall --global dotnet-ef` uninstalls the `dotnet-ef` tool. Uninstalling ensures the latest tool is successfully installed. If `dotnet-ef` isn't installed, an error messages **A tool with the package Id 'dotnet-ef' could not be found.** You can ignore this message.
 * `dotnet tool install --global dotnet-ef` installs globally the `dotnet-ef` tool.
 * `dotnet ef migrations add initialMigration` adds the initial migration. For more information, see [Create the initial database schema using EF's migration feature](/aspnet/core/tutorials/razor-pages/model&tabs=visual-studio-code)

aspnetcore/fundamentals/openapi/include-metadata.md

@@ -516,6 +516,7 @@ public record Todo(
 In a class, struct, or record, properties with the [`[Required]`](xref:System.ComponentModel.DataAnnotations.RequiredAttribute) attribute or [required](/dotnet/csharp/language-reference/proposals/csharp-11.0/required-members#required-modifier) modifier are always `required` in the corresponding schema.
 
 Other properties may also be required based on the constructors (implicit and explicit) for the class, struct, or record.
+
 * For a class or record class with a single public constructor, any property with the same type and name (case-insensitive match) as a parameter to the constructor is required in the corresponding schema.
 * For a class or record class with multiple public constructors, no other properties are required.
 * For a struct or record struct, no other properties are required since C# always defines an implicit parameterless constructor for a struct.

aspnetcore/fundamentals/portable-object-localization.md

@@ -21,6 +21,7 @@ This article walks through the steps for using Portable Object (PO) files in an
 ## What is a PO file?
 
 PO files are distributed as text files containing the translated strings for a given language. Some advantages of using PO files instead of *.resx* files include:
+
 * PO files support pluralization; *.resx* files don't support pluralization.
 * PO files aren't compiled like *.resx* files. As such, specialized tooling and build steps aren't required.
 * PO files work well with collaborative online editing tools.
@@ -236,6 +237,7 @@ This article walks through the steps for using Portable Object (PO) files in an
 ## What is a PO file?
 
 PO files are distributed as text files containing the translated strings for a given language. Some advantages of using PO files instead of *.resx* files include:
+
 * PO files support pluralization; *.resx* files don't support pluralization.
 * PO files aren't compiled like *.resx* files. As such, specialized tooling and build steps aren't required.
 * PO files work well with collaborative online editing tools.
@@ -447,6 +449,7 @@ This article walks through the steps for using Portable Object (PO) files in an
 ## What is a PO file?
 
 PO files are distributed as text files containing the translated strings for a given language. Some advantages of using PO files instead of *.resx* files include:
+
 * PO files support pluralization; *.resx* files don't support pluralization.
 * PO files aren't compiled like *.resx* files. As such, specialized tooling and build steps aren't required.
 * PO files work well with collaborative online editing tools.

aspnetcore/fundamentals/servers/yarp/config-files.md

@@ -90,9 +90,11 @@ Example:
 ### Routes
 
 The routes section is an unordered collection of route matches and their associated configuration. A route requires at least the following fields:
+
 * RouteId - a unique name
 * ClusterId - refers to the name of an entry in the clusters section.
 * Match - contains either a Hosts array or a Path pattern string. Path is an ASP.NET Core route template that can be defined as [explained here](/aspnet/core/fundamentals/routing#route-templates).
+
 Route matching is based on the most specific routes having highest precedence as described [here](/aspnet/core/fundamentals/routing#url-matching). Explicit ordering can be achieved using the `order` field, with lower values taking higher priority.
 
 [Headers](xref:fundamentals/servers/yarp/header-routing), [Authorization](xref:fundamentals/servers/yarp/authn-authz), [CORS](xref:fundamentals/servers/yarp/cors), and other route based policies can be configured on each route entry. For additional fields see [RouteConfig](xref:Yarp.ReverseProxy.Configuration.RouteConfig).

aspnetcore/fundamentals/servers/yarp/config-filters.md

@@ -16,6 +16,7 @@ ai-usage: ai-assisted
 YARP configuration for routes, clusters, and destinations can be loaded from [configuration files](xref:fundamentals/servers/yarp/config-files) or from [configuration providers](xref:fundamentals/servers/yarp/config-providers). Configuration filters can be used to modify that raw input before it's validated and applied.
 
 Filters can be used for a variety of purposes such as:
+
 * Supplementing config fields with data from other sources like the deployment environment
 * Applying system defaults
 * Applying common settings and enforce policies

aspnetcore/fundamentals/servers/yarp/config-providers.md

@@ -24,6 +24,7 @@ Configuration can be modified during the load sequence using [Configuration Filt
 
 ### Routes
 The routes section is an unordered collection of named routes. A route contains matches and their associated configuration. A route requires at least the following fields:
+
 * RouteId - a unique name
 * ClusterId - refers to the name of an entry in the clusters section.
 * Match - contains either a Hosts array or a Path pattern string. Path is an ASP.NET Core route template that can be defined as [explained here](/aspnet/core/fundamentals/routing#route-templates).
@@ -55,6 +56,7 @@ httpContext.RequestServices.GetRequiredService<InMemoryConfigProvider>().Update(
 
 ### Startup
 The `IProxyConfigProvider` should be registered in the DI container as a singleton. At startup, the proxy will resolve this instance and call `GetConfig()`. On this first call the provider may choose to:
+
 * Throw an exception if the provider cannot produce a valid proxy configuration for any reason. This will prevent the application from starting.
 * Synchronously block while it loads the configuration. This will block the application from starting until valid route data is available.
 * Or, it may choose to return an empty `IProxyConfig` instance while it loads the configuration in the background. The provider will need to trigger the `IChangeToken` when the configuration is available.
@@ -68,12 +70,14 @@ The configuration objects and collections supplied to the proxy should be read-o
 If the `IChangeToken` supports `ActiveChangeCallbacks`, once the proxy has processed the initial set of configurations it will register a callback with this token. If the provider does not support callbacks then `HasChanged` will be polled every 5 minutes.
 
 When the provider wants to provide a new configuration to the proxy it should:
+
 * Load that configuration in the background. 
-  - Route and cluster objects are immutable, so new instances have to be created for any new data.
-  - Objects for unchanged routes and clusters can be re-used, or new instances can be created - changes will be detected by diffing them.
+  * Route and cluster objects are immutable, so new instances have to be created for any new data.
+  * Objects for unchanged routes and clusters can be re-used, or new instances can be created - changes will be detected by diffing them.
 * Optionally validate the configuration using the [IConfigValidator](xref:Yarp.ReverseProxy.Configuration.IConfigValidator), and only then signal the `IChangeToken` from the prior `IProxyConfig` instance that new data is available. The proxy will call `GetConfig()` again to retrieve the new data.
 
 There are important differences when reloading configuration vs the first configuration load.
+
 * The new configuration will be diffed against the current one and only modified routes or clusters will be updated. The update will be applied atomically and will only affect new requests, not requests currently in progress.
 * Any errors in the reload process will be logged and suppressed. The application will continue using the last known good configuration.
 * If `GetConfig()` throws the proxy will be unable to listen for future changes because `IChangeToken`s are single-use.

aspnetcore/fundamentals/servers/yarp/destination-resolvers.md

@@ -26,6 +26,7 @@ YARP uses a destination resolver to expand the set of configured destination add
 
 ### Startup
 The `IDestinationResolver` should be registered in the DI container as a singleton. At startup, the proxy will resolve this instance and call `ResolveDestinationsAsync(...)` with the configured destinations retrieved from the resolved `IProxyConfigProviders`. On this first call the provider may choose to:
+
 * Throw an exception if the provider cannot produce a valid proxy configuration for any reason. This will prevent the application from starting.
 * Asynchronously resolve the destinations. This will stop the application from starting until resolved destinations are available.
 * Or, it may choose to return an empty `ResolvedDestinationCollection` instance while it resolves destinations in the background. The provider will need to trigger the `IChangeToken` when the configuration is available.
@@ -37,9 +38,10 @@ The destinations objects and collections supplied to the proxy should be read-on
 If the `IChangeToken` supports `ActiveChangeCallbacks`, once the proxy has processed the initial set of destinations it will register a callback with this token. If the provider does not support callbacks then `HasChanged` will be polled alongside `IProxyConfig` change tokens, every 5 minutes.
 
 When the provider wants to provide a new set of destinations to the proxy it should:
+
 * Resolve those destinations in the background.
-  - `ResolvedDestinationCollection` is immutable, so new instances have to be created for any new data.
-  - Objects for unchanged destinations can be re-used, or new instances can be created.
+  * `ResolvedDestinationCollection` is immutable, so new instances have to be created for any new data.
+  * Objects for unchanged destinations can be re-used, or new instances can be created.
 * Invalidate the `IChangeToken` returned from the previous `ResolveDestinationsAsync` invocation.
 
 Once the new destinations have been applied, the proxy will register a callback with the new `IChangeToken`. Note if there are multiple reloads signaled in close succession, the proxy may skip some and resolve destinations as soon as it's ready.

aspnetcore/fundamentals/servers/yarp/dests-health-checks.md

@@ -93,9 +93,10 @@ Active health check settings can also be defined in code via the corresponding t
 
 `Destination` section and [DestinationConfig](xref:Yarp.ReverseProxy.Configuration.DestinationConfig).
 
-* `Health` - A dedicated health probing endpoint such as `http://destination:12345/`. Defaults `null` and falls back to `Destination/Address`.
+`Health`: A dedicated health probing endpoint such as `http://destination:12345/`. Defaults `null` and falls back to `Destination/Address`.
 
 ### Built-in policies
+
 There is currently one built-in active health check policy - `ConsecutiveFailuresHealthPolicy`. It counts consecutive health probe failures and marks a destination as unhealthy once the given threshold is reached. On the first successful response, a destination is marked as healthy and the counter is reset.
 The policy parameters are set in the cluster's metadata as follows:
 
@@ -347,8 +348,8 @@ public class FirstUnsuccessfulResponseHealthPolicy : IPassiveHealthCheckPolicy
 Destinations health state is used to determine which of them are eligible for receiving proxied requests. Each cluster maintains its own list of available destinations on `AvailableDestinations` property of the [ClusterDestinationState](xref:Yarp.ReverseProxy.Model.ClusterDestinationsState) type. That list gets rebuilt when any destination's health state changes. The [IClusterDestinationsUpdater](xref:Yarp.ReverseProxy.Health.IClusterDestinationsUpdater) controls that process and calls an [IAvailableDestinationsPolicy](xref:Yarp.ReverseProxy.Health.IAvailableDestinationsPolicy) configured on the cluster to actually choose the available destinations from the all cluster's destinations. There are the following built-in policies provided and custom ones can be implemented if necessary.
 
 * `HealthyAndUnknown` - Inspects each `DestinationState` and adds it on the available destination list if all of the following statements are TRUE. If no destinations are available then requests will get a 503 error.
-    - Active health checks are disabled on the cluster OR `DestinationHealthState.Active != DestinationHealth.Unhealthy`
-    - Passive health checks are disabled on the cluster OR `DestinationHealthState.Passive != DestinationHealth.Unhealthy`
+    * Active health checks are disabled on the cluster OR `DestinationHealthState.Active != DestinationHealth.Unhealthy`
+    * Passive health checks are disabled on the cluster OR `DestinationHealthState.Passive != DestinationHealth.Unhealthy`
 * `HealthyOrPanic` - Calls `HealthyAndUnknown` policy at first to get the available destinations. If none of them are returned from this call, it marks all cluster's destinations as available. This is the default policy.
 
 **NOTE**: An available destination policy configured on a cluster will be always called regardless of if any health check is enabled on the given cluster. The health state of a disabled health check is set to `Unknown`.

aspnetcore/fundamentals/servers/yarp/direct-forwarding.md

@@ -19,13 +19,15 @@ Some applications only need the ability to take a specific request and forward i
 [IHttpForwarder](xref:Yarp.ReverseProxy.Forwarder.IHttpForwarder) serves as the core proxy adapter between incoming AspNetCore and outgoing System.Net.Http requests. It handles the mechanics of creating a HttpRequestMessage from a HttpContext, sending it, and relaying the response.
 
 IHttpForwarder supports:
+
 * Dynamic destination selection, you specify the destination for each request
 * Http client customization, you provide the HttpMessageInvoker
 * Request and response customization (except bodies)
 * Streaming protocols like gRPC and WebSockets
 * Error handling
 
 It does not include:
+
 * Routing
 * Load balancing
 * Affinity

aspnetcore/fundamentals/servers/yarp/header-routing.md

@@ -290,6 +290,7 @@ A list of possible values to search for. The header must match at least one of t
 ### Mode
 
 [HeaderMatchMode](xref:Yarp.ReverseProxy.Configuration.HeaderMatchMode) specifies how to match the value(s) against the request header. The default is `ExactHeader`.
+
 * ExactHeader - Any of the headers with the given name must match in its entirety, subject to the value of `IsCaseSensitive`. If a header contains multiple values (separated by `,` or `;`), they are split before matching. A single pair of quotes will also be stripped from the value before matching.
 * HeaderPrefix - Any of the headers with the given name must match by prefix, subject to the value of `IsCaseSensitive`. If a header contains multiple values (separated by `,` or `;`), they are split before matching. A single pair of quotes will also be stripped from the value before matching.
 * Exists - The header must exist and contain any non-empty value. If there are multiple headers with the same name, the rule will also match.