Cookie-Indices should specify how unexpected values are handled

[jeremyroman]

(re. draft-nottingham-http-availability-hints)

@mnot's suggestion via email was:

• ignore unrecognized parameters
• treat other unexpected data structures like a syntax error and ignore the field (i.e., falling back to vary)

I think this makes sense; it fails safe for most cases and if we ever added a parameter where it would be incorrect for existing implementations to ignore it, we could add a must-support-whizbang or similar token which older implementations would reject.

Filed this as an issue both because it's slightly less trivial to actually make this change as I sit here, and because it's nuanced enough that someone might have second thoughts before someone sits down to address this.

[jeremyroman]

One remaining case -- strings which are not valid cookie names in RFC 6265, such as strings containing one of the separators characters. Some of these are also accepted as cookies by browsers (well, at least Chromium browsers -- I haven't dug into Mozilla and WebKit), and some are not.

One possibility is to say that strings that don't match the cookie-name production are ignored (or stricter, constitute a syntax error in the entire header). Alternatively, we could accept all strings (that consist of printable ASCII characters) and simply rely on the fact that they will never compare equal to a cookie that the HTTP implementation never stored (whatever limitations it applies to cookie names).