mirror of
https://git.haproxy.org/git/haproxy.git/
synced 2025-12-24 19:11:00 +01:00
5b15447672
Up to now, we only had a flag in the session indicating if it had to work in "connection: close" mode. This is not at all compatible with keep-alive. Now we ensure that both sides of a connection act independantly and only relative to the transaction. The HTTP version of the request and response is also correctly considered. The connection already knows several modes : - tunnel (CONNECT or no option in the config) - keep-alive (when permitted by configuration) - server-close (close the server side, not the client) - close (close both sides) This change carefully detects all situations to find whether a request can be fully processed in its mode according to the configuration. Then the response is also checked and tested to fix corner cases which can happen with different HTTP versions on both sides (eg: a 1.0 client asks for explicit keep-alive, and the server responds with 1.1 without a header). The mode is selected by a capability elimination algorithm which automatically focuses on the least capable agent between the client, the frontend, the backend and the server. This ensures we won't get undesired situtations where one of the 4 "agents" is not able to process a transaction. No "Connection: close" header will be added anymore to HTTP/1.0 requests or responses since they're already in close mode. The server-close mode is still not completely implemented. The response needs to be rewritten as keep-alive before being sent to the client if the connection was already in server-close (which implies the request was in keep-alive) and if the response has a content-length or a transfer-encoding (but only if client supports 1.1). A later improvement in server-close mode would probably be to detect some situations where it's interesting to close the response (eg: redirections with remote locations). But even then, the client might close by itself. It's also worth noting that in tunnel mode, no connection header is affected in either direction. A tunnelled connection should theorically be notified at the session level, but this is useless since by definition there will not be any more requests on it. Thus, we don't need to add a flag into the session right now.