Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

v11 update: Kestrel applies trailer header timeouts

Aperta Adatta ai principianti
  • Qualcosa non va?
#37,725 0 commenti 1 reazione 2 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@guardrex ci sta già lavorando.

Dal 1/10/2026.

  • #37760 di @copilot-swe-agent — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
88/100
Tipo di issue
Documentazione
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
documentation

Direzione di ricerca

Inizia da fundamentals/servers/kestrel/options.md, nella sezione “Request headers timeout”, e verifica i casi referenziati in Http2TimeoutTests.cs e Http3TimeoutTests.cs per il comportamento documentato. Aggiungi la nota specifica per la versione .NET 11, mantieni il bilanciamento dei moniker circostanti e verifica che la nota venga sottoposta a rendering solo per la versione 11.0 e successive, senza avvisi di build.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

11.0 fundamentals/subsvc

Target repository: dotnet/AspNetCore.Docs
Analyzed at commit: 4986136881f2bbf1879f10106467769df5a49932
Product source verified at: dotnet/aspnetcore @ 1fcd7ef305697a1888f3ede076010350ae9f4f8d
Source release note: Kestrel applies trailer header timeouts

🎯 Goal

KestrelServerLimits.RequestHeadersTimeout is documented in fundamentals/servers/kestrel/options.md, but the article describes only its original scope — the initial request headers. In .NET 11 the same timeout now also bounds trailing headers (trailers) on HTTP/2 and HTTP/3, closing a hole where a client could start a trailer HEADERS frame and stall indefinitely. Add a version-scoped note to the existing "Request headers timeout" section.

This is a behavior change on an existing option with no new API (RequestHeadersTimeout already existed), so the element below names the prior behavior.

✅ Coverage status summary

Legend: ✅ already documented · ✏️ update needed · 🟣 could not determine

# Feature element from What's New Status Where
1 KestrelServerLimits.RequestHeadersTimeout exists and bounds time spent receiving request headers ✅ fundamentals/servers/kestrel/options.md L82–L88
2 In .NET 11, RequestHeadersTimeout also applies to trailing headers (trailers) on HTTP/2 and HTTP/3 — a partially-sent trailer HEADERS frame now resets the request when the timeout elapses ✏️ 1. Update — after options.md L88
3 Prior behavior (element 2's contrast): the timeout covered only the initial request headers; a stalled or incomplete trailer frame wasn't bounded by it ✏️ Same insertion

🔢 Version applicability

Applies to: CURRENT-ONLY
Target moniker: >= aspnetcore-11.0
Earlier versions affected: None — the extension to trailer HEADERS frames ships in .NET 11. The RequestHeadersTimeout option itself predates it and stays documented for all supported versions.

Article monikerRange Moniker state
fundamentals/servers/kestrel/options.md (no front-matter monikerRange; article is zoned inline) State D — the "Request headers timeout" section sits inside a :::moniker range=">= aspnetcore-6.0" zone spanning L14–L181. Adding an 11.0-only note requires the four-directive split: close >= aspnetcore-6.0, open >= aspnetcore-11.0, add the note, close it, reopen >= aspnetcore-6.0.

The insertion point is not inside any # [Tab](#tab/...) group, so no tab-nesting hazard applies.

📋 Coverage gap summary

An operator tuning Kestrel timeouts reads the "Request headers timeout" section and reasonably concludes the timeout guards header receipt at the start of a request. On HTTP/2 and HTTP/3, a request can also carry trailers — a second HEADERS frame after the body — and before .NET 11 that frame wasn't covered by any header timeout, so a client that opened a trailer frame and then stalled tied up the request. .NET 11 extends RequestHeadersTimeout to cover trailer HEADERS too. Nothing in the current section tells the reader this, so someone reasoning about slow-loris-style resource exhaustion via trailers gets an incomplete picture.

Feature announced in What's New:

Kestrel now applies the request headers timeout to trailing headers on HTTP/2 and HTTP/3 connections. Previously the RequestHeadersTimeout limit applied only to a request's initial headers, so a client that started sending a trailing HEADERS frame without finishing it wasn't bounded by the timeout.

Product source confirms the behavior via Kestrel's timeout tests:

Breaking change: No dedicated breaking-change article. It's a hardening change; a client depending on unbounded trailer time would be affected, but that isn't a supported expectation. Worth a one-line "behavior change" flag in the note.

📁 Affected files

Item Path Lines Section
1. fundamentals/servers/kestrel/options.md after 88 "Request headers timeout"

Target article uids: fundamentals/servers/kestrel/options

📝 Proposed changes

✏️ 1. Update — options.md, add a >= aspnetcore-11.0 trailer-timeout note (State D split)

Applies to: >= aspnetcore-11.0
Location: Lines 82–90 — after the "This timeout is not enforced when a debugger is attached" paragraph (L88) and before the ## HTTP/2 limits heading (L90), inside the >= aspnetcore-6.0 zone (L14–L181).

Before (lines 82–90):

### Request headers timeout

<xref:Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerLimits.RequestHeadersTimeout> gets or sets the maximum amount of time the server spends receiving request headers:

:::code language="csharp" source="samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureKestrelLimitsRequestHeadersTimeout" highlight="3":::

This timeout is not enforced when a debugger is attached to the Kestrel process.

## HTTP/2 limits

After:

### Request headers timeout

<xref:Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerLimits.RequestHeadersTimeout> gets or sets the maximum amount of time the server spends receiving request headers:

:::code language="csharp" source="samples/6.x/KestrelSample/Snippets/Program.cs" id="snippet_ConfigureKestrelLimitsRequestHeadersTimeout" highlight="3":::

This timeout is not enforced when a debugger is attached to the Kestrel process.

:::moniker-end

:::moniker range=">= aspnetcore-11.0"

> [!NOTE]
> In .NET 11 and later, `RequestHeadersTimeout` also bounds **trailing headers** (trailers) on HTTP/2 and HTTP/3 requests. If a client begins a trailer `HEADERS` frame but doesn't finish it within the timeout, Kestrel resets the request. In earlier versions the timeout applied only to a request's initial headers, so a stalled or partial trailer frame wasn't bounded by it.

:::moniker-end

:::moniker range=">= aspnetcore-6.0"

## HTTP/2 limits

Rationale: The existing description of RequestHeadersTimeout is accurate for all versions and stays put. The .NET 11 scope extension is additive and version-specific, so it's a >= aspnetcore-11.0 note added via a four-directive split within the surrounding 6.0 zone.

✅ 2. Update — TOC

No TOC change required. The edit adds a note to an existing article.

✅ Action plan

  1. Confirm element 1 (RequestHeadersTimeout doc at L82–L88) — already accurate.
  2. Apply change 1 as a State D four-directive split; verify the >= aspnetcore-6.0 zone that opened at L14 still closes exactly once at L181 (net-zero balance).
  3. Confirm the note renders only under 11.0 and the ## HTTP/2 limits heading remains in the 6.0 zone.
  4. Resolve any build warnings.

⚠️ Review considerations

  • No other issue in this .NET 11 coverage sweep edits this file, so the State D split is standalone (combined balance = existing + 0).
  • Wording of "trailing headers." The product term is trailers / trailer HEADERS frame. The note uses both "trailing headers (trailers)" on first mention for searchability, then "trailer HEADERS frame" for precision.
  • 🟣 Is a metrics/observability note warranted? A reset request may surface in Kestrel connection metrics; if the docs team wants, the metrics article could note trailer-timeout resets. Discretionary, not proposed here.

🔗 References

Lingua principale
C#
Stelle
13.1k
Fork
24.6k
Merge medio
1g 8h
PR unite (30g)
117

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di dotnet/AspNetCore.Docs

Tutte le issue di dotnet/AspNetCore.Docs

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.