Causes issue with Access-Control-Allow-Origin:*

[danielchatfield]

Browser: chrome
Example (may be fixed soon though Fixed by using https directly): http://yeoman.io/community-generators.html

Page tries to load http://yeoman-generator-list.herokuapp.com/ which results in: XMLHttpRequest cannot load http://yeoman-generator-list.herokuapp.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://yeoman.io' is therefore not allowed access..

If the page requests the https version directly then it works.

[diracdeltas]

Wow, what an interesting bug! Both http://yeoman-generator-list.herokuapp.com/ and https://yeoman-generator-list.herokuapp.com/ send "Access-Control-Allow-Origin:*", so in theory CORS should allow http://yeoman.io to load either by XMLHttpRequest.

But in reality:

> $.get('http://yeoman-generator-list.herokuapp.com');  // returns 404 and "XMLHttpRequest cannot load http://yeoman-generator-list.herokuapp.com/. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://yeoman.io' is therefore not allowed access."
> $.get('https://yeoman-generator-list.herokuapp.com');  // returns 200, no errors

And indeed, disabling the Heroku rule makes both work fine. The behavior is exactly the same in Firefox 26.

My guess is that the browser tries to check cross origin request rules on XMLHttpRequest.send() per http://www.w3.org/TR/XMLHttpRequest/#cross-origin-request-event-rules and gets confused because the URL it's supposed to load never gets loaded. So it returns an error, which Chrome mistakes for a cross origin resource sharing failure.

If that's the case, we need to detect when an HTTP XMLHttpRequest is opened, abort it, and then open and send a new XMLHttpRequest with the rewritten URL. :/

[danielchatfield]

This also causes several analytics services to fail, e.g. mixpanel.

[riking]

Bump - this is causing issues with Discourse on a CDN.

https://github.com/discourse/discourse

Test case: http://forum.fazedores.com/

[Akamaozu]

@diracdeltas Your explanation seems to hit the nail on the head.

Was having trouble with xmlhttp not getting the access-control-allow-origin header I clearly set. Requesting from my custom domain worked perfectly but the Heroku domain resulted in CORS. I suspect its something to do with the redirect because that's the only thing that changed.

[emas80]

Hi, we are experiencing the same issue on our beta environment, with the Firefox version.

On our beta environment, we don't have https enabled, so you are browsing in http and contacting our different services only in http.

The front end is a Rails app hosted on Heroku, the assets are hosted on S3. CORS on S3 is correctly configured as for their guide. If I disable HTTPs everywhere it works perfectly.
Also, Mixpanel fails, as I can see in the JS console some CORS-related errors about some urls being contacted from Mixpanel javascript. Mixpanel, like other tools, uses https if it founds https in the url, http otherwise.

It's really weird because from the files hosted on S3, the javascripts are loaded, while the .css are blocked. Needless to say that all of them are hosted on S3 in the same bucket.

Please note that on our production environment, where https is enabled for every service, everything works perfectly, and I can't see any single error, not even in Mixpanel javascript.

[jsha]

From @diracdeltas' summary it sounds like the short-term fix might be to simply skip rewrites of XHRs for now. If the parent page is HTTPS, the XHR should already go to HTTPS or it will be blocked as active mixed content (https://community.qualys.com/blogs/securitylabs/2014/03/19/https-mixed-content-still-the-easiest-way-to-break-ssl). If the parent page is HTTP we aren't improving security a lot by rewriting the XHR.

[jsha]

@emas80 While we're working on a fix, you may be able to fix the issue in your dev environment by changing your code to always contact the HTTPS version of s3, even if you are running in non-HTTPS dev environment.

[garrettr]

From @diracdeltas' summary it sounds like the short-term fix might be to simply skip rewrites of XHRs for now.

XHRs aren't the only type of request affected by this bug. For example, if you load the test case from #49 (comment), you can see that CORS errors are firing for web fonts (.woff and .ttf). This suggests an interaction between HTTPS everywhere and the CORS implementation in Firefox, I would expect the other content types listed on this page will have issues too.

[emas80]

OK thanks!

On Tue, Nov 25, 2014 at 3:21 AM, jsha notifications@github.com wrote:

@emas80 https://github.com/emas80 While we're working on a fix, you may
be able to fix the issue in your dev environment by changing your code to
always contact the HTTPS version of s3, even if you are running in
non-HTTPS dev environment.

—
Reply to this email directly or view it on GitHub
#49 (comment)
.

[garrettr]

@cooperq pointed out that this bug is present in both Firefox and Chrome, so it's likely not implementation-specific, but is more likely, as Yan suggested in #49 (comment), something related to the spec. I was able to avoid the issue by returning early instead of rewriting the URLs that are failing due to CORS.

Interestingly, I was able to determine (by setting breakpoints in the Firefox addon code) that Firefox attempts to rewrite the Fastly font URLs to use https, but the CORS error message refers to the original URL with http.