[release-notes] ASP.NET Core in .NET 11 Preview 4

[danroth27]

ASP.NET Core release notes for .NET 11 Preview 4.

Targets the milestone base branch #10388. Merging this PR
into release-notes/11.0-preview4 adds aspnetcore.md to the milestone.

Generated end-to-end by the release-notes skill. AI-authored content;
please review for accuracy, resolve any inline <!-- TODO --> placeholders,
and then mark this PR ready for review.

cc @danroth27

[danroth27]

Update: pulling the Blazor Gateway section back out of the Preview 4 release notes for now. The package isn't being produced on the build feeds — root cause turned out to be that Microsoft.NET.Sdk.Web defaults IsPackable to false, so the Gateway project's Pack target silently no-ops despite IsShippingPackage=true and a custom NuspecFile. One-line fix is up at dotnet/aspnetcore#66579, but it won't make Preview 4. We'll bring the content back once the package actually ships.

[BrennanConroy]

cc @agocke in case you want to provide input on the messaging here.

[danroth27]

@BrennanConroy This is what copilot came up with for a snippet for UseTlsClientHelloListener. Does it look ok?

[BrennanConroy]

https://github.com/dotnet/aspnetcore/blob/05434a9e554a75c887f204d08849fba337488dc3/src/Servers/Kestrel/Core/src/ListenOptionsHttpsExtensions.cs#L287

This must be called before UseHttps()

[halter73]

Suggested change

	listenOptions.UseHttps();
	listenOptions.UseTlsClientHelloListener((connection, clientHelloBytes) =>
	{
	// Inspect the ClientHello (SNI, ALPN, etc.) for diagnostics or routing.
	});
	});
	// This must be called before UseHttps()
	listenOptions.UseTlsClientHelloListener((connection, clientHelloBytes) =>
	{
	// Inspect the ClientHello (SNI, ALPN, etc.) for diagnostics or routing.
	})
	listenOptions.UseHttps();
	});

[halter73]

Should we call out this was backported to 10.0.8?

Suggested change

	When a minimal API endpoint has any filters or filter factories configured, the filter pipeline now runs even if parameter binding fails ([dotnet/aspnetcore #64539](https://github.com/dotnet/aspnetcore/pull/64539)). Filters can read `HttpContext.Response.StatusCode == 400` and substitute their own response body. Endpoints without filters continue to short-circuit with a 400 as before. In Development, set `RouteHandlerOptions.ThrowOnBadRequest = false` so the framework returns a 400 the filter can observe instead of throwing `BadHttpRequestException` to the developer exception page.
	When a minimal API endpoint has any filters or filter factories configured, the filter pipeline now runs even if parameter binding fails ([dotnet/aspnetcore #64539](https://github.com/dotnet/aspnetcore/pull/64539)). Filters can read `HttpContext.Response.StatusCode == 400` and substitute their own response body.
	In the `Development` environment, set `RouteHandlerOptions.ThrowOnBadRequest = false` so the framework returns a 400 the filter can observe instead of throwing `BadHttpRequestException` to the developer exception page. This is already the default in non-`Development` environments.
	This change was has also been backported to 10.0.8.

I also don't think the short-circuit bit adds anything, because what's being short circuited? The non-existent filters? The endpoint gets skipped with or without filters.

[halter73]

Suggested change

OpenAPI document generation now recognizes [HTTP QUERY](https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/) as a first-class operation type ([dotnet/aspnetcore #65714](https://github.com/dotnet/aspnetcore/pull/65714)). QUERY is a proposed safe, idempotent method that lets clients send a request body when describing a search — useful when a query is too large or too structured to fit in a URL. Routing already accepted arbitrary verb strings via `MapMethods`; this change makes QUERY endpoints show up correctly in the generated OpenAPI document so client generators and API explorers can consume them.

OpenAPI document generation now recognizes [HTTP QUERY](https://datatracker.ietf.org/doc/draft-ietf-httpbis-safe-method-w-body/) as a known operation type ([dotnet/aspnetcore #65714](https://github.com/dotnet/aspnetcore/pull/65714)). QUERY is a proposed safe, idempotent method that lets clients send a request body when describing a search — useful when a query is too large or too structured to fit in a URL. Routing already accepted arbitrary verb strings via `MapMethods`; this change makes QUERY endpoints show up correctly in the generated OpenAPI document so client generators and API explorers can consume them.

Because you know someone is going to call us out for calling it "first-class" and not adding MapQuery() or [HttpQuery].