Correct repeated Transfer-Encoding and Content-Length response framing

Abierto
  • ¿Algo no está bien?
#32 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
52/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
rust
Área
networking

Línea de trabajo

Comienza en src/http_proxy.rs leyendo header_field, content_length, is_transfer_encoding_chunked y response_body; después, sigue el response pump introducido por #23. Añade cobertura del lado de la respuesta para casos repetidos y malformados de Transfer-Encoding y Content-Length, incluido un response keep-alive después de cada uno. Se considera terminado cuando el framing, el rechazo y la correspondencia de las respuestas coincidan con cada criterio de aceptación.

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

Descripción

Follow-up from the post-merge review of #23.

Problem

The new HTTP/1 response pump uses header_field, which returns only the first field with a given name. Response framing therefore does not correctly handle repeated Transfer-Encoding or Content-Length fields.

Examples:

  • Transfer-Encoding: gzip followed by Transfer-Encoding: chunked is validly terminated by chunked framing, but the proxy sees only the first field and treats the response as read-to-close.
  • Conflicting Content-Length fields are not rejected.
  • A malformed first Content-Length becomes indistinguishable from no framing and is treated as read-to-close.

On keep-alive connections this can consume subsequent responses as part of the preceding body, break request/response correspondence, or stall until the upstream closes.

Location

  • src/http_proxy.rs: header_field, content_length, is_transfer_encoding_chunked, and response_body
  • Response pump introduced by #23.

Acceptance criteria

  • Combine all Transfer-Encoding field values in wire order and frame as chunked only when the final coding is chunked.
  • Validate every Content-Length occurrence, including comma-list normalization where supported; reject conflicting or malformed values.
  • Define and test behavior when Transfer-Encoding and Content-Length coexist in a response.
  • Add response-side tests for:
    • repeated TE ending in chunked;
    • repeated TE not ending in chunked;
    • identical repeated CL;
    • conflicting CL;
    • malformed CL;
    • each case followed by another keep-alive response to verify correspondence.
Lenguaje dominante
Rust
Estrellas
1
Forks
0
Merge medio
19 h 12 min
PR fusionados (30 d)
13

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 HarperFast/symphony

Todos los issues de HarperFast/symphony

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.