Updated incorrect list bullets in YARP node

Author: benhopkinstech

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

@@ -90,9 +90,9 @@ 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).
+* 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,11 +16,11 @@ 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
-- Substituting placeholder values
-- Normalization and error correction
+* Supplementing config fields with data from other sources like the deployment environment
+* Applying system defaults
+* Applying common settings and enforce policies
+* Substituting placeholder values
+* Normalization and error correction
 
 ## AddConfigFilter
 Configuration filters are registered in the Dependency Injection system using the [AddConfigFilter](xref:Microsoft.Extensions.DependencyInjection.ReverseProxyServiceCollectionExtensions) API. Any number of unique filters can be added and will be applied in the order added.

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

@@ -24,9 +24,9 @@ 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).
+* 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).
 
 [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).
 
@@ -55,9 +55,9 @@ 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.
+* 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.
 
 The proxy will validate the given configuration and if it's invalid, an exception will be thrown that prevents the application from starting. The provider can avoid this by using the [IConfigValidator](xref:Yarp.ReverseProxy.Configuration.IConfigValidator) to pre-validate routes and clusters and take whatever action it deems appropriate such as excluding invalid entries.
 
@@ -68,15 +68,15 @@ 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. 
+* 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.
-- 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.
+* 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.
+* 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.
 
 Once the new configuration has been validated and 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 load the next available configuration as soon as it's ready. Each `IProxyConfig` contains the full configuration state so nothing will be lost.
 

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

@@ -26,9 +26,9 @@ 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.
+* 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.
 
 ### Atomicity
 The destinations objects and collections supplied to the proxy should be read-only and not modified once they have been handed to the proxy via `GetConfig()`.
@@ -37,10 +37,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.
+* 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.
-- Invalidate the `IChangeToken` returned from the previous `ResolveDestinationsAsync` invocation.
+* 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

@@ -84,16 +84,16 @@ Active health check settings can also be defined in code via the corresponding t
 
 `Cluster/HealthCheck/Active` section and [ActiveHealthCheckConfig](xref:Yarp.ReverseProxy.Configuration.ActiveHealthCheckConfig):
 
-- `Enabled`: Flag indicating whether active health check is enabled for a cluster. Default `false`
-- `Interval`: Period of sending health probing requests. Default `00:00:15`
-- `Timeout`: Probing request timeout. Default `00:00:10`
-- `Policy`: Name of a policy evaluating destinations' active health states. Mandatory parameter
-- `Path`: Health check path on all cluster's destinations. Default `null`.
-- `Query`: Health check query on all cluster's destinations. Default `null`.
+* `Enabled`: Flag indicating whether active health check is enabled for a cluster. Default `false`
+* `Interval`: Period of sending health probing requests. Default `00:00:15`
+* `Timeout`: Probing request timeout. Default `00:00:10`
+* `Policy`: Name of a policy evaluating destinations' active health states. Mandatory parameter
+* `Path`: Health check path on all cluster's destinations. Default `null`.
+* `Query`: Health check query on all cluster's destinations. Default `null`.
 
 `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.
@@ -264,19 +264,19 @@ endpoints.MapReverseProxy(proxyPipeline =>
 
 `Cluster/HealthCheck/Passive` section and [PassiveHealthCheckConfig](xref:Yarp.ReverseProxy.Configuration.PassiveHealthCheckConfig):
 
-- `Enabled` - flag indicating whether passive health check is enabled for a cluster. Default `false`
-- `Policy` - name of a policy evaluating destinations' passive health states. Mandatory parameter
-- `ReactivationPeriod` - period after which an unhealthy destination's passive health state is reset to `Unknown` and it starts receiving traffic again. Default value is `null` which means the period will be set by a `IPassiveHealthCheckPolicy`
+* `Enabled` - flag indicating whether passive health check is enabled for a cluster. Default `false`
+* `Policy` - name of a policy evaluating destinations' passive health states. Mandatory parameter
+* `ReactivationPeriod` - period after which an unhealthy destination's passive health state is reset to `Unknown` and it starts receiving traffic again. Default value is `null` which means the period will be set by a `IPassiveHealthCheckPolicy`
 
 ### Built-in policies
 There is currently one built-in passive health check policy - [`TransportFailureRateHealthPolicy`](xref:Yarp.ReverseProxy.Health.TransportFailureRateHealthPolicyOptions). It calculates the proxied requests failure rate for each destination and marks it as unhealthy if the specified limit is exceeded. Rate is calculated as a percentage of failed requests to the total number of request proxied to a destination in the given period of time. Failed and total counters are tracked in a sliding time window which means that only the recent readings fitting in the window are taken into account.
 There are two sets of policy parameters defined globally and on per cluster level.
 
 Global parameters are set via the options mechanism using `TransportFailureRateHealthPolicyOptions` type with the following properties:
 
-- `DetectionWindowSize` - period of time while detected failures are kept and taken into account in the rate calculation. Default is `00:01:00`.
-- `MinimalTotalCountThreshold` - minimal total number of requests which must be proxied to a destination within the detection window before this policy starts evaluating the destination's health and enforcing the failure rate limit. Default is `10`.
-- `DefaultFailureRateLimit` - default failure rate limit for a destination to be marked as unhealthy that is applied if it's not set on a cluster's metadata. The value is in range `(0,1)`. Default is `0.3` (30%).
+* `DetectionWindowSize` - period of time while detected failures are kept and taken into account in the rate calculation. Default is `00:01:00`.
+* `MinimalTotalCountThreshold` - minimal total number of requests which must be proxied to a destination within the detection window before this policy starts evaluating the destination's health and enforcing the failure rate limit. Default is `10`.
+* `DefaultFailureRateLimit` - default failure rate limit for a destination to be marked as unhealthy that is applied if it's not set on a cluster's metadata. The value is in range `(0,1)`. Default is `0.3` (30%).
 
 Global policy options can be set in code as follows:
 ```csharp
@@ -346,10 +346,10 @@ public class FirstUnsuccessfulResponseHealthPolicy : IPassiveHealthCheckPolicy
 ## Available destination collection
 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.
+* `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`
-- `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.
+* `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,17 +19,17 @@ 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
+* 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
-- Retries
+* Routing
+* Load balancing
+* Affinity
+* Retries
 
 ## Example
 

aspnetcore/fundamentals/servers/yarp/distributed-tracing.md

@@ -21,8 +21,8 @@ As an ASP.NET Core component, YARP can easily integrate into different tracing s
 YARP supports distributed tracing using Open Telemetry (OTEL). When a request comes in, and there is a listener for Activities, then ASP.NET Core will propagate the [Trace Context](https://www.w3.org/TR/trace-context) trace-id, or create one if necessary, and create new spans/activities for the work performed.
 In addition YARP can create activities for:
 
-- Forwarding Requests
-- Active health checks for clusters
+* Forwarding Requests
+* Active health checks for clusters
 
 These will only be created if there is a listener for the [`ActivitySource`](/dotnet/core/diagnostics/distributed-tracing-instrumentation-walkthroughs#activitysource) named `Yarp.ReverseProxy`.