Apply suggestions from code review

Author: guardrex

aspnetcore/fundamentals/servers/yarp/diagnosing-yarp-issues.md

@@ -32,9 +32,9 @@ By default ASP.NET will log to the console, and the configuration file can be us
   },
 ```
 
-You want logging information from the "Microsoft.AspNetCore.\*" and "Yarp.ReverseProxy.\*" providers. The example above will emit "Information" level events from both providers to the Console. Changing the level to "Debug" will show additional entries. ASP.NET implements change detection for configuration files, so you can edit the appsettings.json file (or appsettings.development.json if running from Visual Studio) while the project is running and observe changes to the log output.
+You want logging information from the `Microsoft.AspNetCore.\*` and `Yarp.ReverseProxy.\*` providers. The preceding example emits `Information`-level events from both providers to the console. Changing the level to `Debug` shows additional entries. ASP.NET implements change detection for configuration files, so you can edit the `appsettings.json` file (or `appsettings.development.json` for the `Development` environment) while the project is running and observe changes to the log output.
 
-> Note: Settings in the appsettings.development.json file will override settings in appsettings.json when running in development, so make sure that if you are editing appsettings.json that the values are not overridden.
+> Note: Settings in the `appsettings.development.jso`n file override settings in `appsettings.json` when running in the `Development` environment, so make sure that if you are editing `appsettings.json` that the values aren't overridden.
 
 ### Understanding Log entries
 

aspnetcore/fundamentals/servers/yarp/extensibility-transforms.md

@@ -17,7 +17,7 @@ When proxying a request it's common to modify parts of the request or response t
 
 YARP includes a set of built-in request and response transforms that can be used. See [Transforms](./transforms.md) for more details. If those transforms are not sufficient, then custom transforms can be added.
 
-## RequestTransform
+## `RequestTransform`
 
 All request transforms must derive from the abstract base class [RequestTransform](xref:fundamentals/servers/yarp/transforms). These can freely modify the proxy `HttpRequestMessage`. Avoid reading or modifying the request body as this may disrupt the proxying flow. Consider also adding a parametrized extension method on `TransformBuilderContext` for discoverability and ease of use.
 

aspnetcore/fundamentals/servers/yarp/extensibility.md

@@ -35,9 +35,9 @@ Most of the prebuilt pipeline can be customized through code:
 
 You can also change the pipeline definition to replace modules with your own implementation(s) 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 is not 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.
+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.
 
 ![HTTP forwarder diagram](~/fundamentals/servers/yarp/media/yarp-forwarder.png)
 

aspnetcore/fundamentals/servers/yarp/getting-started.md

@@ -10,9 +10,9 @@ content_well_notification: AI-contribution
 ai-usage: ai-assisted
 ---
 
-# Getting Started with YARP
+# Getting started with YARP
 
-YARP is designed as a library that provides the core proxy functionality which you can then customize by adding or replacing modules. YARP is currently provided as a NuGet package and code samples. We plan on providing a project template and prebuilt executable (`.exe`) in the future.
+YARP is designed as a library that provides the core proxy functionality, which you can customize by adding or replacing modules. YARP is currently provided as a NuGet package and code samples. We plan on providing a project template and prebuilt executable (`.exe`) in the future.
 
 YARP is implemented on top of .NET Core infrastructure and is usable on Windows, Linux or MacOS. Development can be done with the SDK and your favorite editor, [Microsoft Visual Studio](https://visualstudio.microsoft.com/vs/) or [Visual Studio Code](https://code.visualstudio.com/).
 

aspnetcore/fundamentals/servers/yarp/grpc.md

@@ -38,7 +38,7 @@ This shows configuring Kestrel to use HTTP/2 over http (non-TLS):
 
 ## Configure YARP's Outgoing Protocols
 
-YARP automatically negotiates HTTP/1.1 or HTTP/2 for outgoing proxy requests, but only for https (TLS). HTTP/2 over http (non-TLS) requires additional settings. Note that outgoing protocols are independent of incoming ones. E.g. https can be used for the incoming connection and http for the outgoing one, this is called TLS termination. For configuration details, see [here](http-client-config.md#httprequest).
+YARP automatically negotiates HTTP/1.1 or HTTP/2 for outgoing proxy requests, but only for https (TLS). HTTP/2 over http (non-TLS) requires additional settings. Note that outgoing protocols are independent of incoming ones. E.g. https can be used for the incoming connection and http for the outgoing one, this is called TLS termination. For configuration details, see <xref:fundamentals/servers/yarp/http-client-config#httprequest>.
 
 This shows configuring the outgoing proxy request to use HTTP/2 over http.
 ```json

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

@@ -1,7 +1,7 @@
 ---
 uid: fundamentals/servers/yarp/header-guidelines
-title: YARP HTTP Header Guidelines
-description: YARP HTTP Header Guidelines
+title: YARP HTTP header guidelines
+description: Learn about YARP HTTP header guidelines.
 author: samsp-msft
 ms.author: samsp
 ms.date: 2/6/2025
@@ -10,19 +10,19 @@ content_well_notification: AI-contribution
 ai-usage: ai-assisted
 ---
 
-# YARP HTTP Header Guidelines
+# YARP HTTP header guidelines
 
-Headers are a very important part of processing HTTP requests and each have their own semantics and considerations. Most headers are proxied by default, though some used to control how the request is delivered are automatically adjusted or removed by the proxy. The connections between the client and the proxy, and the proxy and the destination, are independent. Therefore, headers that affect the connection and transport need to be filtered. Many headers contain information like domain names, paths, or other details that may be affected when a reverse proxy is included in the application architecture. Below is a collection of guidelines about how specific headers might be impacted and what to do about them.
+Headers are a very important part of processing HTTP requests and each have their own semantics and considerations. Most headers are proxied by default, though some used to control how the request is delivered are automatically adjusted or removed by the proxy. The connections between the client and the proxy and between the proxy and the destination are independent. Therefore, headers that affect the connection and transport must be filtered. Many headers contain information like domain names, paths, or other details that may be affected when a reverse proxy is included in the application architecture. The following is a collection of guidelines about how specific headers might be impacted and what to do about them.
 
 ## YARP header filtering
 
 YARP automatically removes request and response headers that could impact its ability to forward a request correctly, or that may be used maliciously to bypass features of the proxy. A complete list can be found [here](https://github.com/microsoft/reverse-proxy/blob/main/src/ReverseProxy/Forwarder/RequestUtilities.cs#L71), with some highlights described below.
 
-### Connection, KeepAlive, Close
+### `Connection`, `KeepAlive`, `Close`
 
 These headers control how the TCP connection is managed and are removed to prevent impacting the connection on the other side of the proxy.
 
-### Transfer-Encoding
+### `Transfer-Encoding`
 
 This header describes the format of the request or response body on the wire, e.g. 'chunked', and is removed because the format can vary between the internal and external connection. The incoming and outgoing HTTP stacks will add transport headers as needed.
 
@@ -45,9 +45,9 @@ This response header is used with HTTP/3 upgrades and only applies to the immedi
 ### Distributed tracing headers
 
 These headers include TraceParent, Request-Id, TraceState, Baggage, Correlation-Context.
-They are automatically removed based on `DistributedContextPropagator.Fields`, allowing the forwarding HttpClient to replace them with updated values.
+They're automatically removed based on <xref:System.Diagnostics.DistributedContextPropagator.Fields%2A?displayProperty=nameWithType>, allowing the forwarding <xref:System.Net.Http.HttpClient> to replace them with updated values.
 You can opt out of modifying these headers by setting `SocketsHttpHandler.ActivityHeadersPropagator` to `null`:
-```C#
+```csharp
 services.AddReverseProxy()
     .ConfigureHttpClient((_, handler) => handler.ActivityHeadersPropagator = null);
 ```
@@ -58,23 +58,23 @@ This header instructs clients to always use HTTPS, but there may be a conflict b
 
 ## Other Header Guidelines
 
-### Host
+### `Host`
 
-The Host header indicates which site on the server the request is intended for. This header is removed by default since the host name used publicly by the proxy is likely to differ from the one used by the service behind the proxy. This can be configured using the [RequestHeaderOriginalHost](xref:fundamentals/servers/yarp/transforms#requestheaderoriginalhost) transform.
+The Host header indicates which site on the server the request is intended for. This header is removed by default since the host name used publicly by the proxy is likely to differ from the one used by the service behind the proxy. This can be configured using the [`RequestHeaderOriginalHost`](xref:fundamentals/servers/yarp/transforms#requestheaderoriginalhost) transform.
 
-### X-Forwarded-*, Forwarded
+### `X-Forwarded-*`, `Forwarded`
 
 Because a separate connection is used to communicate with the destination, these request headers can be used to forward information about the original connection like the IP, scheme, port, client certificate, etc.. X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host, and X-Forwarded-Prefix are enabled by default. This information is subject to spoofing attacks so any existing headers on the request are removed and replaced by default. The destination app should be careful about how much trust it places in these values. See [transforms](xref:fundamentals/servers/yarp/transforms#defaults) for configuring these in the proxy. See the [ASP.NET docs](/aspnet/core/host-and-deploy/proxy-load-balancer) for configuring the destination app to read these headers.
 
 ### X-http-method-override, x-http-method, x-method-override
 
 Some clients and servers limit which HTTP methods they allow (GET, POST, etc.). These request headers are sometimes used to work around those restrictions. These headers are proxied by default. If in the proxy you want to prevent these bypasses then use the [RequestHeaderRemove](xref:fundamentals/servers/yarp/transforms#requestheaderremove) transform.
 
-### Set-Cookie
+### `Set-Cookie`
 
-This response header may contain fields that constrain the path, domain, scheme, etc. where the cookie should be used. Using a reverse proxy may change the effective domain, path, or scheme of a site from the public view. While it would be possible to [rewrite](https://github.com/microsoft/reverse-proxy/issues/1109) response cookies using custom transforms, it's recommended instead to use the Forwarded headers described above to flow the correct values to the destination app so it can generate the correct set-cookie headers.
+This response header may contain fields that constrain aspects of the URL, such as the scheme, domain, or path, where the cookie should be used. Using a reverse proxy may change the effective scheme, domain, or path of a site from the public view. While it would be possible to [rewrite response cookies using custom transforms](https://github.com/microsoft/reverse-proxy/issues/1109), we recommended instead to use the `Forwarded` headers described earlier to flow the correct values to the destination app so it can generate the correct `set-cookie` headers.
 
-### Location
+### `Location`
 
 This response header is used with redirects and may contain a scheme, domain, and path that differ from the public values due to the use of the proxy. While it would be possible to [rewrite](https://github.com/microsoft/reverse-proxy/discussions/466) the Location header using custom transforms, it's recommended instead to use the Forwarded headers described above to flow the correct values to the destination app so it can generate the correct Location headers. 
 

aspnetcore/fundamentals/servers/yarp/yarp-overview.md

@@ -20,7 +20,7 @@ YARP (Yet Another Reverse Proxy) is a highly customizable reverse proxy library
 
 A reverse proxy is a server that sits between client devices and backend servers. It forwards client requests to the appropriate backend server and then returns the server's response to the client. A reverse proxy provides several benefits:
 
-- Routing: Directs requests to different backend servers based on predefined rules, such as URL patterns or request headers. For example, `/images`, `/api`, `/db` requests can be routed image, api, and database servers.
+- Routing: Directs requests to different backend servers based on predefined rules, such as URL patterns or request headers. For example, `/images`, `/api`, and `/db` requests can be routed image, api, and database servers.
 - Load Balancing: Distributes incoming traffic across multiple backend servers to prevent overloading a specific server. Distribution increases performance and reliability.
 - Scalability: By distributing traffic across multiple servers, a reverse proxy helps scale apps to handle more users and higher loads. Backend servers scaled (added or removed) without impacting the client.