HTTP/2 to origin: bodyless response with a header block over 4 KB fails to parse and is sent to the client as 502/500
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 68/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- cpp
- Área
- backend-api-design, networking
Línea de trabajo
Start with Http2Stream::send_headers and HttpSM::state_read_server_response_header, then follow HTTPHdr::parse_resp in HdrTSOnly.cc and MIMEScanner::get. Reproduce the bodyless HTTP/2 302 or 204 with an approximately 8.8 KB header block. Done means the large header parses across blocks and the client receives the origin response instead of a 502 or 500.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
If an HTTP/2 origin sends a bodyless response (HEADERS with END_STREAM) whose header block is larger than one IOBuffer block (about 4 KB), ATS fails to parse it. The client gets a 502 or 500 instead of the origin's response. It mostly shows up on redirects and 204s that carry a large Content-Security-Policy or Set-Cookie.
Cause
Http2Stream::send_headers, which hands a received header to the HttpSM, prints the decoded response header into_receive_bufferone block at a time, adding a block wheneverprint()doesn't finish. A header of more than about 4 KB therefore spans several blocks, and a field can be split at a block boundary.- With
receive_end_streamset on an outbound stream, it then signalsVC_EVENT_EOS, not READ_READY or READ_COMPLETE. HttpSM::state_read_server_response_headerhandles that EOS by parsing witheof = true. It logsServer closed connection while reading response headerat this point, even though nothing closed.HTTPHdr::parse_resp(HdrTSOnly.cc) loops over the reader one block at a time and passes the sameeofflag for every block. When a field is cut at the end of the first block,MIMEScanner::gettreats it as the end of input and returnsParseResult::ERROR(unterminated field).- The result is
handle_server_setup_error, and the client gets an error. squid-style logs show the origin's real status (a 3xx or 204) next to the 5xx sent to the client, witho_bytesstopping just short of the field that crosses the 4 KB boundary.
Observed / reproduction
Reproduced on a 10.0.x build; HdrTSOnly.cc is identical on master.
- An HTTP/2 origin returns
302with no body and a header block of about 8.8 KB, including one longContent-Security-Policyfield. - A GET through ATS: the origin logs a 302, and the client gets a 502 every time, with
o_bytes=202and the request retried once (two attempts). - The same responses had no errors while that origin was reached over HTTP/1.1.
- In production traffic, one bodyless 3xx endpoint failed 150 of 150 requests.
Suggested fix
Either of these, or both:
- In
HTTPHdr::parse_resp, passeofonly for the last block, when there is no further block to read. - In
Http2Stream, write the whole decoded header into one block sized to fit it, so a header from an HTTP/2 frame is never split.
- Lenguaje dominante
- C++
- Estrellas
- 2k
- Forks
- 878
- Merge medio
- 3 d 16 h
- PR fusionados (30 d)
- 95
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/trafficserver
-
Bug HTTP Support
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
apache/trafficserver#13118 ·
Los mantenedores suelen responder en 2 días
-
header_rewrite: rm-destination after set-destination URL crashes traffic_serverPosiblemente ocupada @moonchen la tomó hace 7 días. AbiertoBug Crash header_rewrite Plugins
apache/trafficserver#13800 · 1 asignado ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
apache/trafficserver#13798 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
apache/trafficserver#13784 ·
Los mantenedores suelen responder en 2 días
-
Plugins
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
apache/trafficserver#13774 ·
Los mantenedores suelen responder en 2 días
Todos los issues de apache/trafficserver
Issues similares
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
ros-navigation/navigation2#6648 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[BUG] OTA Requestor accepts reserved provider endpoint 0xFFFFPosiblemente ocupada @Chapoly1305 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
project-chip/connectedhomeip#74742 ·
Los mantenedores suelen responder en 1 día