Expose configurable HTTP/1 request-header parser admission limits

Abierto
  • ¿Algo no está bien?
#993 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@Aditya-9-6 ya está trabajando en esto.

Desde el 9/9/2026.

  • #1000 de @Aditya-9-6 — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
backend-api-design, networking

Línea de trabajo

Comienza con pingora-core/src/protocols/http/v1/common.rs y server.rs, y luego inspecciona HttpServerOptions y default_h2_options() para conocer los patrones de configuración existentes. Rastrea el análisis de solicitudes normales y de solicitudes con prefijo pipelined antes de decidir dónde deben ubicarse los límites admitidos de bytes y cantidad de campos. Se considera terminado cuando los límites no establecidos conservan el comportamiento actual, los límites configurados rechazan las solicitudes demasiado grandes antes de las callbacks de la aplicación y la semántica de HTTP/2 permanece separada.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Rust
Estrellas
27.7k
Forks
1.8k
Merge medio
1 d 4 h
PR fusionados (30 d)
3

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cloudflare/pingora

Todos los issues de cloudflare/pingora

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.