Timing-Allow-Origin check should be case-insensitive

[npm1]

Scheme, host, port are all case-insensitive, so the timing allow check algorithm should do a case-insensitive check. Currently, the check is stated as If the Timing-Allow-Origin header value list does not contain a value which is byte-for-byte identical to the serialization of the current document's origin, nor a wildcard ("*"), return fail.

[yoavweiss]

I agree current language doesn't handle case sensitivity in a tolerant way. Looking at CORS it doesn't seem to do that either.

IIRC, @annevk was the one pointing me towards the "byte-for-byte identical" language, so he may have opinions here. Also, I'm not sure what current implementations do. Looking at Chromium's, it doesn't seem case insensitive. (other than its "null" comparison...)

We should at the very least add tests to see that whatever we decide here is actually enforced.

[annevk]

Hmm, ideally the null comparison is case-sensitive too.

@npm1 what are you basing your assertions on?

[yoavweiss]

Hmm, ideally the null comparison is case-sensitive too.

Agreed

[yoavweiss]

From IRC discussion with @annevk, it seems like the origin with which the headers are compared will always be lower case. That means developers should always set the TAO (and ACAO) header values to lower case and the checks will pass fine, even if the links the user followed or the URL they clicked contained uppercase letter as part of the scheme or the host.

So, I don't see any reason to change the current behavior to be case-insensitive.

[npm1]

This was reported based on a question from a security developer. Two strings that are case-insensitive matches correspond to the same origin but I guess at some point the URL parser lowercases these so there is a 'canonical' way to represent them? In particular, 'Serializing a request origin' probably already returns this in the canonical way. It seems fine to keep this case-sensitive for consistency then.

[annevk]

Indeed, if the browser ever exposed them in non-canonical case that would be problematic. And if we start doing non-literal comparisons developers might expect we do other kinds of parsing behavior too, which we never do for origins.