Open Tanych opened 2 months ago
Any thoughts on this? This came up in a Chromium code review and it'd be helpful to have a clarification to ensure that we've implemented parsing of the AvailLanguage header correctly. Thanks!
For reference: https://chromium-review.googlesource.com/c/chromium/src/+/5703436/comment/eac735bf_760f79bd/
The text in the spec needs some more nuance, but unrecognised Parameters on Avail-Language
should indeed be ignored. If d
has a non-Boolean value, we'll need to define (probably most sensible to ignore those too).
For multiple d
, I'm inclined to say either first one wins, or it means the entire field should be ignored - thoughts?
Thanks Mark, and my apologies for the delay in getting back to you.
Ignoring unrecognized parameters and non-Boolean parameter values SGTM. I wonder if it'd also be helpful to have the spec say explicitly that the type of the d
parameter is Boolean.
Regarding multiple 'd', I don't know if there is any precedent from how other specs handle this type of thing, but first one wins seems reasonable to me.
I've opened https://crbug.com/1456351 on our end to track making changes based on this feedback. Thanks again!
For the available hints like AvailLanguage, I have a couple of questions to confirm:
when the specs says "unrecognised Parameters on Structured Fields are ignored and therefore do not trigger this fallback", does it mean that e.g.
en, zh;ddd, ja;dd
should result inen, zh, ja
, alsoen, zh;d;c
anden, zh;d=?0
anden;d=1.0, zh
should be treated the same asen, zh
?whether multiple default setting allows or be ignored? it's not clear whether
en, zh;d, ja;d
should actually be rejected or be treated the same was asen, zh;d, ja
or asen, zh;d
.