Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

HTTP CONNECT proxy tunnel has lax response parsing and loses early data

Abierto
  • ¿Algo no está bien?
#4,095 7 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@heitzlki ya está trabajando en esto.

Desde el 11/9/2026.

  • #313 de @hunterinvariants — cerrado sin fusionar
  • #320 de @heitzlki — abierto

Evaluación

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

Línea de trabajo

Comienza en src/client/legacy/connect/proxy/tunnel.rs, en el procesamiento de la respuesta CONNECT, y después lee la estructura privada Rewind en src/common/rewind.rs para entender el contexto del almacenamiento en búfer. Revisa la handshake API y determina cómo deberían representarse el análisis estricto de las respuestas y los datos iniciales retenidos; la tarea estará terminada cuando se rechacen las respuestas malformadas y los datos del servidor de destino se conserven después de establecer el túnel.

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

Descripción

A-client C-bug E-pr-welcome K-hyper-util
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

Lenguaje dominante
Rust
Estrellas
16.3k
Forks
1.8k
Merge medio
4 d 13 h
PR fusionados (30 d)
21

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 hyperium/hyper

Todos los issues de hyperium/hyper

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.