I'm working on an application that has a broken manifest file. It's broken in a bunch of ways.
One of the ways that it's broken is that it is being served as type text/plain.
Safari and Firefox ignore it because of this. None of Safari, Firefox, or Chrome show the manifest file being downloaded in firebug/inspector. Safari does show an error in its console about the incorrect mime type.
Only Chrome accepts the manifest file and creates an application cache. (This, of course, causes the application to break horribly, because the manifest's contents are wrong...)
I was under the impression that any manifest served with an incorrect mime type would be ignored.
Should manifests served as mime type text/plain be ignored? Is this a known bug in Chrome?
According to the specification a manifest must be served with mime-type text/cache-manifest.
If a browser interprets a manifest without that mime-type just because it was referenced in <html manifest="xxx"> it's not following the specification for 100%. But in my opinion: that's not a bug, it's a feature! :D
Aside that, why referencing a manifest without the correct mime-type anyway (instead of not referencing one at all)?
This, of course, causes the application to break horribly, because the manifest's contents are wrong...
Reading that I would assume that you just want to clean the appcache of Users already loaded the missconfigured manifest? If that's your intention so try it on the way described there: Removing HTML5 Appcache Manifest, Permanently
Related
Sorry if I repeat, but I couldn't find the answer. This is my website: http://www.stolems.com/pl
My problem is that files css loaded but doesn't applied. I tried in FF, Chrome, Safari and still nothing. But when I load style in tag style it works. What can I do? I noticed that my files css are mime type text/html it should be text/css?
Besides I loaded at this site admin dashboard and template. Admin dashboard works, template not..
Your server is serving .css files with MIME type text/html. It should be text/css. Just tell your server administrator and they will fix it for you.
If you see the console in chrome, it says:
Resource interpreted as Stylesheet but transferred with MIME type text/html.
And in firefox:
The stylesheet was not loaded because its MIME type, "text/html", is not "text/css".
This happened for your .js files too.
if you are using a .htaccess and you have rewriteRules inside the .htaccess then take a good look if you did not forgot to notify the end of the string using a $, if you forget to notify the end of a string most of the mime types get fuzzled up.
For an html5 game I'm making at a company we've hit a snag. In safari it doesn't even seem to be trying to load our manifest file while in chrome it is. And it runs offline too. Is there any huge differences between how the two handle it that trip it up?
I'll check how firefox handles it and update in a bit. This is literally how the cache looks. Already had it validated and everything.
CACHE MANIFEST
#v 1.01
CACHE:
/graphics/Apalia_Map 02.jpg
/graphics/comic/PAGE4.jpg
/graphics/comic/PAGE2.jpg
/graphics/comic/PAGE8.jpg
/graphics/comic/PAGE7.jpg
/graphics/comic/PAGE3.jpg
/graphics/comic/PAGE6.jpg
/graphics/comic/PAGE5.jpg
/graphics/comic/PAGE1.jpg
/graphics/gameComplete.jpg
/graphics/ui/main_menu_bg.jpg
/graphics/ui/apaliaCredits.jpg
/graphics/levels/elpala3-lvl1.jpg
/graphics/levels/elpala1-lvl1.jpg
/graphics/levels/elpala2-lvl1.jpg
/graphics/effects/fswipe_northwest_1_4.png
/graphics/effects/spinfx08.png
/graphics/effects/shieldfx_7.png
/graphics/effects/spinfx01.png
etc...
I have found the answer about this question.....
Safari is more funny than chrome, I can easily make chrome cache my page, but safari does not.
I list these key to make the instruction clearly for the dump like me:
The HTML tag contain Manifest file name like this:
< !DOCTYPE html>
< html manifest="safari.manifest" >
addType, I use apache server, my http.conf contain this in IfModule which contain those addtype:
< IfModule >
....(other content...)
AddType text/cache-manifest .manifest
< /IfModule >
The manifest file name is "safari.manifest". Its content is the most funny part, I have a html that only contain the javascript. I have no image so I don't have anything in NETWORK and FALLBACK. So I don't even fill them in the safari.manifest.
My failed safari.manifest content is:
CACHE MANIFEST
So it does not work.
My success safari.manifest content is:
CACHE MANIFEST
NETWORK:
FALLBACK:
SO FUNNY that I STILL need that "NETWORK FALLBACK" empty blocks in the file to make safari cache the page. If I don't add that two words, Safari will not cache anything.
That's all I found.
not sure as I can't see what is happening, but the problem could be related either to the way you link to the manifest file or (and I'll place my bets now) to the mime-type the file gets sent with (has to be "text/cache-manifest").
I've been using HTML5 Offline caching on my website for a while and for some reasons I am considering turning it off. To my surprise it doesn't work.
This is how I've implemented HTML5 Offline caching.
In my index.html I give path to the manifest file
<html manifest="app.manifest">
In the app.manifest file I list all the js/css/png file that I would like to be cached by the browser for offline usage. Every time I deploy updates, I update the app.manifest file, which causes the browser to fetch latest version of all the files listed in the manifest file.
In order to turn off the offline caching, I changed my index.html's opening tag to
<html>
I made a dummy change to app.manifest file, so that browser (which has already cached my website), will detect the change and download latest version of all the files (including index.html).
What I noticed is, the browser indeed gets the latest version of all the files. I see the new <html> tag in the updated version without the manifest declaration, however the behavior of the browser for future changes does not change. i.e. I now expect the browser to immediately fetch the new version of the index.html file, when it's changed on server. However that doesn't happen. The browser doesn't download updated index.html until I make any changes to the manifest file.
Thus it appears to me that the browser has permanently associated app.manifest file with my website URL and it won't get rid of it even when I don't mention it in <html> tag.
I have tested this on both Google Chrome and Firefox, same results. I also tried restarting Chrome, but it won't forget that my site ever had app.manifest defined for it. I haven't found any discussion on this aspect of offline caching on the web.
Update: I managed to get rid of the behavior in Chrome by clearing all the browsing data (by going to settings). But that's not something I can tell the users to do.
Make the manifest URL return a 404 to indicate you don't want offline web applications anymore. According to Step 5 of HTML5 ยง5.6.4, this marks the cache as obsolete, and will remove it.
You can also manually delete the offline web application in Chrome by going to about:appcache-internals.
When users visit our website's download page, it automatically starts the download. The page has a display:hidden iframe with src pointing to the installer file
<iframe src="/path/to/installer.dmg"></iframe>
This works fine so far. But my Chrome extension: "Web developer" logs this Warning message
Resource interpreted as Document but transferred with MIME type application/octet-stream
So, is there a way to explicitly declare installer.dmg's content-type as octet-stream, so that browsers do not get confused?
As one of the previous answers references a broken link I will give my answer here.
If you are trying to specify the mime type of files with a certain extension you can add this to .htaccess:
AddType application/octet-stream .dmg
However, this will not guarantee that browsers will 'download' the file. Chrome for example does not recognise this. So here is a way to force files of a certain type to 'download':
<FilesMatch "\.(?i:dmg)$">
ForceType application/octet-stream
Header set Content-Disposition attachment
</FilesMatch>
The little bit of regex around the extension (dmg) is just there to make it case insensitive.
You might need to clear browser cache before it works correctly.
This works in the latest Chrome, Firefox and IE8 (as of August 2013). I have not tested in the latest IE or Safari, so if someone has those browsers and can test them, please confirm they work in the comments below.
Insert those lines in your vhost configuration, inside a docroot directory:
<Directory path/of/your/docroot/directory>
<Files path/of/your/file>
Header set Content-type "mime/type"
</Files>
</Directory>
This page has what you need, if your web server is Apache. Basically what you do is tell apache that any file with a .dmg extension has the mime-type of application/octet-stream.
The problem is that you are using an installer file as a web page
what you can do is open the installer page in a popup on document ready
you can read this (with jquery): http://choosedaily.com/1178/15-jquery-popup-modal-dialog-plugins-tutorials/
or this(no jquery): http://www.quirksmode.org/js/popup.html
I have declared AddType application/x-font-woff woffbut chromium still always give me the message Resource interpreted as Font but transferred with MIME type application/octet-stream. What is going on here, it seems to be a rather common problem. This is Chrome version 14 by the way.
This was actually a legitimate bug in chrome at the time of posting, not sure if it still exists and can't find the relevant link to chrome bug list. If anyone is interested that'd be the first place to look.
Old question but a possible answer for future visitors:
Chrome caches the heck out of things - even when you change the header from the server, Chrome may still load the resource from it's cache. So clear the cache and if necessary, check the headers from a realtime web-checking service.