Re: [PATCH] Support client connection annotation by helpers via clt_conn_id=ID

On 24/06/2014 8:19 a.m., Alex Rousskov wrote:
> On 06/23/2014 07:44 AM, Tsantilas Christos wrote:
>> On 06/23/2014 09:50 AM, Amos Jeffries wrote:
>>> On 23/06/2014 5:43 a.m., Tsantilas Christos wrote:
>>>> clt_conn_id=ID
>>>> Associates the received ID with the client TCP connection.
>>>> The clt_conn_id=ID pair is treated as a regular annotation but
>>>> it persists across all transactions on the client connection
>>>> rather than disappearing after the current request. A helper
>>>> may update the client connection ID value during subsequent
>>>> requests by returning a new ID value. To send the connection
>>>> ID to the URL rewriter, use url_rewrite_extras:
>>>> url_rewrite_extras clt_conn_id=%{clt_conn_id}note ...
>
>
>>> * can we call this "client-tag=" or "connection-tag=" or
>>> "connection-label=". We have ID used internally via InstanceId<>
>>> template members, which are very different to this "ID" being
>>> user-assigned.
>
>
>> The clt_conn_id is not a client tag, but it can be a connection-tag or
>> connection-label.
>
>
> "client-tag" does not work well indeed because the tag is specific to
> the connection, not the client, for some popular definitions of a
> "client". For example, many differently authenticated "clients" may
> share the same tagged connection (when that connection comes from a peer
> that aggregates traffic from many end-users).

My understanding was that a major use-case for this feature was
"
for faking various forms of
connection-based "authentication" when standard HTTP authentication
cannot be used.
"

Allowing client A to "login" client B, C, ...Z etc only makes sense if
the "client" and "user" are detached concepts at this level. Client
being strictly the client-server model type of client for whom any
number of "users" may exist, or proxying for other further away clients
in a multi-hop setup.

Either way by using this tag the helper is assuming that it is relevant
to all future requests on the whole connection. ie that there is either
one "client", or one "user" which the note represents.

>
> "connection-tag" does not work well because the proposed feature is
> specific to the connection coming from an HTTP client. We may decide to
> tag connections to servers later.
>
>
> The internal instance IDs are not particularly relevant to this
> discussion about an external interface name IMO, but yes, there are many
> IDs used in Squid, for various needs. The "connectionId_" name of the
> new data member avoids confusion with the existing InstanceId members
> IMO, but if the proposed option is renamed, we may need to rename the
> data member as well. Please note that there is no "client" in the data
> member name because the class "manages a connection to a client" so the
> "client" scope should be assumed by default.
>
>
> Amos, does clt_conn_tag, clt_conn_mark, clt_conn_label, or clt_conn_note
> (or their longer, partially spelled out versions) sound better than
> "clt_conn_id" to you?

Yes. Any of them are better. "tag" has existing history from
exetrnal_acl_type interface that may want to be considered.

Amos
Received on Tue Jun 24 2014 - 05:00:13 MDT