HTTP/2: DATA sent to closed streams is never credited back to the connection window
I maintainer di solito rispondono entro 2 giorni
Valutazione
- Difficoltà
- 3/5
- Tempo stimato
- 1-2 giorni
- Idoneità per principianti
- 68/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- cpp
- Ambito
- networking
Direzione di ricerca
Inizia da Http2ConnectionState::rcv_data_frame() e segui decrement_local_rwnd() e restart_receiving(). Riproduci la sequenza descritta inviando DATA su uno stream chiuso, quindi verifica che i byte scartati provochino rapidamente un WINDOW_UPDATE a livello di connessione e che una richiesta successiva con un body non rimanga bloccata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Summary
When an HTTP/2 peer sends a DATA frame on a stream that ATS has already closed, Http2ConnectionState::rcv_data_frame() charges the payload against the connection receive window (decrement_local_rwnd() at the top of the function) and then discards the frame with a RST_STREAM(STREAM_CLOSED). Charging the bytes is what RFC 9113 section 6.9 requires, but no stream ever consumes them, so nothing calls restart_receiving() for those bytes and no connection-level WINDOW_UPDATE is ever sent for them.
Impact
A client that keeps sending DATA to closed streams can run the connection window down to zero and stall its own connection. The window is only restored when some other stream on that connection makes progress and triggers restart_receiving(), or on the every-128-frames path in Http2CommonSession. Well-behaved clients can also hit this accidentally: if ATS resets a stream while an upload is still in flight, the in-flight DATA is discarded and permanently deducted from the connection window as the client sees it.
This is scoped to the affected connection only; it does not affect other connections or users. It is a robustness bug, not a security issue.
Expected behavior
Discarded DATA should be credited back to the connection window promptly so the connection window stays synchronized between both endpoints and DATA to closed streams cannot drain it.
Reproduction
- Open an HTTP/2 connection and complete a request on stream 1.
- Send DATA frames on stream 1 (now closed), honoring the connection send window as advertised by ATS.
- After 65535 bytes the client's connection send window reaches zero and ATS never sends a connection
WINDOW_UPDATE. A subsequent request with a body cannot send its DATA.
An AuTest client that does this is included in the fix PR.
- Lingua principale
- C++
- Stelle
- 2k
- Fork
- 878
- Merge medio
- 3g 16h
- PR unite (30g)
- 91
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di apache/trafficserver
-
Bug HTTP Support
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
apache/trafficserver#13118 ·
I maintainer di solito rispondono entro 2 giorni
-
header_rewrite: rm-destination after set-destination URL crashes traffic_serverForse già presa @moonchen l’ha presa 4 giorni fa. ApertaBug Crash header_rewrite Plugins
apache/trafficserver#13800 · 1 assegnatario ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
apache/trafficserver#13798 ·
I maintainer di solito rispondono entro 2 giorni
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
apache/trafficserver#13784 ·
I maintainer di solito rispondono entro 2 giorni
-
Plugins
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
apache/trafficserver#13774 ·
I maintainer di solito rispondono entro 2 giorni
Tutte le issue di apache/trafficserver
Issue simili
-
[request] vsg/1.1.16Apertaupstream update
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
conan-io/conan-center-index#31142 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
NVIDIA/DeepStream#78 ·