httpwg
sfbis: Can List Items repeat with different parameters?
I was playing around with structured headers (pretty much coinciding with Tommy's last, last-call), which prompted me to look into the spec. It is unclear to me if what happens when items in a list are repeated with different parameters:
New-Header: foo; a=1, foo; b=2
- Is that legal?
- Does that mean:
a.
foo; a=1ignoring the second item? b.foo; b=2overriding the first item? c.foo; a=1; b=2combining the parameters? d. Is the person defining the header responsible for defining the behaviour?
(Currently, the JavaScript implementation on npm seems to just output the two as separate items. I am not sure if it satisfies the current test suite or that for RFC8941. )
I was playing around with structured headers (pretty much coinciding with Tommy's last, last-call), which prompted me to look into the spec. It is unclear to me if what happens when items in a list are repeated with different parameters:
New-Header: foo; a=1, foo; b=2
Is that legal?
Does that mean:
a.
foo; a=1ignoring the second item?b.
foo; b=2overriding the first item?c.
foo; a=1; b=2combining the parameters?d. Is the person defining the header responsible for defining the behaviour?
(Currently, the JavaScript implementation on npm seems to just output the two as separate items. I am not sure if it satisfies the current test suite or that for RFC8941. )
Great
My reading is that each item is independent from Structured Fields perspective, so the parsed list should provide access to each one and preserve the order
Cdn-Loop is a good example, there could be multiple instance of a CDN in the chain with different parameters on each. https://datatracker.ietf.org/doc/html/rfc8586
Some fields might not be able to logical handle duplicate values. It is the responsibility of the field definition to describe what to do with duplicates
Cdn-Loop is...
- Is not a Structured Header.
- Does not contain an example of repetition of the same CDN in the list, nor does it specify how to handle the repetition.
Some fields might not be able to logical handle duplicate values. It is the responsibility of the field definition to describe what to do with duplicates
But if each structured field has to define something so basic, and considering structured field is a new tech because "regular" fields were all over the place, it does not feel very standard. Processing different structured fields should imho lead to a consistent outcome, minimizing an author's need to specify and a dev's needs to implement custom handling of such fields.
I don't see anything in the spec that implies that list items can not repeat. It's a list, not a dictionary.
Neither am I saying that. But there is nothing to specify how the repetition should be handled either?
Nothing says that the repitition needs any handling. It's just a list.
(and yes, it wouldn't hurt to have a test case for that)
Yes. Is that not odd? Because, it is semantically ambiguous when you add in different parameters.
It's not ambiguous, the parameters are specific to each item. It's like ordering 5 hotdogs where each has a parameter of mustard or ketchup. Combining the orders so that you have one hotdog with all the sauces isn't correct.
Cdn-loop wasn't defined as a Structured Field list but it can map to it per https://httpwg.org/http-extensions/draft-ietf-httpbis-retrofit.html.
OK! I was thinking of cases where you would need to list a particular item at most once (though I did not imply combining condiments with your hotdogs was the way to go; I wouldn't know, I am a vegetarian!). My doubt stems from a bug I encountered where a server (Cloudflare Pages) was erroneously setting Cross-Origin-Opener-Header multiple times, which could lead to the situation above. However, COOP is an Item SF, so that would be treated as an error, and does not translate exactly!
Having said that, I would still prefer some explicit language about repeated list items in the spec, together with a test case.
What would it say? The semantics of repeated list items are specific to the field in question -- they might be truly separate items (the common case), or it might be that the last one takes precedence. It's the responsibility of the field definition to inflate the semantics of the data structure, not SF.
Exactly that!
Something like:
"Members of a List are allowed to repeat. A structured field definition MUST specify how such repetitions are to be handled."
or, to exclude the common case:
"Members of a List are allowed to repeat. In case these are not truly separate members, a structured field definition MUST specify how such repetitions are to be handled."
I don't think mandating that downstream specs talk about repetitions makes sense. A list is, well, a list. The default expectation is that repetitions are allowed. If you don't want repetitions in your header, then you need to say something. If you don't want even-length lists, you also need to say something.
If you don't say anything, you just get the baseline sf-list semantics, repetitions and all. This is in the same way that the Python len() or map() functions do not need to call out that repetitions or even-length lists are allowed because it's just implicit in the structure.
As you note, COOP is an item, not a list, which means it's already specified that it's a singular value. Had you provided two COOP headers with different contents, you would have had the same error. The repetition was a red herring. Your error came from multiplicity.
A list is, well, a list. The default expectation is that repetitions are allowed.
This was not obvious to me (because of parameters being involved, this is not an ordinary list/array but a different data structure which is list/array like), hence I tripped (maybe it could be set like?)! I am not sure everyone will recognize the "default" convention. Besides, I don't think it is wrong for me to ask what the "baseline sf-list semantics" are, I would rather the spec be explicit about the data structure than engage in mind reading!
List is a list of Item or Inner List. I don't see why parameters affects the modelling, it seems you're ascribing some special meaning to them that doesn't exist at the level of Structured Fields abstraction.
If you don't want repetitions in your header, then you need to say something.
Maybe we can say that explicitly (not having to co-relate with Section 2 to interpret that).
it seems you're ascribing some special meaning to them
What I am saying is that it is possible to assign special meaning to repeated items when including parameters (the convention to treat repetitions as separate entries and not, say, overwrite or combine them is not epistemically pre-ordained, I would be ignorant in that I am not following a convention that exists but not wrong in assuming a different convention is possible). The extra line, however you want to phrase it, removes that doubt.
PS: It is not my intention to grandstand here, so I will stay mum after this unless someone explicitly speaks to me with an explicit mention!
It's possible to ascribe meaning to repetition without parameters. I'm not sure what they change.
It's possible to ascribe meaning to repetition without parameters. I'm not sure what they change.
Reminds me of "-v -v -v" to increase verbosity in command line tools.
Tommy, as the document shepherd for this spec has already noted my objection. So yes, we can close this issue!