Define ABNF for `origin-or-null.

[mikewest]

The ABNF for Access-Control-Allow-Origin relies upon the origin-or-null syntax, which doesn't exist in RFC6454 (see https://www.rfc-editor.org/errata/eid3249). This patch defines the intended syntax.

This is intended to be an editorial change without any change in behavior, but adding grammar is somewhat normative? Idunno.

This patch also takes a normative dependency on RFC6454 for the serialized-origin grammar, which might not be ideal. We could copy it here if you'd prefer.

WDYT?

---

Preview | Diff

[annevk]

This is normative for web developers and conformance checkers.

For other implementations https://fetch.spec.whatwg.org/#concept-cors-check specifies the requirements.

I think we should probably find a way to do this without RFC 6454 and RFC 3986 as neither are part of our ecosystem. Perhaps we can just find all the bytes that serialized-origin needs and also add a reference to HTML's serialization algorithm for more details? Although maybe we can be even more specific as I think CSP needs scheme, host, and port as well and presumably also wants them without dependencies on those RFCs.

[mikewest]

I think it makes a good deal of sense to avoid depending upon Origin and URI. I think we'd just end up copying things for the most part, though: we'd want to define scheme (which I think we'd just copy), port (which we'd also just copy, though maybe with a length limit?), and host (which is complicated, pulling in the IP-related syntaxes, etc).

I'm not sure we'd actually diverge from the RFC on any of those but host. There I think we'd copy the IP bits and shift from reg-name to a subset of unreserved that covered punycode (ALPHA *( ALPHA / DIGIT / "-" / "." ), if we didn't want to get too specific).

Is that more or less what you're thinking? If so, I can look at the grammar more deeply tomorrow to figure out how it lines up with our origin serialization algorithms.

[annevk]

Yeah that sounds reasonable.

[mikewest]

This took a minute to get back to, and now that I've done it, I'm not sure it was worth doing. :) Perhaps the ANBF should be less prescriptive and we should just rely on parsing rules?

[annevk]

I kinda like it. I wonder if serialized-domain is accurate, but for conformance we might as well go with something restrictive.

Also looking at https://whatpr.org/fetch/1924.html#origin-header we should probably either align all the equal signs or none of them. Probably all?

First line of serialized-ipv6 also looks a little weird.

Some actual issues:

• serialized-port should require at least one digit.
• serialized-ipv6 needs to be surrounded by [ and ] in serialized-host.

Also maybe we should do start with the general production and make it more specific downward? Not sure though, I think the current setup is also self-consistent.

[mikewest]

Thanks for your thoughts! I addressed your specific feedback, and took a stab at tightening serialized-domain. Probably still more to do there, but seems like there's diminishing returns at this point. WDYT?

[hm-harshit]

The current rule:

serialized-port = 1*5DIGIT

Could we use something like this here?

serialized-port = "0" / ( %x31-39 0*4DIGIT )

[mikewest]

If you want to get much more granular, we'd probably want to do something similar to dec-octet to spell out all the valid numbers between 0 and 65535:

  DIGIT               ; 0-9
/ %x31-39 1*3DIGIT    ; 10-9999
/ %x31-35 4DIGIT      ; 10000-59999
/ "6" %x30-34 3DIGIT  ; 60000-64999
/ "65" %x30-34 2DIGIT ; 65000-65499
/ "655" %x30-32 DIGIT ; 65500-65529
/ "6553" %x30-35      ; 65530-65535

That seems like overkill to me (and, really, much of the complexity in this patch is arguably over the line of what grammar should be responsible for already). It's a kinda fun little puzzle to see what we can do with the grammar, but I'm not sure it's helpful. @annevk, WDYT?

[annevk]

If we want to do that it's okay I think. I don't have a strong opinion.

[annevk]

Let me know if you want to merge as-is or add more changes.

[mikewest]

@annevk: Would you mind just landing this? We can tighten things later if that seems desirable. Thanks!