I use a number of CDN links in my webapplication for javascript and CSS, e.g.:
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.3/jquery.min.js"
integrity="sha384-I6F5OKECLVtK/BL+8iSLDEHowSAfUo76ZL9+kGAgTRdiByINKJaqTPH/QVNS1VDb"
crossorigin="anonymous"></script>
Usually everything works fine, but sometimes I get this message in Firebug console:
None of the "sha256" hashes in the integrity attribute match the content of the subresource.
If that happens, my javascript doesn't load and my application is broken. A simple refresh will resolve that. Rather than getting rid of the CDN links and hosting the files myself, I would like to fix this. Is this a common problem?
One possible explanation for this is if your system time is sufficiently off. I was running Debian in a VirtualBox instance. I hibernated the host machine a few times without touching the VM again. That's when I noticed certain Web pages weren't loading properly in Firefox within the VM. Once I got here it occurred to me to check the system time. Sure enough it was off by nearly 2 hours. ntp was not installed so I installed that package: sudo aptitude install ntp. I verified that the date/time was updated with date, and then tested Firefox again. The problematic Web pages (including this one) worked.
Make sure your network connection is working or if you have your browser set up to use Network Proxy that it too is working.
I was seeing this message as I was loading html locally (e.g., File -> Open File) on a browser where the integrity check would fail because I did not have the network proxy (via ssh tunnel) working at the time. As soon as I resolved my network connectivity, the page would load and these messages would go away (with the assumption, of course, that the integrity attribute values are correct.)
Related
We are currently using Webpack with the HtmlWebpackPlugin to generate our javascript builds for our webpage.
new HtmlPlugin({
template: 'www/index-template.html', //source path - relative to project root
filename: 'index.html', //output path - relative to outpath above
hash: true,
cache: true //only emit new bundle if changed
}),
This causes a hash to be added to the query string of the bundled javascript file.
<script type="text/javascript" src="/build/vendor.min.js?4aacccd01b71c61e598c"></script><script type="text/javascript" src="/build/client.min.js?4aacccd01b71c61e598c"></script>
When using any standard desktop or mobile browser, new builds are cache busted properly and the new version of the site is loaded without any effort from the user. However, we also have a chrome web app implementation where we call:
chrome.exe --app=http://localhost:65000 --disable-extensions
In this application, for some reason the hash on the end of the javascript build doesn't bust the cache. We have to manually right click somewhere on the page, then click reload (or press F5). For some reason the cache isn't busted in the web application.
I was thinking that possibly it is caching the index.html file maybe? That may cause the app to never receive the updated hash on the build. I'm not sure how to solve that issue though if that is the case.
I have also noticed that if our localhost server is down, the page still loads as if the server were running. This indicates to me some kind of offline cache. I checked the manifest.json parameters and can't find anything to force a reload.
I have also tried these chrome command line switches which did not help either: --disk-cache-size=0, --aggressive-cache-discard, --disable-offline-auto-reload.
Another caveat is that we need to retain the localStorage data and their cookies. In a standard browser window, or any browser for that matter it works just fine, but not when it is inside a Chrome web app.
Are you talking "Progressive Web App" with service workers? If so then the html file can (and should) be cached on first download. You need to have some sort of aggressive update process on the client to ensure new files are loaded properly.
Perhaps having an api call that checks some sort of dirty flag on the server could work, and if it comes back true, it should reload the template files. Or something more complex where it gets an array of dirty files from the server so it knows which ones to reload instead of loading everything. Just some ideas.
As your page works without the server running at localhost, I suspect that your app is offline first. This is done exactly through service workers(as pointed out by #Chad H) which are officially supported by Chrome and are experimental in other browsers. So, expect different behavior in other browsers. To bust the cache,
In Production
For a permanent solution, you to find and modify the service worker (SW) code. Deletion of old caches happens only in activate event of SW.
You can also read more about Service worker and ask a question with the updated SW code. Also, check out this resolved issue that faced a problem similar to yours.
For dev setup
You can use the Disable Cache option under Network tab in Chrome DevTools (works only when DevTools is open) or use a more robust chrome extension called Cache Killer.
I'm encountering an issue with some local web prototyping;
I've been working on a single page which access files on my C:/ by starting my Chrome with --allow-file-access-from-files.
This is great, I've got my first page working successfully and it loads in my .js,.css files etc as expected.
However, when I click the link to proceed to the next page, the HTML loads, but none of the styles, javascript (or even images) load.
I'm receiving 'Failed to load resource' errors in the console, despite the file:// url pointing to the correct location.
Is there any way around this issue?
In lieu of a solution, some advice: Set up a web server on your computer for testing. Developing in an environment that's similar to a "production" environment, as opposed to working around the quirks of local file access, will save you quite a bit of time in the long run.
There are a number of tools that will help you set up a development web server; XAMPP is a popular one.
There is probably a better title for I'd like to accomplish, but the details should be helpful.
I've recently learned that specifying a script's src path as //some.domain.com rather than http://some.domain.com or https://some.domain.com will cause the browser to request the script using whichever protocol was used to load the page. This works great when the page is loaded from a site, but often I debug on my local system, so the protocol is file, and of course errors occur whenever resources or scripts aren't found.
Other than changing src paths, is there a better way to debug locally? I imagine there is code solution that detects when the page is running locally versus loaded from a domain, but I haven't found examples yet.
Install a product such as wampserver, then you'll have a localhost webserver you can test everything on. This is how I do it, works like a charm.
There are similar products available for ASP or other non-PHP server-side technologies (you didn't specify), if you are just doing HTML + JS then any old server would do.
Ok so I'm lost here, frustrated and pulling my hair and out. Plus probably about to be fired or take a pay cut.
I moved Files from a development server to my local machine. The files are consistent (used diff tool), all the dependencies are there. It works for the most part. The problem is that the some of the javascript (not all) is just not working. We're using jquery and a lot of plugins for it. I've checked with the web developer plugin in firefox and all the js files are loading. I cleared the cache in both firefox and chrome multiple times to no avail. The development server is a windows server running wamp. My local machine is running ubuntu. Somebody tell me what I missed.
Download firebug as a Firefox extension and view the http request and responses.
Easiest may be from within the 'net' tab to determine if your script is making a request.
Very likely that it is a source domain issue. There are no work-around for this issue. The ajax request and the source data must be on the same domain.
It may have something to do with JavaScript's security limitations. (In certain circumstances) You can only operate on URLs or pages from the current domain, which most likely changed when you moved the files off the other server. More here.
Are you running the files via a webserver, or just opening the files directly? If it's the latter, you'll want to set up a server on your local machine for local testing, and serve the files using it. Otherwise, you'll very likely run into the domain restrictions others have mentioned above.
You may need to host the site using a local server. VS IDE has an add-on called live server. You need to set up a workspace in order for it to work. The port used on my machine was 5500.
You need to make sure any dependencies for javascript are running on your server or the javascript will not be executed. These dependencies are listed in the json file.
ex. If you require express, you need to be running node or the javascript won't execute in your web browser.
In the terminal:
node app.js
Any dependencies that are not installed and running on the server will not execute.
Are you accessing the html web pages through the webserver and not simply double clicking the file to open it?
Also if you have WebDeveloper toolbar installed the click "Disable", "Disable Javascript" and make sure "All Javascript" isn't ticked.
I'm developing a Django application that contains a model with a date/time field. On my local copy of the application, the admin page for that particular model shows this for the date/time field:
alt text http://www.cs.wm.edu/~mpd/images/bugs/django-date-local.png
This is as expected. However, when I deploy to my webserver and use the application from there, I get this:
alt text http://www.cs.wm.edu/~mpd/images/bugs/django-date-server.png
The application on the server is exactly the same as my local copy, except that I have debugging disabled on the server (but I don't think that should matter...should it?). Why does the admin app on the server differ from the local admin app?
Update
The issue seems localized to Safari. The "Today" and "Now" buttons appear when the admin site is accessed via Firefox. It looks like Safari can't download some of the JavaScript files necessary to show these widgets (strange that Firefox can, though).
I noticed that Safari is receiving a "304 Not Modified" code for the following files, but I'm not sure what that means, or how to fix it. Obviously, these are the JavaScript files and images that control the date/time widget:
RelatedObjectLookup.js
DateTimeShortcuts.js
icon_calendar.gif
icon_clock.gif
I think you have to look at what is different between your firefox configuration and safary config
Off the top of my head:
One could be configured to use a proxy (messing with the trafic) the other not. Make sure the configuration is the same in both.
Safari could have cached the error clear the cache before testing again.
Try to access the gif files directly from the browser (by inputting the full url of the images) and run wireshark on the wire comparing both GET requests and responses. Something WILL be different that will help you to track the problem.
If you're getting 304 on those files. Flush your browser's cache and try again.
If it doesn't load again anyway, make sure you are getting 200 OK.
It seems like you have admin media missing (hence js and images aren't loading). I generally do following.
in settings.py
ADMIN_MEDIA_PREFIX = '/media/admin/'
Then I symlink path of django.contrib.admin.media within my media dir. Say:
ln -s /var/lib/python-support/python2.5/django/contrib/admin/media/ /var/www/media/admin
Development server serves admin media automatically. But on production servers one generally prefers to server static stuff directly from apache (or whatever server).
Check the media location, permissions and setup on your deployment server.
http://www.djangobook.com/en/1.0/chapter20/
Have you tried checking out firebug's NET tab to see if the admin javascript/css/image files are all loading correctly?
I had that problem once.
Compare all those files from the dev server against the production server.