Re: [PATCH] StoreID via eCAP and ICAP

Hey Alex,

I have seen the patch but it will take me time to read here and there.
I think I can describe the header with the whole feature description.
Where is this description should be filed at?

I have written in the past a StoreID helper which first fetch the url
and looks at the properties of it to verify that it's not a 302 and if
so then use a StoreID that will not cause a 302 redirect endless looping.
The helper could exploit any details about the request HEAD response.

Thanks,
Eliezer

P.S. I know that my StoreID is maybe not coded to match very high
standards but any bug that will come from it will reveal usage of a
specific variable which was used couple times in a weird way and places.

On 06/28/2014 02:54 AM, Alex Rousskov wrote:
> Hello,
>
> The attached patch allows eCAP and ICAP services to set StoreID
> values, just like many existing store_id_program helpers do. To avoid
> surprises from rogue services, the optional behavior must be enabled in
> squid.conf by adding "store-id=1" to the e/icap_service directive.
> Adaptation services are executed before the StoreID helpers but they may
> co-exist. The latest StoreID value wins.
>
> The patch also merged eCAP and ICAP code that updates adaptation
> history, resolving an old TODO.
>
> Disclaimer: After these changes, options returned by broken eCAP
> adapters that implemented adapter::Xaction::option() without also
> implementing adapter::Xaction::visitEachOption() will stop working.
> Similarly, options returned by broken eCAP adapters that implemented
> visitEachOption() without also implementing option() may start working.
> I do not think this is a big deal because the loss of backward
> compatibility is limited to broken adapters that would have to be
> rebuild for newer Squid/libecap anyway.
>
>
> I used "Store-ID" for the name of the meta header (an ICAP response
> header or an eCAP option name; not an HTTP header!). Other alternatives
> considered but rejected:
>
> Store-Id: Most registered MIME headers use -ID, not -Id.
> http://www.iana.org/assignments/message-headers/message-headers.xhtml
>
> X-Store-ID: Trying to avoid adding X-Store-ID now and then renaming it
> to Store-ID ten years later, while adding more code for backward
> compatibility reasons. The Store-ID header is not registered. I am not
> going to write an Internet Draft to describe it, but somebody could try
> to submit a_provisional_ Store-ID IANA registration that does not
> require a Draft or an RFC AFAICT. However, the header would still need a
> description on the web somewhere. Perhaps somebody can volunteer to take
> a lead on that?
>
> Archived-At: This is a registered header that is almost perfect for our
> needs. The was worried that other developers would object to using a
> completely different name compared to StoreID helpers (and the feature
> name itself).
>
> Content-ID: This is a registered header that may be reused for our
> needs. However, StoreID is not restricted to (and typically does not
> use) unique content identifiers, content checksums, etc. All StoreID
> helpers I know map URLs and do not really know anything about the
> corresponding response content. Archived-At reasoning above applies here
> as well.
>
>
> Any other reusable and registered (or at least "known") headers to consider?
>
> I am happy to rename if a consensus builds around a different name,
> including those above.
>
>
> Thank you,
>
> Alex.
>
Received on Sun Jul 06 2014 - 21:22:12 MDT