If there are no objections I will apply the latest patch to trunk.
Regards,
Christos
On 06/26/2014 05:45 PM, Tsantilas Christos wrote:
A new patch.
Changes:
- clt_conn_id renamed to clt_conn_tag
- Amos requested fixes.
I hope it is OK.
Regards,
Christos
On 06/22/2014 08:43 PM, Tsantilas Christos wrote:
Hi all,
The attached patch replaces existin annotation values with the new one
received from helpers.
Just one question. We are documenting key-value pairs in cf.data.pre
only for url-rewriter helpers, but annotations works for all squid
helpers.
Should we move the related url-rewriter section to a global section? If
yes where?
For example something like the following in a global section should be
enough:
The interface for all helpers has been extended to support arbitrary
lists of key=value pairs, with the syntax key=value . Some keys have
special meaning to Squid, as documented here.
Currently Squid understands the following optional key=value pairs
received from URL rewriters:
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 ...
On 06/19/2014 09:07 PM, Tsantilas Christos wrote:
On 06/16/2014 06:36 PM, Alex Rousskov wrote:
On 06/15/2014 12:07 AM, Amos Jeffries wrote:
On 15/06/2014 4:58 a.m., Alex Rousskov wrote:
On 06/11/2014 08:52 AM, Tsantilas Christos wrote:
I must also note that this patch adds an inconsistency. All
annotation
key=values pairs received from helpers, accumulated to the
existing key
notes values. The clt_conn_id=Id pair is always unique and replaces
the
existing clt_conn_id=Id annotation pair.
We may want to make all annotations unique, or maybe implement a
configuration mechanism to define which annotations are overwriting
their previous values and which appending the new values.
I suggest making all annotations unique (i.e., new values overwrite
old
ones) because helpers that want to accumulate annotation values
can do
that by returning old values along with new ones:
received by helper: name=v1
returned by helper: name=v1,v2
Please note that the opposite does not work: If annotation values
are
always accumulated, a helper cannot overwrite/remove the old value.
Doing that would mean passing all existing annotations to every
helper
lookup.
Why would that mean the above?
AFAICT, the helper should get only the annotations it needs. That need
is helper-specific and, hence, is configurable via the various _extras
and equivalent directives. That is already supported and does not need
to change.
Here is the overall sketch for supporting "unique annotations":
1. Send the helper the annotations it is configured to get
(no changes here).
2. For each unique annotation key received from the helper,
remove any old annotation(s) with the same key.
3. Store annotations received from the helper
(no changes here).
To support explicit annotation deletion, we can adjust #3 to skip
key-value pairs with the value equal to '-'.
If there is not any objection I will implement this scenario.
Looks that this approach is the best and cover more cases than the
accumulated Notes values.
If someones need to accumulate Note values he can configure squid to
send old note value to helper and helper include it in its response.
This is simple.
If required in the future we can implement a configuration parameter
which configures one or more notes as always accumulated. For example:
AccumulateHelperNotes status message
HTH,
Alex.
