|
1 | 1 | --- |
2 | 2 | uid: fundamentals/servers/yarp/httpsys-delegation |
3 | | -title: YARP Http.sys Delegation |
4 | | -description: YARP Http.sys Delegation |
| 3 | +title: YARP HTTP.sys Delegation |
| 4 | +description: YARP HTTP.sys Delegation |
5 | 5 | author: samsp-msft |
6 | 6 | ms.author: samsp |
7 | 7 | ms.date: 2/6/2025 |
8 | 8 | ms.topic: article |
9 | 9 | content_well_notification: AI-contribution |
10 | 10 | ai-usage: ai-assisted |
11 | 11 | --- |
12 | | - |
13 | | -# YARP Http.sys Delegation |
| 12 | +# YARP HTTP.sys Delegation |
14 | 13 |
|
15 | 14 | ## Introduction |
16 | | -Http.sys delegation is a kernel level feature added into newer versions of Windows which allows a request to be transferred from the receiving process's http.sys queue to a target process's http.sys queue with very little overhead or added latency. For this delegation to work, the receiving process is only allowed to read the request headers. If the body has started to be read or a response has started, trying to delegate the request will fail. The response will not be visible to the proxy after delegation, which limits the functionality of the session affinity and passive health checks components, as well as some of the load balancing algorithms. Internally, YARP leverages ASP.NET Core's [IHttpSysRequestDelegationFeature](/dotnet/api/microsoft.aspnetcore.server.httpsys.ihttpsysrequestdelegationfeature) |
| 15 | + |
| 16 | +HTTP.sys delegation is a kernel level feature added into newer versions of Windows which allows a request to be transferred from the receiving process's HTTP.sys queue to a target process's HTTP.sys queue with very little overhead or added latency. For this delegation to work, the receiving process is only allowed to read the request headers. If the body has started to be read or a response has started, trying to delegate the request will fail. The response will not be visible to the proxy after delegation, which limits the functionality of the session affinity and passive health checks components, as well as some of the load balancing algorithms. Internally, YARP leverages ASP.NET Core's [IHttpSysRequestDelegationFeature](/dotnet/api/microsoft.aspnetcore.server.httpsys.ihttpsysrequestdelegationfeature) |
17 | 17 |
|
18 | 18 | ## Requirements |
19 | | -Http.sys delegation requires: |
20 | | -- [ASP.NET Core's Http.sys server](/aspnet/core/fundamentals/servers/httpsys) |
21 | | -- Windows Server 2019 or Windows 10 (build number 1809) or newer. |
| 19 | + |
| 20 | +HTTP.sys delegation requires: |
| 21 | + |
| 22 | +* [ASP.NET Core's HTTP.sys server](/aspnet/core/fundamentals/servers/httpsys) |
| 23 | +* Windows Server 2019 or Windows 10 (build number 1809) or newer. |
22 | 24 |
|
23 | 25 | ## Defaults |
24 | | -Http.sys delegation won't be used unless added to the proxy pipeline and enabled in the destination configuration. |
| 26 | + |
| 27 | +HTTP.sys delegation won't be used unless added to the proxy pipeline and enabled in the destination configuration. |
25 | 28 |
|
26 | 29 | ## Configuration |
27 | | -Http.sys delegation can be enabled per destination by adding the `HttpSysDelegationQueue` metadata to the destination. The value of this metadata should be the target http.sys queue name. The destination's Address is used to specify the url prefix of the http.sys queue. |
| 30 | + |
| 31 | +HTTP.sys delegation can be enabled per destination by adding the `HttpSysDelegationQueue` metadata to the destination. The value of this metadata should be the target HTTP.sys queue name. The destination's Address is used to specify the url prefix of the HTTP.sys queue. |
28 | 32 |
|
29 | 33 | ```json |
30 | 34 | { |
@@ -53,31 +57,35 @@ Http.sys delegation can be enabled per destination by adding the `HttpSysDelegat |
53 | 57 | } |
54 | 58 | ``` |
55 | 59 |
|
56 | | -In host configuration, configure the host to use the Http.sys server. |
57 | | -```c# |
| 60 | +In host configuration, configure the host to use the HTTP.sys server: |
| 61 | + |
| 62 | +```csharp |
58 | 63 | webBuilder.UseHttpSys(); |
59 | 64 | ``` |
60 | 65 |
|
61 | | -In application configuration, use the `MapReverseProxy` overload that lets you customize the pipeline and add http.sys delegation by calling `UseHttpSysDelegation`. |
62 | | -```c# |
| 66 | +In application configuration, use the `MapReverseProxy` overload that allows you to customize the pipeline and add HTTP.sys delegation by calling `UseHttpSysDelegation`: |
| 67 | + |
| 68 | +```csharp |
63 | 69 | app.MapReverseProxy(proxyPipeline => |
64 | 70 | { |
65 | | - // Add the three middleware YARP adds by default plus the Http.sys delegation middleware |
66 | | - proxyPipeline.UseSessionAffinity(); // Has no affect on delegation destinations |
| 71 | + // Add the three middleware YARP adds by default plus the HTTP.sys |
| 72 | + // delegation middleware |
| 73 | + proxyPipeline.UseSessionAffinity(); // No affect on delegation destinations |
67 | 74 | proxyPipeline.UseLoadBalancing(); |
68 | 75 | proxyPipeline.UsePassiveHealthChecks(); |
69 | 76 | proxyPipeline.UseHttpSysDelegation(); |
70 | 77 | }); |
71 | 78 | ``` |
72 | 79 |
|
73 | | -## Delegation Queue Lifetime |
74 | | -When YARP is configured to use delegation for a destination, a handle is created to the specified http.sys queue. This handle is kept alive as long as the destinations referencing it exist. Clean up of these handles is done during GC, so it's possible cleanup of the handle is delayed if it ends up in Gen2. This may cause issues for some receivers during process restart because if they try to create the queue during startup it will fail (because it still exists since YARP has a handle to it). The receivers need to be smart enough to attach instead and properly re-setup the queue. ASP.NET Core's http.sys server [has this issue](https://github.com/dotnet/aspnetcore/issues/40359). |
| 80 | +## Delegation queue lifetime |
| 81 | + |
| 82 | +When YARP is configured to use delegation for a destination, a handle is created to the specified HTTP.sys queue. This handle is kept alive as long as the destinations referencing it exist. Clean up of these handles is done during GC, so it's possible cleanup of the handle is delayed if it ends up in Gen2. This may cause issues for some receivers during process restart because if they try to create the queue during startup it fails because it still exists since YARP has a handle to it. The receivers must be smart enough to attach instead and properly re-setup the queue. ASP.NET Core's HTTP.sys server has this issue. For more information, see [Http.sys server should support setting up URL groups when attaching to an existing queue (`dotnet/aspnetcore` #40359)](https://github.com/dotnet/aspnetcore/issues/40359). |
75 | 83 |
|
76 | | -YARP exposes a way to reset its handle to the queue. This allows consumers to write custom logic to determin if/when the handle to the queue should be cleaned up. |
| 84 | +YARP exposes a way to reset its handle to the queue. This allows consumers to write custom logic to determine when the handle to the queue should be cleaned up. |
77 | 85 |
|
78 | 86 | Example: |
79 | 87 |
|
80 | | -```c# |
| 88 | +```csharp |
81 | 89 | var delegator = app.Services.GetRequiredService<IHttpSysDelegator>(); |
82 | 90 | delegator.ResetQueue("TargetHttpSysQueueName", "http://*:80"); |
83 | 91 | ``` |
0 commit comments