HTTP CONNECT proxy tunnel has lax response parsing and loses early data
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 48/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- rust
- Ambito
- networking
Direzione di ricerca
Inizia in src/client/legacy/connect/proxy/tunnel.rs, nella gestione della risposta CONNECT, quindi leggi la struct privata Rewind in src/common/rewind.rs per comprendere il contesto del buffering. Esamina la handshake API e determina come rappresentare il parsing rigoroso delle risposte e i dati iniziali conservati; il lavoro è completo quando le risposte malformate vengono rifiutate e i dati del server di destinazione vengono preservati dopo la stabilizzazione del tunnel.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Version
hyper-util 0.1.20
Platform
Linux 6.18.14
Summary
While evaluating hyper-util's client::legacy::connect::proxy::tunnel for use with gRPC routing over HTTP CONNECT proxies, I identified two limitations in the current handshake implementation.
1. Lax Response Parsing
It heuristically matches the start and end of the expected response, potentially accepting malformed responses.
This can be fixed by using httparse to properly parse the response.
2. No Buffering for Early Data
It assumes the read buffer contains no data from the target server immediately after the proxy's response. This assumption holds for protocols where the client always speaks first (e.g., TLS) after the tunnel is established. However, since gRPC implementations must work with any security protocol, they must handle cases where the server sends data immediately.
Fixing this would require an API change, as the returned I/O stream would need to incorporate a buffer for the peeked data, similar to the private Rewind struct.
Although the handshaking code is simple enough to be re-implemented in gRPC, I wanted to check if these fixes can be upstreamed to allow us to use hyper-util.
Code Sample
Expected Behavior
- The proxy response must be correctly parsed.
- The data from the target server must be retained.
Actual Behavior
- A malformed proxy response may be accepted
- The data from the target server may be lost.
Additional Context
No response
- Lingua principale
- Rust
- Stelle
- 16.3k
- Fork
- 1.8k
- Merge medio
- 1g 23h
- PR unite (30g)
- 13
Guida per i contributori
Apri 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 hyperium/hyper
-
C-feature
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 65/100
-
C-feature
Difficoltà 5/5 Più di una settimana Idoneità per principianti 35/100
-
C-bug S-waiting-on-author
-
A-http2 C-bug
-
C-bug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
Tutte le issue di hyperium/hyper
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
TheLarkInn/aipm#2413 ·
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
alexgorbatchev/simple-ptt#15 ·
-
tooling
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
todo:ticket
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
taikoxyz/taiko-mono#22168 · 1 commento ·