I am trying a simple test with the html 5 cache.
Here is a simple web page :
<!DOCTYPE html>
<html manifest="test.manifest">
<head>
</head>
<body>
<img src="http://www.somewebsite.com/picture.jpg"/>
</body>
</html>
With the following manifest :
CACHE MANIFEST
#v0.1
NETWORK:
http://www.somewebsite.com/
This work fine, the picture is displayed.
My problem is that I won't be able to know from where the picture will come. Here comes the online whitelist wildcard flag, that is supposed to solve my problem.
But with the manifest :
CACHE MANIFEST
#v0.1
NETWORK:
*
The image is not displayed (tested on safari / safari mobile / firefox).
What is not working ?
Is there another way to turn the online whitelist wildcard flag on ?
Tested in Firefox 3.6.4:
NETWORK:
http://*
Per the docs, when "the online whitelist wildcard flag is open" (i.e., the NETWORK: * format),
Subresources, such as style sheets,
images, etc, would only be cached
using the regular HTTP caching
semantics, however.
which seems to be the "what is not working". To cache subresources in the HTML5 way, the manifest must either list them in a CACHE: section, or use specific "online whitelist namespaces" as you did in your first version.
I wish to use an svg font in a webapp aimed for mobile safari (mobile safari only reads the svg font format for #font-face) Mobile safari also requires the font-ID, which is included at the end of the file name, but included after number sign (#):
font-name.svg#123456789
This is not working in the cache-manifest for the site and, with the limited feedback one gets from mobile safari, I am only guessing that the # is causing the font-id to be read as a comment, and not part of the actual file name.
Is there a way to 'trick' the cache manifest into reading this differently? Perhaps with a wildcard after the SVG? Or an ascii-only trick?
Related
We created a web site that uses resources from cdnjs. This site has been live for a couple of months but we have sporadic issues with resources from this CDN and FireFox.
The error in the console for each script/style CDN resource is:
None of the "sha256" hashes in the integrity attribute match the content of the subresource.
The error message in the network tab for each resource is:
The connection used to fetch this resource was not secure
Resources that I have had issues with include these elements (as they appear in our web page):
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/css/bootstrap-dialog.min.css" integrity="sha256-wstTM1F5dOf7cgnlRHIW3bmoRAAGh6jL7tMIvqTuFZE=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/bootstrap-datetimepicker/4.17.47/css/bootstrap-datetimepicker.min.css" integrity="sha256-yMjaV542P+q1RnH6XByCPDfUFhmOafWbeLPmqKh11zo=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jqtree/1.4.4/jqtree.min.css" integrity="sha256-ymsp1QFcwiJbIgAoSOkMtqe4GFczZH1KjXLq6y5f+QY=" crossorigin="anonymous" />
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/font-awesome/4.7.0/css/font-awesome.min.css" integrity="sha384-wvfXpqpZZVQGK6TAh5PVlGOfQNHSoD2xbE+QkPxCAFlNEevoEH3Sl0sibVcOQVnN" crossorigin="anonymous" />
<script src="https://cdnjs.cloudflare.com/ajax/libs/bootstrap3-dialog/1.35.4/js/bootstrap-dialog.min.js" integrity="sha256-IpgnbT7iaNM6j9WjtXKI8VMJ272WM9VvFYkZdu1umOA=" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/moment.js/2.15.2/moment-with-locales.min.js" integrity="sha256-K+AZsAFjiBd4piqBmFzaxDsiQiHfREubm1ExNGW1JIA=" crossorigin="anonymous"></script>
Steps to reproduce
You can reproduce the problem with one of the above URLs and place it directly in the URL of the FireFox browser. The resource should load in the browser window but after pressing CTRL+F5 at least one time (could be up to 5 times) an error will appear. I can duplicate this from multiple PCs although we are located in the Netherlands so maybe a timing issue or something similar (beyond my expertise)?
This does not happen with any other resources from other CDNs that we are using like the following:
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script src="https://code.jquery.com/jquery-3.3.1.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>
My environment:
Windows 10 Pro 64bit patched to latest
FireFox 60.0.1 (64-bit)
My question
Is this an issue that is specific to cdnjs and they must resolve this or is this an issue with FireFox or is this an issue with how we are requesting the resource?
As a side note we also regularly test our software on Google Chrome, MS Internet Explorer 11, MS Edge, and Opera and have never experienced this problem on these browsers (or any other for that matter).
I have already created a post on Mozilla's forum but the response was that this is out of scope with a recommendation to post it on SO or submit a bug on GitHub. I have not done the latter becomes I am not (yet) convinced this is a bug in FireFox. I have also submitted an issue on cdnjs's github repo.
TL;DR: similar problem on Linux (RHEL 7.3) with Firefox 45.6.0 was solved by downloading 60.0.2 from getfirefox.com.
I'm afraid this is unlikely to solve #Igor's problem, but I had a very similar problem and solved it with a Firefox upgrade; perhaps this will help others.
In my case I was seeing the same
The connection used to fetch this resource was not secure
message in the web console's Network tab not only for Cloudflare but for several other sites:
https://cdnjs.cloudflare.com/
https://ajax.googleapis.com/
https://www.googletagmanager.com/
https://www.google.com/
https://www.youtube.com/
https://www.mozilla.org/ (!)
Chromium, however, was unaffected (as were lynx and curl).
Given the error message for failures, I poked around in Preferences -> Advanced -> Certificates -> View Certificates and was immediately suspicious of all of the expired ones (since 2014!) in the Servers tab, including www.google.com. Attempts to delete them failed, however; they came back immediately after retesting any of the problematic sites in a new tab.
Every suggestion on the Mozilla help pages also failed: no proxy, no anti-virus, safe mode, refresh profile, switch to a brand-new profile (also got bogus 2014 certs, so clearly hard-coded), disable hardware acceleration, disable DNS prefetch, and several other about:config hacks. Reinstalling the existing Firefox version via yum also failed, as did manual deletion of all sqlite files and most of the relevant-looking sites under storage/default (all within $HOME/.mozilla/firefox/<profile>). Even Mozilla's own certutil failed to read the freshly minted cert8.db in the new, clean profile:
$ certutil -L
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format.
I even tried to reload Firefox's root certificates via the Import option in the Advanced preferences page for 45.x, but the plain-text version I found on Mozilla's Mercurial repo apparently wasn't understood by Firefox's import button. (Or maybe it was; there was zero feedback. But the expired stuff on the Servers tab didn't go away.)
I mention everything that didn't work both because several of those actions did help others who reported similar problems, and also because running through all the possibilities (and several intervening discussions with colleagues) took a huge amount of time.
Ultimately, grabbing the latest Firefox binary via
https://support.mozilla.org/en-US/kb/install-firefox-linux
http://www.getfirefox.com/
and unpacking the tarball in a local directory worked fine, and it took all of two minutes to complete and verify. Both old and new profiles work fine with it. And lo and behold, the Servers tab is completely empty of all certificates, expired or not. In my case, I'm pretty sure that was the problem, and my inability to delete the bogus certs was a bug in 45.x.
This question is very old but if any one facing this problem please check the script attribute integrity
<script src="https://code.jquery.com/jquery-3.1.1.min.js" integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo" ></script>
I just signed up for a cloudflare account and began forcing everything to https just to see how it worked, and to my surprise, all my images refused to work over https. now this is something I don't understand because the assets are all linked via:
HTML:
<img src="./images/image.jpg" />
CSS:
background-image: url(../images/image.jpg);
So I figured, I would change it up to use absolute urls with // instead of relative paths:
HTML:
<img src="//example.com/images/image.jpg" />
CSS:
background-image: url(//example.com/images/image.jpg);
this did not work either. so I decided to hard link to https:
HTML:
<img src="https://example.com/images/image.jpg" />
CSS:
background-image: url(https://example.com/images/image.jpg);
and again, not working. what happens is the images all buffer and as soon as they are fully downloaded and displayed,they disappear abruptly.
All of the images are available over https or http so I do not understand the issue here. Would appreciate a little insight into this and whether its a cloudflare specific issue or an issue with how I'm writing my code. Can anyone confirm that relative paths should call assets via whatever protocol is currently in use? ive not seen any issue with it in the past.
Thanks in advance
Odd problem.
Would appreciate a little insight into this and whether its a
cloudflare specific issue
In general, there should be no problem to do what you are asking, there's no CloudFlare issue
or an issue with how I'm writing my code.
Both of your code examples look good to me, the first perhaps preferable because it will work with both HTTP and HTTPS
<img src="//example.com/images/image.jpg" />
Have you
ruled out browser issues by testing with another browser?
cleared the CF cache?
tested with CF set to development mode?
ruled out any app related issues by testing https image loading on a plain HTML page?
tried changing the CF SSL Level (Flexible, Full, Strict)?
if still no joy, can you post a URL?
Good luck!
As it turns out this was a Cloud Flare issue. They have a feature called Rocket Loader, which compresses all your js files into one long minified JS file which was apparently causing one of my scripts to break, only when served over https. It has been raised as a bug with Cloud Flare support (as it is odd that it works over http but not https). This particular issue was with sss.js (Super Simple Slider) the solution supplied by Cloud Flare Support was to change my script tag for sss.js from:
<script type="text/javascript" src="js/sss.js"></script>
and adding data-cfasync="false" to the tag:
<script type="text/javascript" data-cfasync="false" src="js/sss.js"></script>
Apparently this extra bit of code makes Cloud Flare's Auto-Minifier and Rocket Loader ignore that particular file.
I am working with a legacy site that grabs some XML content via AJAX, constructs a block of HTML code with it, and then appends it to a blank div. The XML makes heavy use of Arabic text.
It seems to work fine in all browsers except Chrome. In Chrome, page loading will die at the point of appending the string to the div. When I remove the Arabic text from the XML, the page loads just fine.
The HTML being generated has the following meta tag:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
and the XML has this encoding tag:
<?xml version="1.0" encoding="UTF-8"?>
Here is a sample of the XML that is being passed:
<segment>
<content>السَّلامُ عَلَيْكُم.</content>
<linked>true</linked>
<glossWord>السَّلامُ عَلَيْكُم</glossWord>
<glossTrans>Hello. (Literally "Peace be upon you").</glossTrans>
<glossExpl>This is a very commonly used greeting. It works for any time of the the day. It can also be used to mean 'goodbye'.</glossExpl>
</segment>
Interesting tidbit, when I went to create this question in Chrome, pasting the above into the form ALSO broke Chrome, and the browser froze solid. I had to reopen and submit it in Firefox. If this is a bug in Chrome it would be nice to be able to find a way to work around it, as I don't really like the idea of telling people, "Don't use X browser" to access a site.
Had a similar issue, and it turned out to be Google Translate in Chrome on 10.6.8 having issues when I used multiple languages/characters. I got around this by adding the class "notranslate" onto html elements that I didn't want Google Translate to bomb out on.
To quickly see if this works for you, add the class "notranslate" to your body and see if the page stops hanging. Hope this works for you!
I have a question about the <img> tag src attribute.
Is it possible to hide the <img> tag src attribute when viewing the source in a browser?
If it is possible, how? Please tel me if you have any reliable sources.
No, it's not possible.
You can set them dynamically with JS, but you can't hide them. You can store them as base64 encoded strings, and then decode them on the fly which will "hide" them from your page's source.
However, this is still utterly pointless as in the end, the browser still makes an HTTP request to fetch the image.
Simply spoken: This is impossible.
You might try to obfuscate your image src attributes (JS, Base64, etc), but for the browser to be able to show an image, you'll always end up exposing the image URI.
Which, in turn, means that everyone who knows their firebug will be able to see where your cute kitteh image comes from.
Alternative:
Generate One-Time URIs for your images (quite expensive).
Another good feature is to hide the location paths of your important scripts. I found a great npm plugin for this https://www.npmjs.com/package/location-hide
This works also for php href, src, content it will use everything inside src=""
You need only node.js for creating the exported files. It´s easy to use even if you don´t know node.js
It turns
<script src="test/folder/sample.js" type="text/javascript"></script>
<link href="test/stylesheet/perfect-scrollbar.css" rel="stylesheet">
into
<script src="TNANIuTOLZfmLYwaPDIYhcZDVOWKodqYhysaTeQHFPDhYlDLCOtxZqYmkKAhaSwSgbsYOWlpBzVSBtMZKSfwRqvPSqWVlBBuzHR" type="text/javascript"></script>
<link href="gyXeFnOEvZbgTjLvdZRnsyrfhaXqffkDjcdATTouqpIenCalLRXKamuXEtiKbPGCsNrdQIaqTMTNWsLyLFuxygKytaruWzSjKYMq" rel="stylesheet">
And it generate new jquery include codes like this to include your scripts with javascript in a external file
$('[src=\'TNANIuTOLZfmLYwaPDIYhcZDVOWKodqYhysaTeQHFPDhYlDLCOtxZqYmkKAhaSwSgbsYOWlpBzVSBtMZKSfwRqvPSqWVlBBuzHR\']').attr("src", "test/folder/sample.js")
$('[href=\'gyXeFnOEvZbgTjLvdZRnsyrfhaXqffkDjcdATTouqpIenCalLRXKamuXEtiKbPGCsNrdQIaqTMTNWsLyLFuxygKytaruWzSjKYMq\']').attr("src", "test/stylesheet/perfect-scrollbar.css")
Also I would suggest you that you include all of your external javascript codes in 1 single js file. This file you place in the root of your index file that you can make this
<script src="./allinone_external_file.js" type="text/javascript"></script>
Then make right htaccess that nobody can acces this file. You can also make a fake import script for the source code that every body can see. But this file is only a redirect for the real external js file. you make this multiple times as example + use other obfuscation tools. This will protect you from people searching exploits with your javascript codes. I know its no big deal and maybe you can see the jquery include codes if you know how. But anyway its a great protection.
I've been writing a simple text-editor in HTML5 that is supposed to work offline. I can't, however, get the offline application cache to work, and I can't work out why not.
My manifest file is like this:
CACHE MANIFEST
application.html
options.html
...
And it is being invoked as follows:
<!DOCTYPE html>
<html manifest="cache.manifest">
<head>
...
I'm using Google App Engine to host the web application.
I've put the webpage through the W3C HTML validator (http://validator.w3.org/check?uri=https%3A%2F%2Fwrite-space.appspot.com%2F) and it comes out fine.
I've tested it in Chrome and Firefox. In Chrome nothing is added to the cache storage (and window.applicationCache.status returns 0). In Firefox the notification bar asking to cache the files does not appear. Basically, the files are not being cached.
I've looked at various demos that do cache for offline viewing, and cannot work out why my code does not work.
Can anyone help?
To add MIME-type text/cache-manifest for .manifest files in GAE use this in your app.yaml:
- url: /static/(.*)\.manifest
static_files: static/\1.manifest
upload: static/(.*)\.manifest
mime_type: text/cache-manifest
This would serve all .manifest files in folder static with the correct MIME-type.
You have to add a MIME type to .manifest:
.manifest using text/cache-manifest
In .htaccess:
AddType text/cache-manifest .manifest