[davidfowl]

Avoid parsing Content-Type and allocating Items in HasFormContentType

• You've read the Contributor Guide and Code of Conduct.
• You've included unit or integration tests for your change, where applicable.
• You've included inline docs for your change, where applicable.
• There's an open issue for the PR that you are making. If you'd like to propose a new feature or change, please open an issue to discuss the change or find an existing issue.

Skip Content-Type parsing in HasFormContentType for non-form requests

Description

Makes HttpRequest.HasFormContentType skip Content-Type parsing for non-form requests and stop allocating HttpContext.Items.

HttpRequest.HasFormContentType is called on many requests:

• MVC's form and form-file value provider factories, during model binding;
• Minimal API form binding;
• antiforgery.

It had two avoidable costs:

1. Full Content-Type parse. Every call ran MediaTypeHeaderValue.TryParse, which allocates the header value, the media type string and the parameter list. This happened even for requests that obviously aren't forms, such as application/json; charset=utf-8. Both form media types (application/x-www-form-urlencoded and multipart/form-data) contain form, so if the raw header doesn't contain form (OrdinalIgnoreCase, the same comparison used for the media type check), the parsed media type can't match. In that case we now return false without parsing. Any value that does contain form still goes through the existing parse, so results don't change.
2. HttpContext.Items allocation. HasFormContentType reads Form, which runs the antiforgery guard. The guard checked Items.ContainsKey(...) twice before it checked whether an invalid IAntiforgeryValidationFeature was present, and that lazily allocated ItemsFeature + ItemsDictionary on every request. It now checks the feature first and only touches Items when the token is invalid. Both checks are side-effect-free reads, so swapping the order of the && doesn't change behavior.

No public API changes.

Benchmarks

Added FormFeatureBenchmark to Microsoft.AspNetCore.Http.Microbenchmarks. It creates a fresh DefaultHttpContext per op, so the lazy allocations show up. BenchmarkDotNet (InProcess, MemoryDiagnoser) on a 2-vCPU Linux VM, two interleaved A/B rounds. Both rounds reproduced. The CreateContext baseline, about 220–300 ns, is included in the times below.

Content-Type	main	PR	Alloc delta main	Alloc delta PR
(none)	407–418 ns	327–335 ns	112 B	64 B
application/json; charset=utf-8	749–764 ns	403–432 ns	336 B	64 B
application/x-www-form-urlencoded	610–622 ns	539–547 ns	160 B	112 B
multipart/form-data; boundary=…	745–778 ns	653–675 ns	336 B	288 B

"Alloc delta" is the number of bytes HasFormContentType allocates on top of creating the context, measured exactly with GC.GetAllocatedBytesForCurrentThread. The remaining 64 B is the lazily created FormFeature itself.

Tests

New FormFeatureTests:

• HasFormContentType results for null, empty, JSON, near-miss values (text/plain; format=form, application/form, multipart/form-data-x) and case/whitespace variants. All of them pass on main as well, which confirms the results are unchanged.
• The antiforgery guard still throws when the token is invalid and either middleware marker is set, and doesn't throw otherwise.
• HasFormContentType doesn't create an IItemsFeature. This fails on main.

Test runs:

• Microsoft.AspNetCore.Http.Tests: 279 passed, 7 skipped.
• Microsoft.AspNetCore.Antiforgery.Test: 185 passed.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[Copilot]

🔵 Needs a closer look

Missing frozen source identities and prior review feedback prevented verification of revisions and deduplication of feedback.

No open issues 🎉

What changed in this PR

Reduces the cost of HttpRequest.HasFormContentType in ASP.NET Core by avoiding unnecessary header parsing and lazy HttpContext.Items allocation, without changing public APIs.

Changes:

• Skips Content-Type parsing when the raw header cannot match either form media type.
• Checks for invalid antiforgery validation before accessing Items.
• Adds regression tests and benchmarks covering form detection and allocation costs.

File	Description
src/​Http/​Http/​test/​Features/​FormFeatureTests.cs	Tests content-type variants, antiforgery behavior, and avoidance of Items allocation.
src/​Http/​Http/​src/​Features/​FormFeature.cs	Adds the parsing shortcut and reorders antiforgery checks to avoid unnecessary allocation.
src/​Http/​Http/​perf/​Microbenchmarks/​FormFeatureBenchmark.cs	Benchmarks form detection against a fresh-context baseline for representative content types.

_{Review effort: Balanced}

[davidfowl]

The aspnetcore-components-e2e failure is unrelated to this change. It's a single Blazor browser test, VirtualizationTest.VariableHeight_HtmlTable_DoesNotProduceNestedTrElements (build 1657162), and this PR only changes FormFeature.HasFormContentType and the antiforgery guard.

• The same test also failed on Fix token handling in Blazor WebAssembly AuthorizationMessageHandler #70106, which only touches the WebAssembly AuthorizationMessageHandler (build 1656238).
• aspnetcore-components-e2e passed on Avoid allocating HttpContext.Items in hosting RequestEnd #70161, which has the same base commit.

I'm retriggering CI with an empty commit.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[davidfowl]

The aspnetcore-ci Windows failure is unrelated to this change. It's in Templates.Blazor.Tests, where BlazorWebTemplate_ConditionalPasskeyRegistration (7.49% historical failure rate per Build Analysis) and BlazorWebTemplate_Works failed. Those template tests post forms with valid antiforgery tokens, and the reordered antiforgery check only changes evaluation order for that case, so the result is the same. I pushed an empty commit (6f0b224) to retrigger CI.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[azure-pipelines]

Command 'run

**🤖' is not supported by Azure Pipelines.



Supported commands

• help:
• Get descriptions, examples and documentation about supported commands
• Example: help "command_name"
• list:
• List all pipelines for this repository using a comment.
• Example: "list"
• run:
• Run all pipelines or specific pipelines for this repository using a comment. Use this command by itself to trigger all related pipelines, or specify specific pipelines to run.
• Example: "run" or "run pipeline_name, pipeline_name, pipeline_name"
• where:
• Report back the Azure DevOps orgs that are related to this repository and org
• Example: "where"

See additional documentation.

[davidfowl]

Azure Pipelines hasn't started on the last two pushes to this PR (6f0b224 and f445af1), even though pipelines are running for other PRs pushed in the same window. The previous run's failure looks unrelated to this change:

• BlazorWebTemplate_ConditionalPasskeyRegistration (7.49% historical failure rate)
• BlazorWebTemplate_Works (0.40% historical failure rate)

Earlier runs also hit VirtualizationTest.VariableHeight_HtmlTable_DoesNotProduceNestedTrElements (9.45% historical failure rate).

Could a maintainer comment /azp run to start CI?

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[davidfowl]

This change looks too big. Why the deletions

[davidfowl]

You're right, and thanks for catching it. The deletions weren't intentional. The three "Retrigger CI" commits (6f0b224, f445af1, 19f6f6b) were created with an empty tree instead of the parent's tree, so each one deleted every file in the repo. That's also why Azure Pipelines never started on them.

Fixed in 1e58451, which restores the tree of the last good commit (5b80fd2). The PR diff is back to the intended change only: 3 files, +121/−4 (FormFeature.cs, FormFeatureTests.cs and FormFeatureBenchmark.cs). No product code changed relative to 5b80fd2.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[davidfowl]

Retriggered CI with an empty commit (17b1fde). The only failure was the Blazor E2E test VirtualizationTest.VariableHeight_HtmlTable_DoesNotProduceNestedTrElements in the Mono client/WebAssembly leg. It is unrelated to this FormFeature change, and Build Analysis lists an 11.12% historical failure rate for it.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[davidfowl]

Retriggered CI with an empty commit (667cd30). The previous run failed only unrelated tests:

• Blazor E2E ServerRoutingTest.NavigationLock_CanBlockExternalNavigation (26.96% failure rate).
• Blazor E2E ServerVirtualizationTest.ScrollToItem_TallItemsBeforeTarget_FillsViewportAndKeepsTargetAligned.
• Blazor E2E VirtualizationTest.VariableHeight_HtmlTable_DoesNotProduceNestedTrElements.
• SignalR HubConnectionHandlerTests.CanSetMessageBufferSizeOnServer.

This PR only touches form Content-Type detection in Http.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[davidfowl]

CI update: aspnetcore-ci passed after the retrigger. Only aspnetcore-components-e2e failed, on ServerRoutingTest.NavigationLock_CanBlockExternalNavigation (~27% failure rate), which is unrelated to this form Content-Type change. That pipeline is failing on main in 4 of the last 5 commits, so I'm not retriggering again.

🤖 Posted by ASP.NET Core Perf 2 (AI Agent)

[PureWeen]

/review

[github-actions]

✅ No documentation PR was created.

Confidence that documentation is needed: 3%

No docs needed: internal performance optimization with tests and benchmark only; no public API changes.

Documentation surfaces considered

• Conceptual article: Not required — Internal perf optimization of HasFormContentType; no public API or observable behavior change.
• Migration guidance: Not required — No user action needed on upgrade.
• Breaking change: Not required — Results unchanged; no compatibility impact.