Add linefeed line terminator switch

[sebastienros]

Adding support for https://www.rfc-editor.org/rfc/rfc7230.html#section-3.5 via an app switch.

Although the line terminator for the start-line and header fields is
the sequence CRLF, a recipient MAY recognize a single LF as a line
terminator and ignore any preceding CR.

Description:

The HTTP specification allows servers to support a single LF as line terminator (on top of CR/LF). Azure App Service has been deploying Yarp as their front-end and faces clients trying to use this capability.
The PR is adding an optional switch to enable the feature.

Regression?

No

Risk:

The feature is enabled by a switch, existing applications are not impacted.

Verification:

Updated unit tests and verified by App Service.

[ghost]

Hi @sebastienros. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[BrennanConroy]

Really should start PRs on main since it's easier to remember to backport than it is to remember to forward port.

[sebastienros]

I agree but it's more a question of deadline here. I needed to get a local build ready for testing before it is even merged.

[sebastienros]

/backport to main

[github-actions]

Started backporting to main: https://github.com/dotnet/aspnetcore/actions/runs/2192179026

[halter73]

Do we have any benchmarks with a bunch of request headers before and after?

[dougbu]

@sebastienros what is the status of this PR❔ I see neither a servicing-approved label nor team approval.

[sebastienros]

Plaintext platform with full pgo, default settings.

| application                             | base       | pr         |         |
| --------------------------------------- | ---------- | ---------- | ------- |
| CPU Usage (%)                           |         99 |         99 |   0.00% |
| Cores usage (%)                         |      2,783 |      2,782 |  -0.04% |
| Working Set (MB)                        |        126 |        126 |   0.00% |
| Private Memory (MB)                     |      1,167 |      1,166 |  -0.09% |
| Build Time (ms)                         |      2,956 |      3,009 |  +1.79% |
| Start Time (ms)                         |        473 |        487 |  +2.96% |
| Published Size (KB)                     |     97,117 |     97,117 |   0.00% |
| .NET Core SDK Version                   |    6.0.202 |    6.0.202 |         |
| Max CPU Usage (%)                       |         99 |         99 |   0.00% |
| Max Working Set (MB)                    |        131 |        131 |   0.00% |
| Max GC Heap Size (MB)                   |         65 |         63 |  -3.08% |
| Size of committed memory by the GC (MB) |          0 |          0 |         |
| Max Number of Gen 0 GCs / sec           |       0.00 |       0.00 |         |
| Max Number of Gen 1 GCs / sec           |       0.00 |       0.00 |         |
| Max Number of Gen 2 GCs / sec           |       0.00 |       0.00 |         |
| Max Time in GC (%)                      |       0.00 |       0.00 |         |
| Max Gen 0 Size (B)                      |          0 |          0 |         |
| Max Gen 1 Size (B)                      |          0 |          0 |         |
| Max Gen 2 Size (B)                      |          0 |          0 |         |
| Max LOH Size (B)                        |          0 |          0 |         |
| Max POH Size (B)                        |          0 |          0 |         |
| Max Allocation Rate (B/sec)             | 29,020,464 | 27,898,704 |  -3.87% |
| Max GC Heap Fragmentation               |          0 |          0 |         |
| # of Assemblies Loaded                  |         62 |         62 |   0.00% |
| Max Exceptions (#/s)                    |      2,277 |      2,157 |  -5.27% |
| Max Lock Contention (#/s)               |        288 |        384 | +33.33% |
| Max ThreadPool Threads Count            |         48 |         48 |   0.00% |
| Max ThreadPool Queue Length             |        617 |        621 |  +0.65% |
| Max ThreadPool Items (#/s)              |    728,087 |    718,173 |  -1.36% |
| Max Active Timers                       |          1 |          1 |   0.00% |
| IL Jitted (B)                           |    483,230 |    483,989 |  +0.16% |
| Methods Jitted                          |      7,886 |      7,887 |  +0.01% |


| load                   | base        | pr          |        |
| ---------------------- | ----------- | ----------- | ------ |
| CPU Usage (%)          |          93 |          93 |  0.00% |
| Cores usage (%)        |       2,612 |       2,614 | +0.08% |
| Working Set (MB)       |          38 |          38 |  0.00% |
| Private Memory (MB)    |         370 |         370 |  0.00% |
| Start Time (ms)        |           0 |           0 |        |
| First Request (ms)     |         110 |         108 | -1.82% |
| Requests/sec           |  10,932,215 |  10,926,610 | -0.05% |
| Requests               | 165,062,656 | 164,988,832 | -0.04% |
| Mean latency (ms)      |        1.51 |        1.46 | -3.31% |
| Max latency (ms)       |       70.41 |       72.23 | +2.58% |
| Bad responses          |           0 |           0 |        |
| Socket errors          |           0 |           0 |        |
| Read throughput (MB/s) |    1,310.72 |    1,310.72 |  0.00% |
| Latency 50th (ms)      |        0.76 |        0.76 |  0.00% |
| Latency 75th (ms)      |        1.17 |        1.16 | -0.85% |
| Latency 90th (ms)      |        2.26 |        2.23 | -1.33% |
| Latency 99th (ms)      |       16.80 |       15.83 | -5.77% |

[halter73]

Plaintext platform with full pgo, default settings.

For these kinds of changes, we should also be running the microbenchmarks in HttpParserBenchmark.cs.

[halter73]

I'm HUGE fan of the updated code! It's a lot cleaner than it was before while also adding the new switch. Do we have any perf numbers for the latest changes? I suspect it's as fast or faster than before, but I want to verify.

@dougbu I just discussed this with @sebastienros. We think the internal customer who wants this switch can test this out from an internal feed first. That would increase our confidence in these changes. As of right now, we've only been able to test this by manually crafting invalid requests that we think look like requests a real client might send. We haven't been able to test this with a request from a real client or even a replay of a request from a real client.

[mmitche]

Reminder that code complete is today.

[Pilchie]

Removing servicing-approved and putting back in 6.0.x, since we decided not to include this in 6.0.6

[dougbu]

Please let me know if and when this gets servicing-approved

[sebastienros]

@dougbu Will submit a new request for next service release, and I also need to update it. It's currently being tested internally.

[dougbu]

I also need to update it.

At this point you also have conflicts. That'll help me remember not to merge until all t's are dotted and i's crossed 😃

[dougbu]

We have a slight hold up in opening the release/6.0 branch but I'm wondering if this PR will be ready as soon as that happens. Currently hitting merge conflicts and I don't see a servicing-approved label from Tactics.

[dougbu]

@sebastienros @adityamandaleeka are we trying to get this into 6.0.9❔ Need to resolve conflicts if so

[halter73]

Suggested change

	_enableLineFeedTerminator = AppContext.TryGetSwitch("Microsoft.AspNetCore.Server.Kestrel.EnableLineFeedTerminator", out var enabled) && enabled;
	_allowHttp1LineFeedTerminators = AppContext.TryGetSwitch("Microsoft.AspNetCore.Server.Kestrel.AllowHttp1LineFeedTerminators", out var enabled) && enabled;

[dougbu]

Please resolve the conflicts if this is going into 6.0.10