Variants' incoming-request assumes all content-negotiation systems' Accept headers are lists

[jyasskin]

https://httpwg.org/http-extensions/draft-ietf-httpbis-variants.html#cache says:

Given incoming-request (a mapping of field-names to lists of field values)

It doesn't specify how to calculate this from the HTTP request (https://fetch.spec.whatwg.org/#requests? I don't see a version-independent definition of a request in the HTTP specs.) that the cache actually receives, and it doesn't deal with request headers like https://httpwg.org/http-extensions/client-hints.html#dpr that hold a single value instead of a list.

[mnot]

Are you looking for text that effectively says:

If the header is defined to be a single value, take the first instance of the header field and put its value into a list. If the header is defined to be a list (e.g., using the #rule), parse each instance of the header field into a list and combine all of those lists.

?

note that work on http-core might help here; e.g., see httpwg/http-core#116

[jyasskin]

#735 changed the use of incoming-request to say

Let request-value be the field-value associated with field-name in incoming-request (after being combined as allowed by Section 3.2.2 of [RFC7230])

which I think is good (but I would since I wrote it). The declaration of incoming-request could say the same thing.

I'd rather have this part of this spec not worry about the definition of the header, and instead isolate that to the call into the "content negotiation mechanism that the implementation supports". Then headers like DPR can define for themselves how they react to responses that are invalid by including multiple header instances.