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.