Specific scripts fail to load under certain conditions
Created by: mvastola
I think this issue may be related to #16, but it either has intricacies not previously documented, or it is a slightly different or more complicated issue.
I created a proof of concept HTML page that triggers the issue in a gist. Several interesting things of note:
- The specific resource that will not load is the
modernizr.min.js
javascript. Curiously, the other two resources load just fine. - Doing any of the following will remove the issue:
- Disabling the
decentraleyes
extension. - Loading this HTML document from a web server rather than a
file:///
URI - Removing the
crossorigin="anonymous"
attribute from the problematic script tag.
- Disabling the
- When loading this page locally, the web console provides the error:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://cdnjs.cloudflare.com/ajax/libs/modernizr/2.8.3/modernizr.min.js. (Reason: CORS header 'Access-Control-Allow-Origin' missing).
- However, it is difficult to debug this exactly, because this request does not show up in the "Network Monitor" panel at all (and thus I can't see the headers).
- I am, however, able to see the request/response headers from the other two resource requests (I'm not entirely sure if they're being intercepted by decentralize) and I'm able to see the request/response headers of the successful Modernizr GET request when
decentraleyes
is disabled. - My debugging showed that the request headers for the two javascript resources are always identical (regardless of if
decentraleyes
is enabled/disabled) and the response headers are likewise identical (with the obvious exception of expected differences in some date and caching related headers).- The submitted
origin
request header is consistently given the valuenull
and theAccess-Control-Allow-Origin
response header, which is -- in fact -- not missing, consistently returns*
. - To ensure that this information wasn't just data fabricated by
decentraleyes
, with the extension enabled, I obtained thecurl
command to retrievejquery.min.js
swapped in the URL forModernizr
, and observed that theAccess-Control-Allow-Origin
response header was present and its value was*
. - No other errors/warnings were sent to the Web Console, by
decentraleyes
, or otherwise. - Despite turning on the "Add Comments to Locally Fetched Files" option, even the resources that did load failed to display any such comments.
- The submitted
So yeah.. I think that's all the detail I have right now. I'll update this if I can think of anything else, but for right now this is consistently reproducible for me and unfortunately I'm not able to make enough sense out of when this (doesn't) work(s) to identify a better pattern.
If you have any debugging steps you'd like me to try, I'd be happy to give them a go.
FWIW, I'm not using this out of privacy concerns (though I know this is an important use case); I simply thought this would be cool/useful from a speed perspective. In my case, therefore, it would have been nice to have the option to fall back to default behavior.