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.
