It seems this is actually allowed by the RFCs; although it is intended
as HTTP/1.0 backward compatibility, and HTTP/1.1 servers (backends)
really should do better.
Even if they shouldn't (due to HTTP/1.0 or Connection; close) some
backends send HTTP/1.1 without Connection: close, and use Content-Length
to signal end of response (and don't close the connection, as they wait
for another request).
Now Content-Length is used to find the end of the response (chunked
transfer-encoding was already supported).
mod_proxy now signals HTTP/1.1, but also sends "Connection: close": it
doesn't reuse the connection yet.
- reset backend_source before backend_drain; first tell the backend we
are not interested in data anymore, then force closing the outgoing
- as backend_drain might get reopened for a Connection: upgrade, the
backend cannot rely on backend_drain->out.is_closed, but waits for a
disconnect (which will also release the last reference). the same is
done for backend_source, so a backend can just wait for both reference
counts to drop to zero before actually closing the backend connection
(unless it keeps the streams alive itself).