Lighttpd

RFC 7230 Section 6.1. Connection

   The "close" connection option is defined for a sender to signal that
   this connection will be closed after completion of the response.  For
   example,

     Connection: close

   in either the request or the response header fields indicates that
   the sender is going to close the connection after the current
   request/response is complete

lighttpd mod_proxy always sends Connection: close to a backend, whether HTTP/1.0 or HTTP/1.1.

When another lighttpd instance is the backend, that lighttpd backend responds with Connection: close and closes the connection, as expected from a polite backend.

lighttpd mod_proxy (incorrectly) expects such behavior, and does not look at the response, instead simply transferring data until the connection to the backend is closed. Such behavior happened to work when making HTTP/1.0 requests to backends, where Connection: close is the default, as is the behavior of any CGI gateway backend whose response does not provide Content-Length. However, with HTTP/1.1 requests, lighttpd should be more careful and should handle a) no Content-Length and no Transfer-Encoding: chunked, b) Content-Length c) Transfer-Encoding: chunked. In b) and c), lighttpd should -- but currently does not -- close the connection to the backend after the exact Content-Length specified has been received or after the Transfer-Encoding: chunked response-body-ending 0\r\n chunk (and optional trailers) have been received.

• lighttpd currently does not track the Content-Length received from a backend.
• lighttpd currently does not peek into Transfer-Encoding: chunked if the client is HTTP/1.1. chunked body from the backend is transferred to client as-is.
• In the case of HTTP/2 client, lighttpd decodes HTTP/1.1 Transfer-Encoding: chunked from the backend, but mod_proxy does not check when the final chunk (and optional trailers) have been received.

I'll work on adding the necessary accounting for mod_proxy to track the state of the response data sent from the backend.

I have patches for parsing chunked encoding from the backend, including the optimization to avoid copying data when we are (re-)sending chunked encoding to client.
lighttpd git on branch personal/gstrauss/master

Remaining work to do for this issue is to handle Content-Length, if provided, and to continue to handle case where Content-Length (and Transfer-Encoding: chunked) are not provided by the backend.

I pushed a sketch of patches (untested) to my dev branch personal/gstrauss/master. When I am better rested tomorrow, I need to run through a battery of scenarios to check that it is working as desired and does not break existing usage. At the moment, I do not recommend these new patches on anything other than a test server.

I stay with server.feature-flags += ("proxy.force-http10" => "enable") and wait until you have finished your patches.

I tested the patches and can confirm, that it works now with standard settings (server.feature-flags += ("proxy.force-http10" => "disable")).