Corrected some spelling/wording in YARP node

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

@@ -32,7 +32,7 @@ By default ASP.NET will log to the console, and the configuration file can be us
   },
 ```
 
-You want logging infomation 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 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.
 
 > 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.
 
@@ -44,10 +44,10 @@ The logging output is directly tied to the way that ASP.NET Core processes reque
 | ----- | ----------- | ----------- |
 | dbug | Microsoft.AspNetCore.Server.Kestrel.Connections[39]<br>Connection id "0HMCD0JK7K51U" accepted.| Connections are independent of requests, so this is a new connection |
 | dbug | Microsoft.AspNetCore.Server.Kestrel.Connections[1]<br>Connection id "0HMCD0JK7K51U" started. | |
-| info | Microsoft.AspNetCore.Hosting.Diagnostics[1]<br>Request starting HTTP/1.1 GET http://localhost:5000/ - - | This is the incomming request to ASP.NET |
-| dbug | Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware[0]<br>Wildcard detected, all requests with hosts will be allowed. | My configuation does not tie endpoints to specific hostnames |
+| info | Microsoft.AspNetCore.Hosting.Diagnostics[1]<br>Request starting HTTP/1.1 GET http://localhost:5000/ - - | This is the incoming request to ASP.NET |
+| dbug | Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware[0]<br>Wildcard detected, all requests with hosts will be allowed. | My configuration does not tie endpoints to specific hostnames |
 | dbug | Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1001]<br>1 candidate(s) found for the request path '/' | This shows what possible matches there are for the route |
-| dbug | Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]<br>      Endpoint 'minimumroute' with route pattern '{\*\*catch-all}' is valid for the request path '/' | The mimimum route from YARPs configuration has matched|
+| dbug | Microsoft.AspNetCore.Routing.Matching.DfaMatcher[1005]<br>      Endpoint 'minimumroute' with route pattern '{\*\*catch-all}' is valid for the request path '/' | The minimum route from YARPs configuration has matched|
 | dbug | Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware[1]<br>     Request matched endpoint 'minimumroute' | |
 | info | Microsoft.AspNetCore.Routing.EndpointMiddleware[0]<br>      Executing endpoint 'minimumroute' | |
 | info | Yarp.ReverseProxy.Forwarder.HttpForwarder[9]<br>      Proxying to http://www.example.com/ | YARP is proxying the request to example.com |
@@ -155,7 +155,7 @@ public class ForwarderTelemetry : IForwarderTelemetryConsumer
     /// Called before forwarding a request from `ForwarderMiddleware`, therefore is not called for direct forwarding scenarios.
     public void OnForwarderInvoke(DateTime timestamp, string clusterId, string routeId, string destinationId)
     {
-        Console.WriteLine($"Forwarder Telemetry [{timestamp:HH:mm:ss.fff}] => OnForwarderInvoke:: Cluster id: {clusterId}, Route Id: { routeId}, Destination: {destinationId}");
+        Console.WriteLine($"Forwarder Telemetry [{timestamp:HH:mm:ss.fff}] => OnForwarderInvoke:: Cluster id: {clusterId}, Route Id: {routeId}, Destination: {destinationId}");
     }
 }
 ```

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

@@ -15,11 +15,11 @@ ai-usage: ai-assisted
 ## Introduction
 When proxying a request it's common to modify parts of the request or response to adapt to the destination server's requirements or to flow additional data such as the client's original IP address. This process is implemented via Transforms. Types of transforms are defined globally for the application and then individual routes supply the parameters to enable and configure those transforms. The original request objects are not modified by these transforms, only the proxy requests.
 
-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 transfrorms can be added.
+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
 
-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 easy of use.
+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.
 
 A request transform may conditionally produce an immediate response such as for error conditions. This prevents any remaining transforms from running and the request from being proxied. This is indicated by setting the `HttpResponse.StatusCode` to a value other than 200, or calling `HttpResponse.StartAsync()`, or writing to the `HttpResponse.Body` or `BodyWriter`.
 
@@ -45,7 +45,7 @@ All response trailers transforms must derive from the abstract base class [Respo
 
 ## Request body transforms
 
-YARP does not provide any built in transforms for modifying the request body. However, the body can be modified in custom transforms.
+YARP does not provide any built in transforms for modifying the request body. However, the body can be modified by custom transforms.
 
 Be careful about which kinds of requests are modified, how much data gets buffered, enforcing timeouts, parsing untrusted input, and updating the body-related headers like `Content-Length`.
 
@@ -76,7 +76,7 @@ This sample requires YARP 1.1, see https://github.com/microsoft/reverse-proxy/pu
 
 ## Response body transforms
 
-YARP does not provide any built in transforms for modifying the response body. However, the body can be modified in custom transforms.
+YARP does not provide any built in transforms for modifying the response body. However, the body can be modified by custom transforms.
 
 Be careful about which kinds of responses are modified, how much data gets buffered, enforcing timeouts, parsing untrusted input, and updating the body-related headers like `Content-Length`. You may need to decompress content before modifying it, as indicated by the Content-Encoding header, and afterwards re-compress it or remove the header.
 

aspnetcore/fundamentals/servers/yarp/extensibility.md

@@ -23,7 +23,7 @@ YARP uses the concept of [Routes](xref:fundamentals/servers/yarp/config-files#ro
 
 ![Middleware pipeline diagram](~/fundamentals/servers/yarp/media/yarp-pipeline.png)
 
-Most of the pre-built pipeline can be customized through code:
+Most of the prebuilt pipeline can be customized through code:
 
 - [Configuration Providers](xref:fundamentals/servers/yarp/config-providers)
 - [Destination Enumeration](xref:fundamentals/servers/yarp/destination-resolvers)
@@ -37,10 +37,10 @@ You can also change the pipeline definition to replace modules with your own imp
 
 ## Http Forwarder
 
-If the YARP pipeline is too rigid for your needs, 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 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.
 
 ![HTTP forwarder diagram](~/fundamentals/servers/yarp/media/yarp-forwarder.png)
 
-The transform component can still be used with the forwarder is needed.
+The transform component can still be used if the forwarder is needed.
 
 For more information see [Direct forwarding](xref:fundamentals/servers/yarp/direct-forwarding).

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

@@ -12,7 +12,7 @@ ai-usage: ai-assisted
 
 # 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 snippets. 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 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 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/).
 
@@ -24,7 +24,7 @@ You can download the .NET SDK from https://dotnet.microsoft.com/download/dotnet/
 
 A complete version of the project built using the steps below can be found at [Basic YARP Sample](https://github.com/microsoft/reverse-proxy/tree/release/latest/samples/BasicYarpSample).
 
-Start by creating an "Empty" ASP.NET Core application using the command line:
+Start by creating an empty ASP.NET Core application using the command line:
 
 ```dotnetcli
 dotnet new web -n MyProxy
@@ -97,6 +97,6 @@ Learn more about the available configuration options by looking at <xref:Yarp.Re
 
 ## Run the project
 
-When using the .NET CLU, use `dotnet run` called within the sample's directory or `dotnet run --project <path to .csproj file>`.
+When using the .NET CLI, use `dotnet run` within the sample's directory or `dotnet run --project <path to .csproj file>`.
 
-In Visual Studio, start the app with the **Run** button.
+In Visual Studio, start the app by clicking the **Run** button.

aspnetcore/fundamentals/servers/yarp/grpc.md

@@ -1,7 +1,7 @@
 ---
 uid: fundamentals/servers/yarp/grpc
-title: YARP Proxing gRPC
-description: YARP Proxing gRPC
+title: YARP Proxying gRPC
+description: YARP Proxying gRPC
 author: samsp-msft
 ms.author: samsp
 ms.date: 2/6/2025
@@ -10,7 +10,7 @@ content_well_notification: AI-contribution
 ai-usage: ai-assisted
 ---
 
-# YARP Proxing gRPC
+# YARP Proxying gRPC
 
 ## Introduction
 
@@ -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 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. See [here](http-client-config.md#httprequest) for configuration details.
+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).
 
 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 Headers
-description: YARP HTTP Headers
+title: YARP HTTP Header Guidelines
+description: YARP HTTP Header Guidelines
 author: samsp-msft
 ms.author: samsp
 ms.date: 2/6/2025
@@ -10,17 +10,17 @@ content_well_notification: AI-contribution
 ai-usage: ai-assisted
 ---
 
-# YARP HTTP Headers
+# 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 destination are independent, and so 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 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.
 
 ## 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
 
-These headers control how the TCP connection is managed and are removed to avoid impacting the connection on the other side of the proxy.
+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
 
@@ -45,7 +45,7 @@ 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` so that the forwarding HttpClient can replace them with updated values.
+They are automatically removed based on `DistributedContextPropagator.Fields`, allowing the forwarding HttpClient to replace them with updated values.
 You can opt out of modifying these headers by setting `SocketsHttpHandler.ActivityHeadersPropagator` to `null`:
 ```C#
 services.AddReverseProxy()
@@ -60,7 +60,7 @@ This header instructs clients to always use HTTPS, but there may be a conflict b
 
 ### 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 is configurable 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
 
@@ -72,7 +72,7 @@ Some clients and servers limit which HTTP methods they allow (GET, POST, etc.).
 
 ### Set-Cookie
 
-This response header may contain fields constraining 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 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.
 
 ### Location