mirror of
http://git.haproxy.org/git/haproxy.git/
synced 2024-12-15 07:54:33 +00:00
6046652253
This one is the next step of previous patch. It correctly computes the response mode and the Connection flag transformations depending on the request mode and version, and the response version and headers. We're now also able to add "Connection: keep-alive", and to convert server's close during a keep-alive connection to a server-close connection.
197 lines
8.1 KiB
Plaintext
197 lines
8.1 KiB
Plaintext
2010/01/16 - Connection header adjustments depending on the transaction mode.
|
|
|
|
|
|
HTTP transactions supports 5 possible modes :
|
|
|
|
WANT_TUN : default, nothing changed
|
|
WANT_TUN + httpclose : headers set for close in both dirs
|
|
WANT_KAL : keep-alive desired in both dirs
|
|
WANT_SCL : want close with the server and KA with the client
|
|
WANT_CLO : want close on both sides.
|
|
|
|
When only WANT_TUN is set, nothing is changed nor analysed, so for commodity
|
|
below, we'll refer to WANT_TUN+httpclose as WANT_TUN.
|
|
|
|
The mode is adjusted in 3 steps :
|
|
- configuration sets initial mode
|
|
- request headers set required request mode
|
|
- response headers set the final mode
|
|
|
|
|
|
1) Adjusting the initial mode via the configuration
|
|
|
|
option httpclose => TUN
|
|
option http-keep-alive => KAL
|
|
option http-server-close => SCL
|
|
option forceclose => CLO
|
|
|
|
Note that option httpclose combined with any other option is equivalent to
|
|
forceclose.
|
|
|
|
|
|
2) Adjusting the request mode once the request is parsed
|
|
|
|
If we cannot determine the body length from the headers, we set the mode to CLO
|
|
but later we'll switch to tunnel mode once forwarding the body. That way, all
|
|
parties are informed of the correct mode.
|
|
|
|
Depending on the request version and request Connection header, we may have to
|
|
adjust the current transaction mode and to update the connection header.
|
|
|
|
mode req_ver req_hdr new_mode hdr_change
|
|
TUN 1.0 - TUN -
|
|
TUN 1.0 ka TUN del_ka
|
|
TUN 1.0 close TUN del_close
|
|
TUN 1.0 both TUN del_ka, del_close
|
|
|
|
TUN 1.1 - TUN add_close
|
|
TUN 1.1 ka TUN del_ka, add_close
|
|
TUN 1.1 close TUN -
|
|
TUN 1.1 both TUN del_ka
|
|
|
|
KAL 1.0 - CLO -
|
|
KAL 1.0 ka KAL -
|
|
KAL 1.0 close CLO del_close
|
|
KAL 1.0 both CLO del_ka, del_close
|
|
|
|
KAL 1.1 - KAL -
|
|
KAL 1.1 ka KAL del_ka
|
|
KAL 1.1 close CLO -
|
|
KAL 1.1 both CLO del_ka
|
|
|
|
SCL 1.0 - CLO -
|
|
SCL 1.0 ka SCL del_ka
|
|
SCL 1.0 close CLO del_close
|
|
SCL 1.0 both CLO del_ka, del_close
|
|
|
|
SCL 1.1 - SCL add_close
|
|
SCL 1.1 ka SCL del_ka, add_close
|
|
SCL 1.1 close CLO -
|
|
SCL 1.1 both CLO del_ka
|
|
|
|
CLO 1.0 - CLO -
|
|
CLO 1.0 ka CLO del_ka
|
|
CLO 1.0 close CLO del_close
|
|
CLO 1.0 both CLO del_ka, del_close
|
|
|
|
CLO 1.1 - CLO add_close
|
|
CLO 1.1 ka CLO del_ka, add_close
|
|
CLO 1.1 close CLO -
|
|
CLO 1.1 both CLO del_ka
|
|
|
|
=> Summary:
|
|
- KAL and SCL are only possible with the same requests :
|
|
- 1.0 + ka
|
|
- 1.1 + ka or nothing
|
|
|
|
- CLO is assumed for any non-TUN request which contains at least a close
|
|
header, as well as for any 1.0 request without a keep-alive header.
|
|
|
|
- del_ka is set whenever we want a CLO or SCL or TUN and req contains a KA,
|
|
or when the req is 1.1 and contains a KA.
|
|
|
|
- del_close is set whenever a 1.0 request contains a close.
|
|
|
|
- add_close is set whenever a 1.1 request must be switched to TUN, SCL, CLO
|
|
and did not have a close hdr.
|
|
|
|
Note that the request processing is performed in two passes, one with the
|
|
frontend's config and a second one with the backend's config. It is only
|
|
possible to "raise" the mode between them, so during the second pass, we have
|
|
no reason to re-add a header that we previously removed. As an exception, the
|
|
TUN mode is converted to CLO once combined because in fact it's an httpclose
|
|
option set on a TUN mode connection :
|
|
|
|
BE (2)
|
|
| TUN KAL SCL CLO
|
|
----+----+----+----+----
|
|
TUN | TUN CLO CLO CLO
|
|
+
|
|
KAL | CLO KAL SCL CLO
|
|
FE +
|
|
(1) SCL | CLO SCL SCL CLO
|
|
+
|
|
CLO | CLO CLO CLO CLO
|
|
|
|
|
|
3) Adjusting the final mode once the response is parsed
|
|
|
|
This part becomes trickier. It is possible that the server responds with a
|
|
version that the client does not necessarily understand. Obviously, 1.1 clients
|
|
are asusmed to understand 1.0 responses. The problematic case is a 1.0 client
|
|
receiving a 1.1 response without any Connection header. Some 1.0 clients might
|
|
know that in 1.1 this means "keep-alive" while others might ignore the version
|
|
and assume a "close". Since we know the version on both sides, we may have to
|
|
adjust some responses to remove any ambiguous case. That's the reason why the
|
|
following table considers both the request and the response version. If the
|
|
response length cannot be determined, we switch to CLO mode.
|
|
|
|
mode res_ver res_hdr req_ver new_mode hdr_change
|
|
TUN 1.0 - any TUN -
|
|
TUN 1.0 ka any TUN del_ka
|
|
TUN 1.0 close any TUN del_close
|
|
TUN 1.0 both any TUN del_ka, del_close
|
|
|
|
TUN 1.1 - any TUN add_close
|
|
TUN 1.1 ka any TUN del_ka, add_close
|
|
TUN 1.1 close any TUN -
|
|
TUN 1.1 both any TUN del_ka
|
|
|
|
KAL 1.0 - any SCL add_ka
|
|
KAL 1.0 ka any KAL -
|
|
KAL 1.0 close any SCL del_close, add_ka
|
|
KAL 1.0 both any SCL del_close
|
|
|
|
KAL 1.1 - 1.0 KAL add_ka
|
|
KAL 1.1 - 1.1 KAL -
|
|
KAL 1.1 ka 1.0 KAL -
|
|
KAL 1.1 ka 1.1 KAL del_ka
|
|
KAL 1.1 close 1.0 SCL del_close, add_ka
|
|
KAL 1.1 close 1.1 SCL del_close
|
|
KAL 1.1 both 1.0 SCL del_close
|
|
KAL 1.1 both 1.1 SCL del_ka, del_close
|
|
|
|
SCL 1.0 - any SCL add_ka
|
|
SCL 1.0 ka any SCL -
|
|
SCL 1.0 close any SCL del_close, add_ka
|
|
SCL 1.0 both any SCL del_close
|
|
|
|
SCL 1.1 - 1.0 SCL add_ka
|
|
SCL 1.1 - 1.1 SCL -
|
|
SCL 1.1 ka 1.0 SCL -
|
|
SCL 1.1 ka 1.1 SCL del_ka
|
|
SCL 1.1 close 1.0 SCL del_close, add_ka
|
|
SCL 1.1 close 1.1 SCL del_close
|
|
SCL 1.1 both 1.0 SCL del_close
|
|
SCL 1.1 both 1.1 SCL del_ka, del_close
|
|
|
|
CLO 1.0 - any CLO -
|
|
CLO 1.0 ka any CLO del_ka
|
|
CLO 1.0 close any CLO del_close
|
|
CLO 1.0 both any CLO del_ka, del_close
|
|
|
|
CLO 1.1 - any CLO add_close
|
|
CLO 1.1 ka any CLO del_ka, add_close
|
|
CLO 1.1 close any CLO -
|
|
CLO 1.1 both any CLO del_ka
|
|
|
|
=> in summary :
|
|
- the header operations do not depend on the initial mode, they only depend
|
|
on versions and current connection header(s).
|
|
|
|
- both CLO and TUN modes work similarly, they need to set a close mode on the
|
|
reponse. A 1.1 response will exclusively need the close header, while a 1.0
|
|
response will have it removed. Any keep-alive header is always removed when
|
|
found.
|
|
|
|
- a KAL request where the server wants to close turns into an SCL response so
|
|
that we release the server but still maintain the connection to the client.
|
|
|
|
- the KAL and SCL modes work the same way as we need to set keep-alive on the
|
|
response. So a 1.0 response will only have the keep-alive header with any
|
|
close header removed. A 1.1 response will have the keep-alive header added
|
|
for 1.0 requests and the close header removed for all requests.
|
|
|
|
Note that the SCL and CLO modes will automatically cause the server connection
|
|
to be closed at the end of the data transfer.
|