Add GeneratingCONNECT step for the existing at_step ACL (#484)
The new step allows admins to customize CONNECT request generation using
request_header_access and request_header_replace. As detailed below,
matching the request method does not work for those purposes.
request_header_access controls what HTTP request headers Squid _sends_.
However, this directive, like most other ACL-driven Squid directives,
uses the received request, _not_ the being-formed to-be-sent request.
This can be confusing, but it is the correct design/behavior.
When Squid is about to send a CONNECT request to a cache peer, what
_received_ request should request_header_access ACLs look at? There are
several ways to answer that question:
1. The received CONNECT request (or, for intercepted TLS connections,
its faked equivalent). This is how the current CONNECT-sending code
works when establishing the tunnel for a not-yet-bumped client
connection. Problems:
1. The CONNECT request received by Squid was not meant for the cache
peer. It was meant specifically for this Squid. While it may have
info useful for request_header_access checks, it is conceptually
wrong to think of whats happening as "forwarding of that received
CONNECT to the cache peer". Unlike GET requests, the CONNECT
request that this Squid will send to the cache peer is dedicated
to the Squid-peer connection. It is generated, not forwarded.
2. That CONNECT request may have been received a long time ago, and
Squid may have forwarded many bumped GET requests since then. It
feels strange to consult such an old/"disconnected" message.
2. The received (and bumped) GET request. This is how the current
CONNECT-sending code works when establishing the tunnel for an
already bumped client connection. Problem:
1. Squid is about to send a generated CONNECT request, not to
forward a received GET request (the latter will happen later,
after the CONNECT transaction). The two requests may differ a
lot. Using a GET request when generating a CONNECT request is
confusing: "Why is my CONNECT method ACL does not match when
Squid sends a CONNECT request?!"
3. No request. Problems:
1. Some old configurations that use request-specific ACLs with
request_header_access will generate runtime "missing request"
warnings and may fail to work correctly.
2. Extra admin work is required to store request-specific
information as connection annotations that request_header_access
ACLs can still access.
3. Conceptually, there is a request that Squid is establishing this
CONNECT tunnel for. Squid will access-log that request. Hiding
that information from ACLs feels odd/wrong. And some of that info
would still be accessible to ACLs (via ALE/etc.). This hiding
does not really hide all of the details.
Our solution preserves what received request Squid is looking at. Items
1 and 2 above still apply (depending on the configuration and on the
request being processed), with their unique problems intact. Those
problems are not as bad as the problems associated with the item 3!
The at_step ACL was added for SslBump but, IIRC, we knew that it may
eventually cover other request processing steps. Generating a CONNECT
request is one of those other steps.