On 12/13/2015 02:31 AM, Amos Jeffries wrote: > On 9/12/2015 10:56 p.m., Christos Tsantilas wrote: >> There are several use cases where an annotation may contain a list of >> values for a single key. Today it is only possible to match the full >> annotation value.
>> E.g. if an external ACL sets an annotation like: >> "applications=http,facebook,facebook-chat" >> the following ACLs can be used to block access to certain applications: >> >> acl fb_chat note -m applications facebook-chat >> acl db_upload note -m applications dropbox-upload >> http_access deny fb_chat >> http_access deny db_upload > Annotations from the helper are kv-pair. By definition that means > singular value per key on helper responses. You are mixing up two different concepts: value syntax and value semantics. From the syntax point of view, the a key=value pair indeed contains a singular value. However, the interpretation of what that value _means_ is up to the admin. The opaque-to-kv-parser value may actually contain a lot of things from the admin point of view. Traditionally, Squid admins use ACLs to interpret opaque-to-Squid values. > So where is the need for this coming from? Very often, helper annotation values contain a list of flags such as content classification tags or error IDs. Matching individual items in such a list using existing [regular expression] ACLs is tedious and error-prone(**). To support this common need better, we should accept this new ACL flag. A detailed example included with the patch submission illustrates one real-world use case. Christos, please answer Amos' implementation-specific questions. My response above only details the need for this new feature, not the implementation details (which can be adjusted as needed, of course). Thank you, Alex. P.S. (**) We could force helpers to emit multiple key=value pairs with the same key to emulate a list, but that requirement forces a single semantics onto a value that may be interpreted differently by different ACLs. _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
