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_clo
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

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

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.