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