Re: Failing Parameter in Key Header

[Mark Nottingham <[e-mail]>]

Hi Paul,


> On 30 May 2016, at 11:07 AM, Paul Mansour <[e-mail]> wrote:
> 
> I am trying to implement the Key header (from https://tools.ietf.org/html/draft-ietf-httpbis-key-01) and have a question regarding “fail parameter processing”.   I apologize in advance if this question is best for another forum. The Key header does not appear to be widely discussed yet, so I thought this might be the right place.

Very much so.

 
> Why is a key-item with zero parameters treated as a “failing parameter” (going to section 2.2.2) when calculating a secondary cache key?  I would have thought that at step 5, sub-step 2, it would read something like:
>   
> …append “field-value” (or a normalized version of it) to “secondary-key” (and go to next key item)
>  
> In other words, if there are zero parameters for a key-item, simply append the value of the header field to the secondary-key and then move on to the next key-item. In all other cases when building the cache key, there is an actual error in the parameter (no = sign, bad parameter name, etc.). In the case of zero parameters, it is not really an error, as the spec explicitly allows for zero or more parameters.

The spec uses "fail' to mean "fall back to normal Vary processing". One way to achieve that would be to append the request header's value to the secondary key, but specifying it that way would block the implementation from making Vary-specific optimisations (e.g., trimming whitespace, using knowledge of the request header to canonicalise it). 

I agree we could make this more clear, though.


>  In addition, and related, and I think more important, it is unclear to me whether or not each key item stands on its own if there is a failing parameter (or as it stands, no parameters) in one of them. In the step-by-step algorithm it seems to indicate that they are independent, as in case of error the instruction is to move on to the next key-item (after handling the error). But in the failing parameter processing section 2.2.2 it seems to indicate that if there is a single failing parameter, the entire Key header should be ignored (falling back to Vary I assume) or that all of the “nominated header fields being compared match” which is the same as treating the Key header as a Vary header with no parameters for any nominated header field. In either case, one failing parameter in one key-item appear to void all parameters in all key-items.

Good question. I think we need to clarify this text in 2.2.2:

"""
When this happens, implementations MUST either behave as if the Key header was not present, or assure that the nominated header fields being compared match, as per [RFC7234], Section 4.1.
"""

to something like:

"""
When this happens, implementations MUST either behave as if the whole Key header was not present (i.e., abort processing of Key, ignoring it entirely and falling back to Vary), or assure that the nominated header fields being compared match, as per [RFC7234], Section 4.1 (i.e., treat the failing portion of the Key header as falling back to Vary, but continuing to process other parts).
"""

Would that help?


--
Mark Nottingham   https://www.mnot.net/