Expose configurable HTTP/1 request-header parser admission limits

Aperta
  • Qualcosa non va?
#993 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

@Aditya-9-6 ci sta già lavorando.

Dal 9/9/2026.

  • #1000 di @Aditya-9-6 — aperta

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
38/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend-api-design, networking

Direzione di ricerca

Inizia da pingora-core/src/protocols/http/v1/common.rs e server.rs, poi esamina HttpServerOptions e default_h2_options() per individuare i pattern di configurazione esistenti. Traccia l’analisi delle richieste normali e delle richieste con prefisso pipelined prima di decidere dove collocare i limiti supportati per byte e numero di campi. Il lavoro è completato quando i limiti non impostati mantengono il comportamento esistente, i limiti configurati rifiutano le richieste sovradimensionate prima delle callback dell’applicazione e la semantica di HTTP/2 rimane separata.

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

Descrizione

enhancement

What is the problem your feature solves, or the need it fulfills?

At current main (09696b51bc59315353d96686355861604d0bb48c), downstream HTTP/1 request-header admission is fixed inside pingora-core:

  • pingora-core/src/protocols/http/v1/common.rs defines MAX_HEADERS = 256, INIT_HEADER_BUF_SIZE = 4096, and MAX_HEADER_SIZE = 1_048_575.
  • HttpSession::read_request() in pingora-core/src/protocols/http/v1/server.rs grows its parser buffer against that fixed ceiling. The source notes that the size check happens before the next read, so a completed large socket read can already exceed the nominal threshold before rejection.
  • HttpServerOptions currently exposes transport options such as h2c, keepalive request limits, and H2 idle timeout, but no HTTP/1 request-header byte/count admission setting.

For an edge proxy that needs an operator-controlled header budget materially below the built-in ceiling, rejecting in a ProxyHttp::request_filter() callback is too late to serve as a parser/resource admission control: the request header has already been buffered and parsed before that callback.

HTTP/2 already has a different control surface: default_h2_options() applies a decoded header-list limit and H2Options::max_header_list_size can customize it. I am not proposing that HTTP/1 wire/parser bytes and HTTP/2 decoded header-list size be treated as identical accounting.

Describe the solution you'd like

Please expose a supported HTTP/1 server/composition option that can lower request-header resource admission before or during parser buffering, without requiring downstream users to copy or patch Pingora parser source.

A useful API would preserve today's behavior when unset and allow an adopter to configure, at minimum:

  • a positive maximum HTTP/1 request-header byte budget; and
  • preferably a positive maximum HTTP/1 header-field count, bounded by the existing safe supplier maximum.

The limit should be applied by the HTTP/1 parser path itself, including pipelined-prefix handling, rather than only after RequestHeader construction. Oversized traffic may fail at the transport/parser boundary; a specific application status such as 431 is less important than enforcing the resource bound before application callbacks.

Expected compatibility/acceptance properties:

  1. None/unset preserves the current constants and behavior.
  2. Near-limit HTTP/1 requests succeed; over-limit one-large-field and many-small-fields requests fail before application callback processing.
  3. The configured byte/count limits also apply when the request begins from a pipelined prefix on a reused connection.
  4. Zero/impossible values fail configuration rather than silently disabling admission.
  5. HTTP/2 keeps its separate decoded-header-list semantics and defaults; this proposal should not reinterpret the H2 limit as HTTP/1 wire bytes.
  6. The implementation remains cancellation-safe and does not require allocating up to the current ~1 MiB ceiling when an adopter configures a substantially smaller budget.

If maintainers prefer these fields on a type other than HttpServerOptions, a per-connection/session option applied before HttpSession::read_request() would also satisfy the need as long as it is a supported public API.

Describe alternatives you've considered

  • Reject in ProxyHttp::request_filter(): useful for semantic policy, but too late for parser/allocation admission because session.req_header() already exists.
  • Place Nginx/another proxy in front: defeats the purpose for deployments where Pingora is the edge authority and does not make Pingora's own parser budget configurable.
  • Fork/vendor pingora-core to change MAX_HEADER_SIZE/MAX_HEADERS: enforces the right phase but creates a mutable supplier fork and makes upgrades/provenance harder.
  • Reuse HTTP/2 max_header_list_size: not appropriate because HTTP/1 parser/wire accounting and H2 decoded header-list accounting are different contracts.

Additional context

This request is based on source inspection of current protected main at 09696b51bc59315353d96686355861604d0bb48c. A downstream integration issue tracking the same boundary is ContextualWisdomLab/pingora-gateway#43.

The goal is a supported resource-admission hook, not a product-specific header policy.

Lingua principale
Rust
Stelle
27.7k
Fork
1.8k
Merge medio
1g 4h
PR unite (30g)
3

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 cloudflare/pingora

Tutte le issue di cloudflare/pingora

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.