Http-key about i-d

[mnot]

It's not just a cache key; just as Vary does, it identifies the aspects of the request that helped select the response.

Also, Key is shorter. IIRC Roy has strong feelings about that...

WRT predicate syntax - do you have a concrete suggestion? Roy originally talked about a regex-like syntax (not full regex), but the http parameter syntax uses existing parsers.

[jasnell]

Hmm.. well, Key is rather ambiguous really. Not sure what alternative name could work, however, so I guess I'll leave that one alone for now.

On the predicate syntax... I guess the thing that I'm struggling with the most is whether people will go through the trouble of actually using the predicates properly. As I said, we can barely get people to use Vary properly and that's just header field names, let alone value matching of specific parameters and so forth.

Question: what if we're selecting a Header field that uses a non-ascii encoding? For example Link with a UTF-8 title parameter. How would that work exactly? Given that different fields allow for different encoding schemes, would I just use something like w*="..." and depend on the implementation to decode everything prior to matching?

Comment: I do see that you changed the case for 'c' and 'n' .. thanks for that ..

[mnot]

Hopefully, Key will be automagically generated by implementations, rather than be set by hand by authors. I do think we might have a semicolon-delimited selector (i.e., use everything before the first parameter, stripping whitespace) in the next draft, so that this fairly common syntactic convention can be easily dealt with correctly. Slightly more out there would be qvalue comparison, but I don't know if we need that yet.

WRT non-ascii encoding -- while it's out there, I don't think it's likely in a selecting request header, and if it is, someone can always do an extension modifier.