<div dir="ltr">Same thoughts as Amos: a common ACL switch to annotate results of the matching seems more natural from the user's perspective (although probably requires more code to implement).</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 10, 2016 at 12:47 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 10/07/2016 7:14 a.m., Alex Rousskov wrote:<br>
><br>
> B. Add general ACL options to be able to force any existing ACL to add<br>
> an annotation:<br>
><br>
>     acl myOldAcl dst --annotate foo=bar <a href="http://127.0.0.1/32" rel="noreferrer" target="_blank">127.0.0.1/32</a><br>
><br>
> Please let me know if you consider any of the above alternatives more<br>
> attractive (than adding new ACLs) or need me to detail their drawbacks.<br>
><br>
<br>
</span>I do like the below better. But for the record what was the drawback on<br>
(B) that you saw as serious?<br>
 This used to be what we were planning to add one day.<br>
<div><div class="h5"><br>
><br>
> Please note that the documentation below does not currently detail what<br>
> "adding" a foo=bar annotation means when there is already an annotation<br>
> named "foo". During implementation, we will decide whether the new ACLs<br>
> should always append to the existing matching annotation and/or<br>
> overwrite it. The documentation will be adjusted accordingly, of course.<br>
><br>
><br>
> * acl aclname annotate_transaction key value [fast]<br>
><br>
> Always matches. Used for its side effect: This ACL immediately adds<br>
> a key=value annotation to the current master transaction. The added<br>
> annotation can then be tested using note ACL and logged (or sent to<br>
> helpers) using %note format code. This ACL is especially useful for<br>
> recording complex multi-step ACL-driven decisions. For example:<br>
><br>
>     # Do not log transaction accepted after aclX matched<br>
><br>
>     # First, mark transactions accepted after aclX matched<br>
>     acl markSpecial annotate_transaction special true<br>
>     http_access allow acl001<br>
>     ...<br>
>     http_access deny acl100<br>
>     http_access allow aclX markSpecial<br>
><br>
>     # Second, do not log marked transactions:<br>
>     acl markedSpecial note special true<br>
>     access_log ... deny markedSpecial<br>
><br>
>     # Note that the following would not have worked because aclX<br>
>     # alone does not determine whether the transaction was allowed:<br>
>     # access_log ... deny markedSpecial # Wrong<br>
><br>
><br>
> Warning: This ACL annotates the transaction even when negated and<br>
> even if subsequent ACLs fail to match. For example, the following<br>
> three rules will have exactly the same effect as far as annotations<br>
> set by the "mark" ACL are concerned:<br>
><br>
>     some_directive acl1 acl2 ... mark # rule matches if mark is reached<br>
>     some_directive acl1 acl2 ... !mark     # rule never matches<br>
>     some_directive acl1 acl2 ... mark !all # rule never matches<br>
><br>
><br>
> * acl aclname annotate_client key value [fast]<br>
><br>
> Always matches. Used for its side effect: This ACL immediately adds<br>
> a key=value annotation to the current client-to-Squid connection.<br>
> Connection annotations are propagated to the current and all future<br>
> master transactions on the annotated connection. All caveats for the<br>
> annotate_transaction ACL apply to this ACL.<br>
<br>
</div></div>I think the format should use explicitly the ' key="value" ' syntax to<br>
make it simpler to identify where the value ends and ACL sub-tree begin.<br>
<br>
That will also allow us to define the above format as adding a new key<br>
only if not already present. We could use key+="value" syntax for<br>
appending a value to an possibly existing key (or adding if none).<br>
<br>
"Always matches" seems incorrect definition for this ACL. When 'fast' is<br>
provided it should pass-thru the match or non-match result of the [fast]<br>
ACL sub-tree, and only annotate when that result is a match.<br>
 I assume [fast] default would be 'all' to always annotate and be true<br>
if there was no sub-tree.<br>
<br>
We will also have to be careful to blacklist the reserved key names that<br>
require special processing to be correct:<br>
 user, group, password, ttl, url, url-rewrite, etc.<br>
<br>
Otherwise it seems good. Thanks.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
squid-dev mailing list<br>
<a href="mailto:squid-dev@lists.squid-cache.org">squid-dev@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-dev" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">    Francesco</div>
</div>