Bug 59819 – Sync XHRs are rejected when the cases of the origin and destination hosts are different

• Status: RESOLVED
• Resolution: INVALID
• Component: Platform

[Jessie Berlin]

protocolHostAndPortAreEqual fails when comparing http://www.webkit.org and http://www.webKit.org.

This causes the sync loader clients on Mac and Windows to reject XHRs from an origin with domain a to an origin with domain A.

[Jessie Berlin]

<rdar://problem/9359829>

[Jessie Berlin]

On IRC, Adam Barth commented:

Normal URLs have case-insensitive host names
there's some scheme used in the Safari extensions system that has a case-sensitive "host" name
but that should probably be an exception (it's a dangerous design that won't play nicely with other folks who interpret URLs)

But he also pointed out that maybe we should not be using protocolHostAndPortAreEqual because we should be asking the SecurityOrigin about security issues.

[Jessie Berlin]

Further IRC discussion:

abarth: I think that the answer is to use SecurityOrigin::canRequest() when checking for redirects during XMLHttpRequest (and eventually, we need to stop blocking redirects, and implement what the spec says)
<abarth> that should work
<ap> abarth: we also need to audit all other uses of protocolHostAndPortAreEqual() which is only used in appcache code, and probably replace all those with SecurityOrigin invocations

[youenn fablet]

Doing a quick test, Firefox, Chrome and Safari are consistently rejecting this.
String comparison is done in passesAccessControlCheck between the header value and the serialised security origin.

This aligns with my reading of https://fetch.spec.whatwg.org/#cors-check, which is basically comparing the header value (might have any case) with a byte serialised origin (this one being always lowercased I believe).