Imagine an image with url https://example.com/image.jpg is accessed from page https://example.com/ . If another web page say, http://another.com/page shows https://example.com/image.jpg on the page, will the image cached by the browser be shown or new image will be requested from the server.
The image will be cached by the browser, unless you specify otherwise in your browser's settings or the page serving the image specifies otherwise in its response headers. In fact, this is the main point of caching: to improve load times by avoiding repetitive requests to the same URL.
Related
If I've loaded an image into an html page, when I load it a second time further down in that page will it be instantly available?
Depends on the headers sent with the image, but I believe most browsers will cache images automatically. That should work fine as long as the URL is the same. Check the network request to make sure the image is only being requested once from the server.
My question is rather simple. Is there a way in the cache manifest file (or In the html) to tell iPhone, iPad or other never to cache specific files?
I have a made a small webpage that also works as a web app and there is some of the page that never should be cached.
Yes, you can list the files in the Network section to tell the browser to never save the files.Lines from the book diveintohtml5
The line marked NETWORK: is the beginning of the “online whitelist” section. Resources in this section are never cached and are not available offline.
For device or browser specific manifest, you can not do anything from JavaScript side. You have to do additional server side detection for that.
The files listed in the .mf file are the same files i am trying to load when the page first runs. Does having a manifest attribute defer processing of the rest of the document until the appcache loads?
No. On the very first load the cache gets built in the background, using the same files that where just downloaded, provided they have proper cache settings. E.g. If you have foo.css with long cache headers in your HTML page and the manifest, the browser will:
Load and render the page.
Look at the manifest.
Load foo.css from browser cache to appcache.
BUT: Appcache will however result in a FOUC (brief white page on reload), even if online and the page/app was made well enough so far to show smooth reloads.
With AppCache, the browser loads the document and its associated resources directly from the cache, without accessing the network, so this should load just as fast if not faster.
How do I force caching of pages, scripts, images(resources) including the results of dynamicly generated content (php,asp,etc etc), I do not have control of the website in question and I understand that if I cache a dynamic page it becomes static,, thats fine for me,,
However... I do not want to cache everything.. the pages loads default.asp,,,as well as a tone of .js scripts,,, in turn which make calls to a API returning some XML,,
I want to cache the default.asp and all .js but not the xml files.
im using chrome and chrome is aggressively caches what it can but all the stuff from this site has a max-age=0 header.
so from chrome how can I override headers for individual resources?
I've switched my Facebook page to pull an iframe as a result of Facebook's recent announcement that they were supporting iframes in pages. Since you need to host the iframe page outside of Facebook, I figured it would be nice to do using Cloudfront to host the files (an HTML page, a CSS stylesheet and a jpg image). Unfortunately, despite setting the permissions on the Cloudfront files to 744, the iframe page loads correctly in a browser, but when called from Facebook, I get this error message.
When I host the same files on my Media Temple server, the iframe on the actual Facebook page also loads correctly.
Is there a reason why Facebook and Cloudfront don't play together? I haven't been able to find one so far.
Unfortunately Facebook loads the iframe page using an HTTP POST, not an HTTP GET and is not compatible since Amazon has a REST interface and properly uses POST to upload/modify content.
Best,
David Bullock
I ran into this problem today and it caused some headscratching. As David Bullock points out the problem is that Facebook loads the HTML page via a POST request but S3 (and thus by extension CloudFront) won't serve resources in response to this (it returns 405 Method Not Allowed).
You can host your CSS, scripts and images on S3 / CloudFront, but the initial HTML page has to be on some other server. If you're concerned about load or latency from across the globe then you could try implementing a tiny redirector that forwards the Facebook POST request to the CloudFront-cached location (you'll have to return 303 See Other to do this redirection so the browser makes a GET request instead: see RFC 2616).
There is a shockingly easy workaround to the fact that AWS rejects POST requests and the fact that Facebook requires page tabs to be hosted via HTTPS: just redirect the request through https://bit.ly/….
Yes, it's really that easy.
Host the HTML page wherever you like. HTTP is fine.
Create a bit.ly-shortened URL to the page.
Use it—substituting https:// for http://—as the "Secure Page Tab
URL" as you create your Facebook Page Tab.
Activate the tab using this highly-undocumented dialog URL: https://www.facebook.com/dialog/pagetab?app_id=app_id&redirect_uri=bitly_url
Boom: done.
OK, it can be done: but you need to host the images on Cloudfront and the rest of the content on S3. Amazon provides a set of clear instructions on how to this. Issue solved.
Use Cloudfront to trap the 405 error and serve your html as the "Custom Error Response" page to the desired index page
Updated:
This was down voted, however I'm going to help lots of Facebook developers with the following. The final Issue that we had with hosting a facebook application on S3 was with CORS. We fixed the 405's by doing a "Custom Error Response" See this link for details:
http://blog.celingest.com/en/2014/10/02/tutorial-using-cors-with-cloudfront-and-s3/