Correct repeated Transfer-Encoding and Content-Length response framing

Aperta
  • Qualcosa non va?
#32 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
52/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
rust
Ambito
networking

Direzione di ricerca

Inizia in src/http_proxy.rs leggendo header_field, content_length, is_transfer_encoding_chunked e response_body, quindi segui il response pump introdotto da #23. Aggiungi coverage lato response per i casi ripetuti e malformati di Transfer-Encoding e Content-Length, ciascuno seguito da una risposta keep-alive. Il lavoro è completo quando framing, rifiuto e corrispondenza delle response corrispondono a ogni criterio di accettazione.

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

Descrizione

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.
Lingua principale
Rust
Stelle
1
Fork
0
Merge medio
19h 12m
PR unite (30g)
13

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

Tutte le issue di HarperFast/symphony

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.