[squid-dev] [PATCH] annotate_transaction ACL

[Christos Tsantilas]

Hi all,
  Which is the status of this patch?
Can be applied to squid-5?


On 02/01/2017 12:19 πμ, Eduard Bagdasaryan wrote:
> Hello,
>
>
> The "annotate transaction" patch implements  two new ACLs:
> annotate_transaction and annotate_client. Please apply this patch first.
>
> Both ACLs always match and are useful for their side effect, immediately
> adding a key-value pair to the current transaction annotation
> (annotate_transaction) or to the current client-to-Squid connection
> annotation (annotate_client).  Connection annotations are propagated to
> the current and all future master transactions on the annotated
> connection. Before this patch only 'clt_conn_tag' annotation tag could
> be used for a connection annotation.
>
> To reuse the existing notes parsing code, I had to refactor Note, Notes
> and NotePairs classes:
>
> * Made data members private and adjusted to follow 'rule of three'.
>   Having public assess to containers with pointers may cause memory
>   problems: for example ExternalACLEntry::update() called directly
>   notes.entries.clear() without deleting the pointers.
> * None-fatal check for 'special' characters inside note name.
> * Used SBufs instead of Strings and const char* where possible.
> * Adjusted ACLNoteStrategy::matchNotes() to avoid 'expanding quoted values'
>   code duplication inside
>
> Also fixed acl quoted flag parameters syntax. The old code improperly
> required quoting both flag and its parameter, e.g., "-m= ," whereas
> only parameter should be quoted: -m=" ,".
>
> Also moved UpdateRequestNotes() from Notes.cc to HttpRequest.cc to
> resolve dependency problems while bulding unit tests.
>
> TODO: transaction annotation matching code (ACLNoteData) performs
> parsing in its own way, using ACLStringData::parse(), lacking special
> characters/reserved keywords checks. Consider reusing the existing
> Notes parsing code instead.
>
>
> The "helper deny message" patch fixes Auth::UserRequest::denyMessage()
> misuse.
>
> I believe this method was improperly used in contexts where actually
> Auth::UserRequest::setDenyMessage() expected. Probably the reason is
> that both denyMessage() and getDenyMessage() were not constant,
> provoking such 'misuse'.
>
> Also placed some common code into UserRequest::denyMessageFromHelper(),
> eliminating code duplication. Though there are many places
> inside auth/ntlm/UserRequest.cc and auth/negotiate/UserRequest.cc
> where code is still duplicated.
>
>
> Thanks,
> Eduard.
>