Re: [PATCH] StoreID via eCAP and ICAP

On 07/06/2014 03:19 PM, Eliezer Croitoru wrote:

> I think I can describe the header with the whole feature description.
> Where is this description should be filed at?

As you know, the StoreID feature is described at
http://wiki.squid-cache.org/Features/StoreID

I do not know whether IANA is going to accept a reference to a
subsection of that wiki page as the Store-ID header description, but one
can try and find out. The registration procedure for provisional headers
is described by RFC 3864. I do not know how well that documentation
matches the reality,

> 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.

Sorry, I do not understand why you are saying the above. AFAICT, the
proposed patch does not really change how StoreID helper responses are
processed.

Thank you,

Alex.

> 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 - 22:43:42 MDT