I'm using the application cache to make my website also work offline.
My manifest looks something like this and is embedded using an <iframe>:
CACHE:
favicon.ico
assets/css/style.css
assets/js/libs/zepto.js
assets/js/app.js
NETWORK:
*
FALLBACK:
/ offline.html
it works as expected when I cut the internet connection -> everything is served via the offline.html page.
but just now I found out that every 404 (e.g. an URL that never existed on the server) also uses the FALLBACK section in the manifest on displays the offline.html.
is there a way to distinguish between being offline (in which case the offline.html is the right choice) and the server returning a 404 (in which case I just want to display the 404 error)?
Appcache will FALLBACK if the original request...
...results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors
(from http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#changesToNetworkingModel)
Unfortunately, when a fallback occurs, there's no why to find out why. You can't differentiate between a 500, 404, redirect or failed connection.
Here's a hacky workaround:
FALLBACK:
/connection-test.js connection-failed.js
/ offline.html
You could embed connection-test.js in your offline.html page. connection-test.js loading would indicate the user has a connection, connection-failed.js would indicate there's no connection.
I came across your post while searching for a solution to this same problem.
What I ended up doing was checking the value of navigator.onLine in my fallback page (which, in your case, would be offline.html). If navigator.onLine is true, then the user is supposedly online/connected to the internet (caveats apply), and were sent to the fallback page because the file they requested was not found. So, then I change the content of the page to that of a 404.
Example:
<script>
header=document.getElementById('header');
error_message=document.getElementById('error_message');
if(navigator.onLine){
header.innerHTML='Page not found';
error_message.innerHTML='The page you requested could not be found. Please check the URL and try again.';
}
</script>
It would certainly be great if the application cache spec included some other way of handling 40x's and 50x's. While this solution is certainly not ideal, it's the best one I could come up with.
I hope it helps.
Related
Up until several weeks ago I was able to stream icecast and shoutcast on my HTTPS site. This would create a "mixed content" warning but was never explicitly blocked.
Now I find that chrome is forcing the http://streaminglink urls to load https://streaminglink and I can't access the http audio anymore.
Here is a code example in jPlayer
$("#jquery_jplayer").jPlayer("setMedia", {
mp3:"http://149.202.79.68:8213/stream.mp3"
});
I expect chrome to load the http url but instead it is looking for the https and I get the following error in the console:
GET https://149.202.79.68:8213/stream.mp3 net::ERR_CONNECTION_CLOSED
NOTE
The https ^ - that's not coming from my code or configuration... =/
So it looks like this is default behavior for Chrome since 79.
https://www.engadget.com/2019/10/04/chrome-security-block-http-content/
Broke my site. Thanks Google.
you can now allow insecure content in the specific site settings
chrome://settings/content/siteDetails?site=https%3A%2F%2F<SITE_DOMAIN>
I've been working on an Spring MVC application that has custom error pages, these pages return a generic error message and the stack trace as an HTML comment. I'm currently developing the offline funcitonalities of this application using HTML5's Appcache. My manifest is something like this:
CACHE MANIFEST
CACHE:
... my explicit entries (not relevant) ...
FALLBACK:
... some fallback entries (not relevant) ...
<!-- This next line is relevant --!>
/ pageNotFoundOffline.html
SETTINGS:
prefer-online
Which is supposed to serve a previously cached 404 page when the user can't connect to the server, the problem is that it also serves this 404 page when an error occurs, thus rendering completely useless the custom error page already implemented in the application.
Why i want to do this? i want that whenever a user tries to access any page on my application and the request fails with a 404 (either because the is no available internet connection or because the servers are down), that user is informed that the request failed and he or she is being redirected to our offline functionalities, also i want to inform the user when he or she succesfully reached our servers but an internal error occurred (through the custom error page).
Is there a workaroud for this problem?, what i would like to accomplish is the cached 404 page to be served only when there is a 404 exception and the custom error page returned by the server to be displayed when there was an internal error.
I'm afraid that it is not possible with appcache - the fallback intercepts all server errors. The specification for appcache says: "If this results in a redirect to a resource with another origin (indicative of a captive portal), or a 4xx or 5xx status code or equivalent, or if there were network errors (but not if the user canceled the download), then instead get, from the cache, the resource of the fallback entry corresponding to the fallback namespace f. Abort these steps."
If you can use the more modern way of doing things, Service Workers, I would recommend using that, as that will let you do what you want.
I'm delivering a manifest for my app that looks something like this
CACHE MANIFEST
#1359542586541
NETWORK:
*
FALLBACK:
/ /index.offline
When offline, it works correctly by returning index.offline on the index path, however it has the side-effect of returning index.offline for every other resource as well. i.e. The / pattern is acting as a catchall.
Is there any way of matching the index page without everything else so only the homepage uses the fallback?
One irritation this causes is that it seems to return index.offline whenever a request returns a 500 status
No, the first URL in a FALLBACK is a prefix match. The only way is to always use the explicit index page rather than rely on default documents:
FALLBACK:
/index.html /index.offline
There was a discussion of the behaviour for 500 errors on HTML5 Help mailing list last February including several responses by the spec editor, this message specifically talks about FALLBACK sections.
I've got a canvas element on my website which, for some users, is throwing cross domain exceptions. The issue has occurred in Chrome, Firefox and Safari, but I've been unable to replicate it myself in any browser.
The console output from Chrome is:
Unable to get image data from canvas because the canvas has been tainted by cross-origin
data.
The error is thrown by the library StackBlur.js, where it calls imageData = context.getImageData( top_x, top_y, width, height );
However, the images used on the site are all on the same domain, protocol and port. The paths are generated by Rails. The main path is like https://myappp.com/ and the image paths are like https://myapp.com/assets/promo/slideshow/slides/myslideimage.jpg
Deploying the exact same code on our staging site (which does not use HTTPS) http://staging.myapp.com/ with image paths like http://myapp.com/assets/promo/slideshow/slides/myslideimage.jpg results in no errors.
Why might the use of HTTPS be causing cross-domain issues?
Thank you.
I was mostly mistaken. It turns out that our redirect from http to https was on the blink, so a user was able to visit the http version with assets from https, meaning that the error was entirely legitimate all along. I never reproduced it because I visited the site from my browser history, which was https.
Fixing our redirect so both the main request and assets are on the same protocol resolves the issue.
I have a manifest that looks somethin like this:
CACHE MANIFEST
# e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a
/a/application.js
/a/application.css
NETWORK:
*
FALLBACK:
/ /offline/redirect
The issue is that my /404.html and /500.html pages (that are obviously served up with a response code of 404 and 500) are triggering the fallback. They both act just as if the server is offline.
My question is twofold:
Why does /404.html trigger the fallback when /events doesn't?
How can I allow /404.html and /500.html to not trigger the fallback while still allowing / to
trigger it.
For what it's worth, I've already tried this:
NETWORK:
*
/404.html
/500.html
... however since those pages are served w/ a non-200 response code, it triggers the app cache error callback and the cache isn't saved.
Thanks!
What worked for me:
Remove * from the NETWORK declaration
Redirect to /404.html (et al) instead of rendering in place.
So using the example above: /teams/1241231 302 redirect to /404.html which returns a 404 status code.