Closed maphew closed 7 years ago
Doh! already implemented, use the -X
or --cross-domain
flag.
...however I'm still getting some CORS errors after enabling it (others went away though). I'll close until I build a reproducible case.
Great. Do let me know if you can reproduce an issue here - I'd like to make sure this use case is well catered for.
Reproducible. Current devd.exe (downloaded today), Win7x64.
The blood.ca compare file is one I found just by searching the internet for the filename. I've no association with the domain.
<!DOCTYPE html>
<html lang="en" dir="ltr">
<head>
<title>// PROTOTYPE //</title>
<!-- This one gives CORS fail message -->
<style>
@import url("https://beta.gov.yk.ca/profiles/wetkit/libraries/theme-wet-boew/css/theme.min.css?oeortg");
</style>
<!-- This one does NOT give CORS fail, yet file contents are identical! (according to WinMerge)
<style>
@import url("https://blood.ca/profiles/wetkit/libraries/wet-boew/dist/theme-wet-boew/css/theme-min.css?oaklh9");
</style>
-->
</head>
<body>
<header>
<div class="alert alert-warning">
<a href="#">This is a 'beta' prototype</a>
</div>
<header>
</body>
</html>
Chrome dev console:
DevdReconnectingWebSocket attempt-connect ws://devd.io/.devd.livereload
cors-test.html:1 Access to Font at 'https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.woff' from origin 'https://beta.gov.yk.ca' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://devd.io' is therefore not allowed access.
cors-test.html:1 Access to Font at 'https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.ttf' from origin 'https://beta.gov.yk.ca' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://devd.io' is therefore not allowed access.
.devd.livereload.js:147 DevdReconnectingWebSocket onopen ws://devd.io/.devd.livereload
Firefox:
econnectingWebSocket onopen ws://devd.io/.devd.livereload .devd.livereload.js:147:21
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.woff. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). (unknown)
downloadable font: download failed (font-family: "Glyphicons Halflings" style:normal weight:normal stretch:normal src index:1): bad URI or cross-site access not allowed source: https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.woff theme.min.css:12:2667
GET
https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.ttf [HTTP/1.1 206 Partial Content 9ms]
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.ttf. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). (unknown)
downloadable font: download failed (font-family: "Glyphicons Halflings" style:normal weight:normal stretch:normal src index:2): bad URI or cross-site access not allowed source: https://beta.gov.yk.ca/profiles/wetkit/libraries/wet-boew/fonts/glyphicons-halflings-regular.ttf theme.min.css:12:2667
downloadable font: no supported format found (font-family: "Glyphicons Halflings" style:normal weight:normal stretch:normal src index:4) source: (end of source list)
The CSS files differ by checksum - though I haven't gone to the effort to un-minimize them and check, I suspect the behavioural difference is simply because one theme loads the fonts and the other doesn't.
Unfortunately, we can only set the access-control header on requests that actually pass through devd. In this case, it's the font response that needs the header, but we can't touch that since the communication is directly between the browser and the remote server. You could use something like mitmproxy (another project of mine) to add the required headers, but I'd suggest that would be overkill.
Since we can't fix this, I'll close the ticket for now. Please feel free to re-open it if you find another issue.
Stranger and stranger. It appears having text on the line preceeding the import makes the error go away, for both Chrome and Firefox.
<!DOCTYPE html>
<head><title>// PROTOTYPE //</title>
<!-- This @import gives CORS fail message -->
<style>
p {} <!-- and any text on this line makes it go away!?-->
@import url("https://beta.gov.yk.ca/profiles/wetkit/libraries/theme-wet-boew/css/theme.min.css?oeortg");
</style>
</head>
<body><p class="alert alert-warning">
<a href="#">This is a 'beta' prototype</a></p>
</body></html>
Right now I'm working on a page that has multiple remote imports that fail due to CORS when the html page is loaded from the local file system. It would be nice not to have re-write them for local development and testing instead of saving a copy of all remote resources locally and editing the paths in the local documents.
According to this page all it takes is "the owner only needs to add
Access-Control-Allow-Origin:
* to the response header."