Fetch-hulppunt plakt een 502 in een lopend 200-antwoord en laat de verbinding hangen #2755

New issue

Open

opened 2026-11-02 23:47:00 +00:00 by brenno · 1 comment

brenno commented

2026-11-02 23:47:00 +00:00

Owner

Gevonden in de kritische review van 03-11-2026 (stabiliteit).

Wat er misgaat

Valt de bron weg nadat het fetch-hulppunt de 200 met headers al heeft verstuurd — een reset halverwege, een time-out, IncompleteRead — dan schrijft _do_get een tweede, volledig HTTP-antwoord (HTTP/1.1 502 Bad Gateway …) in de body van het lopende antwoord. De verbinding blijft daarna open staan.

Hoe gevalideerd

Reproductie met een bron die Content-Length: 1000 aankondigt, 10 bytes stuurt en de verbinding reset. De client ontving letterlijk:

HTTP/1.1 200 OK … Content-Length: 1000\r\n\r\nHTTP/1.1 502 Bad Gateway … kon de bron niet bereiken

en wachtte na 3 seconden nog steeds: de proxy sloot de verbinding niet.

Oorzaak

server/fetch-proxy/ocideck_fetch_proxy.py r. 335: de except (OSError, ssl.SSLError, http.client.HTTPException) roept altijd _refuse(502) aan, ook als send_response(200)/end_headers() (r. 300–308) al zijn gebeurd. close_connection wordt niet gezet.

Gevolg

Met Content-Length wacht de browser op bytes die nooit komen; de import hangt tot een time-out van de reverse proxy.
Met chunked encoding raakt de stroom onleesbaar.
In beide gevallen krijgt de app een kapot of hangend antwoord in plaats van een nette afbreking.

Voorstel

Bijhouden of de headers al weg zijn. Zo ja: niets meer schrijven, close_connection = True, zodat de client een afgebroken antwoord ziet. Zo nee: de bestaande 502 blijft.

Wat overeind moet blijven

De neutrale 502 (zonder doel-URL) bij een fout vóór de eerste byte.
Het afkappen bij MAX_BYTES en de deadline.

Test

Python-zelftoets met een bron die halverwege reset: de proxy sluit de verbinding en schrijft geen tweede statusregel. Rood op de huidige code.

Gevonden in de kritische review van 03-11-2026 (stabiliteit). ## Wat er misgaat Valt de bron weg *nadat* het fetch-hulppunt de 200 met headers al heeft verstuurd — een reset halverwege, een time-out, `IncompleteRead` — dan schrijft `_do_get` een tweede, volledig HTTP-antwoord (`HTTP/1.1 502 Bad Gateway …`) in de body van het lopende antwoord. De verbinding blijft daarna open staan. ## Hoe gevalideerd Reproductie met een bron die `Content-Length: 1000` aankondigt, 10 bytes stuurt en de verbinding reset. De client ontving letterlijk: ``` HTTP/1.1 200 OK … Content-Length: 1000\r\n\r\nHTTP/1.1 502 Bad Gateway … kon de bron niet bereiken ``` en wachtte na 3 seconden nog steeds: de proxy sloot de verbinding niet. ## Oorzaak `server/fetch-proxy/ocideck_fetch_proxy.py` r. 335: de `except (OSError, ssl.SSLError, http.client.HTTPException)` roept altijd `_refuse(502)` aan, ook als `send_response(200)`/`end_headers()` (r. 300–308) al zijn gebeurd. `close_connection` wordt niet gezet. ## Gevolg - Met `Content-Length` wacht de browser op bytes die nooit komen; de import hangt tot een time-out van de reverse proxy. - Met chunked encoding raakt de stroom onleesbaar. - In beide gevallen krijgt de app een kapot of hangend antwoord in plaats van een nette afbreking. ## Voorstel Bijhouden of de headers al weg zijn. Zo ja: niets meer schrijven, `close_connection = True`, zodat de client een afgebroken antwoord ziet. Zo nee: de bestaande 502 blijft. ## Wat overeind moet blijven - De neutrale 502 (zonder doel-URL) bij een fout vóór de eerste byte. - Het afkappen bij `MAX_BYTES` en de deadline. ## Test Python-zelftoets met een bron die halverwege reset: de proxy sluit de verbinding en schrijft geen tweede statusregel. Rood op de huidige code.

brenno added the

bug

in-progress

labels

2026-11-02 23:47:00 +00:00

brenno commented

2026-11-02 23:47:19 +00:00

Author

Owner

Opgepakt (kritische review 03-11-2026). Tak: fix/proxy-midstream-2755. Verwachte reikwijdte: server/fetch-proxy/ocideck_fetch_proxy.py en zijn zelftoets.