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
Related
Related question here.
Boris' answer to the above question seems to make sense, but I installed the Font Awesome files on my server and the problem remains:
I looked into the library and found that the font files are included in the install, so the argument about cross-server access to fonts doesn't seem valid. I don't mind using the BootstrapCDN, but then Boris' suggestion seems to apply, and I don't know how to send the right CORS headers. (I tried it, but it doesn't work either.) Any idea how I can fix this, either using the "Bootstrap CDN" or the "default CSS"? (see also these instructions.)
PS: IE10 shows the glyph correctly.
Did you try Bootstrap CDN?
Just include <link href="//netdna.bootstrapcdn.com/font-awesome/4.0.3/css/font-awesome.css" rel="stylesheet"> in your <head> section. Font files will be loaded automatically from CDN, too.
Checked this on Firefox and it works perfectly.
#Boris says:
Firefox only allows cross-domain linking of fonts if the server the font is on sends the right CORS headers.
So it's clear that it's CDNs duty to set the right headers, not yours. And them seem to do that correctly, because Firefox doesn't complain.
If you host fonts on your own server, keep in mind that cross-domain rule may still apply, e.g. font files places under example.com may be unaccessible from www.example.com, if www.example.com doesn't send the right headers.
Read this answer for tips about bypassing cross-sub-domain restrictions - this might help in your case.
Put in a custom CSS the following (for me it solved the problem):
#font-face
{
font-family:'FontAwesome';
src:url('./fontawesome-webfont.eot');
src:url('./fontawesome-webfont.eot?#iefix') format('embedded-opentype'),
url('./fontawesome-webfont.woff') format('woff'),
url('./fontawesome-webfont.ttf') format('truetype'),
url('./fontawesome-webfont.svg#FontAwesome') format('svg');
font-weight:normal;
font-style:normal
}
[class^="icon-"]:before,
[class*=" icon-"]:before
{
font-family:FontAwesome;
font-weight:normal;
font-style:normal;
display:inline-block;
text-decoration:inherit
}
I am having same issue, we use the fonts on router board using micro httpd.
i added Access-Control-Allow-Origin: * header but not working for me.
i found in firebug that the woff file is not returing anything in response text. the same thing if i use CDN url, everything works fine. so on local micro-httpd server need some mandatory header to configure. please tell me also the exact mime types for all fonts needed.
.ttf", "application/x-font-ttf"
.eot", "application/vnd.ms-fontobject"
.woff", "application/font-woff"
.svg", "image/svg+xml"
solution to make the fontawesome css work locally is to include the files under Fonts folder into the same directory of .html files(pages).
eg:File structure as of now where fontawesome is not working
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\styles\font-awesome\css\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
The issue here is that for a page loaded from a file:// URI, only files in (or below) the same directory of the filesystem are considered to be "same origin", and so putting the font in a different subtree (../font/) means it will be blocked by security policy restrictions.As Firefox disables cross-domain fonts "by default.
Instead change the file structure as below:
prototype\pages\.html files
prototype\styles\font-awesome\css\font-awesome.min.css
prototype\pages\fonts\fontawesome-webfont.eot,fontawesome-webfont.woff
place the fonts folder under pages directory which fixes the issue.Hope it helps.
some-class-name:before
{
content: attr(\f021);
}
worked for me
If you are the owner of your own server, you can add a HTTP header to deal with that problem. Problem based on cross domain policies.
example.com/font-awesome.woff
boo.example/index.htm
in that case you should add that header to example.com
Access-Control-Allow-Origin = "http://boo.example"
or
Access-Control-Allow-Origin = "*"
that will make your font file reachable from other sites or specific site.
Be sure your paths are correct. Use the fa class and the icon class like:
fa fa-envelope
and will work great..
Greetings.
In Chrome I get the following error messages in the console
[blocked] The page at https://domain.com/home.html ran insecure
content from
http://domain.com/typo3temp/stylesheet_09c1ef800c.css?1345207892.
if I call https://domain.com. The user gets a page without stylesheets and images. What can I do against this?
The files are included like <script type="text/javascript" src="js/lib/jquery-1.5.1.min.js"></script> but I don't want to define the domain.
Should I completely switch to https by setting the base URL with https? Which other possibilites do I have?
I used
config {
baseURL = https://domain.com
}
and adapted all links which had a http in the beginning (otherwise the slider stopped working because Chrome didn't load the other ressources ...). Seems to work now.
I'm using bootstrap and I added font awesome through Less, overriding the Glyphicons. The icons display OK in chrome but in Firefox i just see boxes.
This is how my directory looks like
-- Project
-- js
-- css
-- less
-- font-awesome
-- css
-- font
-- less
All I've modified in the Project > less > boostrap.less file has been:
#import "sprites.less";
//for this line
#import "../font-awesome/less/font-awesome.less";
As I said in Chrome works fine but for some reason Firefox shows only boxes.
Custom web fonts via CDN (or any cross-domain font request) doesn't work in Firefox or Internet Explorer (correctly so, by spec) though they do work (incorrectly so) in Webkit-based browsers.
You can fix this by adding headers to your page.
Apache
<FilesMatch ".(eot|ttf|otf|woff)">
Header set Access-Control-Allow-Origin "*"
</FilesMatch>
Nginx
if ($filename ~* ^.*?\.(eot)|(ttf)|(woff)$){
add_header Access-Control-Allow-Origin *;
}
Credit: http://davidwalsh.name/cdn-fonts
If you want a quick and easy way to make Font-awesome work, try using CDNJS. It's free and powered by CloudFlare. CORS is supported out of the box.
Try something like this:
<link href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/3.2.1/css/font-awesome.min.css" media="all" rel="stylesheet" type="text/css">
If you are hosting the font on S3, you have to enable CORS on the bucket. Through AWS Management Console, edit the properties for the bucket and under Permissions click on "Add CORS Configuration". In my case, if I left the default config, it still didn't work, so I changed it to:
<CORSConfiguration>
<CORSRule>
<AllowedOrigin>*</AllowedOrigin>
<AllowedMethod>GET</AllowedMethod>
</CORSRule>
</CORSConfiguration>
I was having issue with the if statement because I didn't have a $filename variable.
But I did have similar results using:
location ~ /\.(eot|otf|ttf|woff)$ {
add_header Access-Control-Allow-Origin *;
}
Using a CDN as premjg suggested is the least invasive method besides hosting it yourself. The latest version of fontawesome suggests bootstrapcdn, e.g.,
<link href="//maxcdn.bootstrapcdn.com/font-awesome/4.2.0/css/font-awesome.min.css" rel="stylesheet">
As a minor note, noscript silently blocks requests to the CDN unless whitelisted, and it won't prompt you to whitelist the CDN unless your page also requests JS files from the same domain.
If you're like me, modifying a web.config file is something you're not allowed to touch.
Try storing all the font files (.eot, .ttf, etc) into their own local folder, and link to them locally instead of the FontAwesome CDN. Cleared it up in IE and FF for me every time.
#font-face{ font-family:'FontAwesome'; src:url('../_fonts/fontawesome-webfont.eot'); }
If you're using wordpress and you think you've tried everything, look and see if you ever installed a Font Awesome plugin. Disable the plugin and refresh in Firefox.
This was the solution for me - the plugin's older version of font-awesome was overriding the files I was trying to update myself manually.
In fonts folder please upload the following files
FontAwesome.otf
fontawesome-webfont.eot
fontawesome-webfont.svg
fontawesome-webfont.ttf
fontawesome-webfont.woff
------------------ Important glyphicons files----------------
glyphicons-halflings-regular.eot
glyphicons-halflings-regular.svg
glyphicons-halflings-regular.ttf
glyphicons-halflings-regular.woff
Please upload the following files and after that you link your font-awesome.min.css in your header file.
Here is the following link with proper files:
http://goo.gl/WICQAf
I am using a favicon which is linked in all pages using <link> tag. This favicon is stored in a folder inside the root folder, and I have another favicon stored in the root folder also. When the site loads fully the favicon which I am referring to is shown correctly. But when I stop the site before loading completely then it shows the favicon from the root folder.
Is this the default/desired behavior?
Thanks
I'd say yes.
The only way the browser can find your correct favicon is by using the <link> tag. If that tag's not present or parsed correctly the browser will have to fall back on its default behaviour which is to look for a file called favicon.ico in the root folder.
I don't know about desired behaviour, but it is to be expected. The browser will request /favicon.ico by default, and the <link> is considered an override.
You will find for most browsers, they will actually fetch both, but display the <link> by preference.
Most browsers, if they don't find a <link rel="icon"> or <link rel="shortcut icon">, fall back on the old bog-standard of showing /favicon.ico . Some can be configured to avoid this (e.g. Opera has this in GUI config), some will look for /favicon.ico regardless.
This is an artifact of the Browser Dark Ages and no fault of your own.
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?