On 06/23/2014 11:00 PM, Amos Jeffries wrote:
> 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.
> "
Correct. There is a certain danger in conflating a use case with a
feature that resulted from that use case, but you have stated the
original motivation correctly.
> 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.
In the scope of this particular feature, only the former interpretation
of "client" applies: The agent making a connection to Squid. Distant
users indirectly delivered or "proxied" to Squid do not apply.
> 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.
Not quite: One user or client may open multiple connections to Squid,
each possibly having its own ID/tag/label. The feature is about [client]
connection tagging, not client or user tagging.
>> 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.
"tag" usage in external_acl_type is semantically similar to what we are
doing here. Unfortunately, "tag" is not called clt_request_tag, and it
has a different never-reset semantics.
"mark" is used in QoS (TOS/DSCP) connection marking context, a
semantically related concept. Note that some supported connection
markings can be reset/changed during a single connection lifetime
(AFAICT), just like the connection ID being proposed. On the other hand,
those markings alter bytes on the wire while the proposed feature does
not do that [directly].
"note" is used for various annotations with a different multi-value
semantics (unless we change that ASAP). Also, the proposed feature is
setting the _value_ of that annotation without controlling the note key
so it is somewhat wrong to call it clt_conn_note. It should be
clt_conn_note_value instead, which is probably too long/awkward.
None of these suffixes are a perfect fit. I do not have a strong
preference, but can suggest clt_conn_tag if nobody has a strong
preference or better ideas.
HTH,
Alex.
