Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

WebSocket: a reset of either joined socket is logged at ERROR by ConnectionBase

Aperta
  • Qualcosa non va?
#157 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
62/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
java
Ambito
networking

Direzione di ricerca

Start in ReverseProxy.Proxy#sendResponse, where the client socket (request.proxiedRequest().toNetSocket()) and the backend socket (proxiedResponse.netSocket()) are joined with only handler and closeHandler. Read ConnectionBase#handleException to see why an unhandled reset is logged at ERROR. Done means both joined sockets get an exception handler that logs at trace and closes the other socket, with no reproducer test required.

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

Descrizione

Version

5.2.1 (also current main)

Context

Once the backend answers 101, ReverseProxy.Proxy#sendResponse joins the client socket
(request.proxiedRequest().toNetSocket()) and the backend socket (proxiedResponse.netSocket()) with handler and
closeHandler only. Neither socket gets an exception handler, so a failure on a joined socket is logged as an error.
The common case is a peer resetting its connection, which is routine for WebSockets (a closed tab, a mobile client
changing networks, a load balancer in front of the proxy closing its connection with a reset). With the native epoll
transport each one logs:

[ERROR] io.vertx.core.net.impl.ConnectionBase - recvAddress(..) failed with error(-104): Connection reset by peer

(Connection reset with the NIO transport.) Behind HAProxy this is a steady stream of ERROR lines, one per abruptly
ended WebSocket, that cannot be told apart from real failures.

Client side. toNetSocket() replaces the HTTP server connection with a new NetSocketImpl
(Http1ServerConnection#netSocket). The new connection does not keep the server's exception handler (which logs
connection failures at trace by default), so a reset takes this path:

  1. the read fails with ECONNRESET, and Netty fires exceptionCaught and then closes the channel;
  2. VertxHandler#exceptionCaught calls ConnectionBase#handleException on the NetSocketImpl;
  3. ConnectionBase#handleException finds no exception handler and logs the exception at ERROR;
  4. the channel closes, closeHandler fires and closes the backend socket.

Backend side. proxiedResponse.netSocket() is an HttpNetSocket over the request to the backend. A failure is
reported to that request's connection (Http1ClientConnection#handleException, which calls
ConnectionBase#handleException) and to the request (HttpClientRequestImpl#handleException), each of which logs it
at ERROR unless it has an exception handler, and then to the socket. The request and its connection belong to
whoever created the request (the OriginRequestProvider), so this issue only covers the joined sockets. Related: the
request also logs Connection was closed at ERROR whenever the proxy closes a WebSocket, a normal close included,
unless its creator sets an exception handler (the existing WebSocketTest tests log it on main).

The failure branch right below (Handle this case printed to System.err when toNetSocket() fails) is covered by
#155 / #156.

Steps to reproduce
  1. Proxy a WebSocket to a backend and let the backend answer 101.
  2. Once data has gone through the proxy, reset the client connection (close it with SO_LINGER 0).
  3. The proxy logs the reset at ERROR from io.vertx.core.net.impl.ConnectionBase.
Possible fix

Set an exception handler on both joined sockets, next to the closeHandlers, that logs at trace and closes the other
socket.

Do you have a reproducer?

The steps above; there is no test with the fix, because the change only affects what is logged. After an
IOException on a read, Netty closes the channel once it has reported the exception, and the existing closeHandlers
then close the other socket, so both sides close with or without the exception handlers. A test would have to capture
Vert.x's own log output, which nothing in this project does, and would depend on which logging backend the tests
happen to run with.

Lingua principale
Java
Stelle
68
Fork
38
Nessuna PR unita negli ultimi 30g

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 eclipse-vertx/vertx-http-proxy

Tutte le issue di eclipse-vertx/vertx-http-proxy

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.