My AMP pages are passing validation, but some images are 404'ing. When accessing the pages from my site, the images load correctly. However, when the pages are loaded from Google's AMP CDN (I believe they cache all the pages) certain images return 404s.
In the network tab, I noticed that the image GET requests are correct when on my site (content-type: image/png). Google's cached pages, on the other hand, make a GET request with content-type "text/html" for the images that don't load. The GET response is a basic HTML page indicating a 404.
It should be noted that several images do load successfully. They're stored in both an image folder, and remotely on a parse-server. Both image locations have successfully provided pictures, just not all the time; and I can't seem to find any inconsistencies that could cause some to respond 200, others 404.
I would greatly appreciate any tips for figuring this one out!
edit: Is it possible that Google hasn't cached the images yet? The page itself is definitely cached.
The problem is that you're using a relative path to the image instead of an absolute path. So the following <amp-img> tag,
<amp-img ... src="/images/city_images/633_Image.png">
needs to be
<amp-img ... src="https://chargehub.com/images/city_images/633_Image.png">
That should fix your issue.
When loading your sample link, I get a 404 for https://cdn.ampproject.org/ii/w1000/s/chargehub.com/images/city_images/633_Image.png. When I request the corresponding original image from your server, I see a Cache-Control: no cache header:
% HEAD https://chargehub.com/images/city_images/633_Image.png | grep Cache-Control
Cache-Control: no-cache
While I don't have any guesses about why other images that are also served with Cache-Control: no cache, like https://chargehub.com/logos/ChargeHub-Logo.png, do get cached, I would try instructing your web server to not set this header to see if that helps.
Problem located! The images were originally pulled off of Google's Image API. The API allowed me to specify a file format (I wanted .png's). Unfortunately, if the image Google had was a JPEG, they simply added a .png extension to it and returned it to me.
Basically, if the AMP-IMG was expecting example.png, it only works if example.png is truly png encoded (you can tell the encoding by opening the file in a text editor, PNG will have a "png" near the top).
In my case, example.png was actually example.jpg RENAMED to example.png (jpeg encoding still). Google's caching service doesn't like this, and returned a 404.
I simply renamed all my photos to .jpg extension, and then batch converted them to true .png's using Photoshop. Hope this helps if anyone else is stuck!
Related
Various flavors of this have been asked already, but I've yet to see a real answer for this.
We have a separate image service that our web app uses to get some of its images. The image service is well tested and is functioning properly. To make it concrete, our app is served from domain.com. The src element of img elements is images.domain.com/{imageId}. The image service retrieves the URL for the image and sends back a HTTP 302 redirect for the image.
The application allows users to change images. So say a user 5 has image A as a profile image, and decides to change it by uploading image B. When the user uploads the image, the application cache is properly invalidated and the database is updated. The application does a standard redirect after POST and one of the elements in the page that the user is redirected to after changing her image is something like:
<img src="example.domain.com/5">
The problem is that Chrome never makes the call to example.domain.com/5 to retrieve the image upon the initial redirect or a regular reload of the page, it simply serves image A from the browser cache. A standalone call to example.domain.com/5 correctly returns image B, and a hard refresh or clearing Chrome's cache forces Chrome to request the image's src, which correctly returns image B. Note that I'm not talking about serving either image from the cache after getting a 304 Not Modified response, I'm talking about Chrome deciding not to visit the img src at all and just returning image A. Also, appending some unique query string to the img's src attribute fixes the problem, but that's a hack that we'd rather not have to do.
It's worth noting that Firefox was doing the same thing initially. There were no Cache Control headers in the response initially. We added a Cache Control: no-cache header (and tried no-store as well) to the response header and this fixed the behavior in Firefox, but Chrome and Safari still serve the outdated, cached image without making a call to the image's src.
It looks like this was a longstanding bug in Chromium (https://code.google.com/p/chromium/issues/detail?id=103458) that's allegedly fixed as of about 6 weeks ago, but we're using the most updated version of Chrome.
We've looked at the answers here and here but they don't actually answer the question.
Per section 14.9.1 of RFC 2616:
If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
Unless we're missing something or doing something wrong, it would seem that Chrome (and Safari) are not complying the RFC behavior for no-cache headers for 302 redirects? Anyone experience this before or have any insight?
cache-control: no-store
I had the same maddening problem that you described (slightly different in that it was a missing cookie redirect back to the login page) that worked everywhere but Safari.
In desperation, I came across this open WebKit bug and saw the fateful comment (and finally a glimmer of hope):
CachedRawResource now keeps the redirect chain, and has some trivial logic for checking correctness, but it's nowhere near complete (only checks cacheControlContainsNoStore()). And of course other resource types don't have anything.
Added no-store to my cache-control header and no more problem.
Please read this.. https://www.hochmanconsultants.com/articles/301-versus-302.shtml
Chrome has pretty aggressive caching.
When you use a temporary redirect, you are basically saying that the actual URL is temporarily unavailable so use this other URL instead. Chrome rightly caches the old URL because it is still valid. Try a 301 instead. Then Chrome should know that the original URL is no longer valid.
I have a issue of displaying .png images on web my web page. Other image types excluding .png just work fine. The issue is .png. The web site is located in a sub domain. In the root, a wordpress site is running.
In firebug, I can see a 403 error. But I can assure that I have set 0777 permissions for all images. It couldn't be a permission issue.
Rarely, .pngs are loading. But the second request gives a broken image. I have applied different cache removal techniques including <FilesMatch> directive in .htaccess, appending version attributes to image link, using # ...etc. But nothing works.
The most complicated point is that when copy & paste the image link in browser it shows the .png. However not within a web page.
Can anybody help me resolve this?
Thanks in advance.
Even I tried executing it in a browser. But the .png image doesn't showup for me.
Try changing the image folder permission to 755 or 644.
My browser is session authenticated with a website.
I am using their API to pull down images from the site so I can display them on my page.
Visiting that image url displays the image, putting it in an img tag does not:
<img src = "https://files.something.com/123123" />><!-- this doesn't show -->
arse<!-- this works -->
Any ideas on why? and how I might overcome it?
If I put in http for the link, it redirects to https any way.
There's two things worth bearing in mind here:
Your host is automatically redirecting to https. Is this deliberate?
I suspect that you're seeing coming up against cross-domain security, or that your server is actively refusing it.
To trouble-shoot: you'll want to find out what response you're getting from your images.
Open up either the 'NET' tab in Firebug, or 'Network' in Chrome Developer Tools and watch the page-load. I suspect you're going to see those images come through red with an error number. Once you've got that it's very easy to trouble-shoot why the server's refusing to serve the images.
I have a wordpress site here http://itrain.com.my/v3/ as my Home Page
I am wondering why it is not displaying well in Firefox?
Anyone who is good in css?
By the way, try to look at the subpages http://www.itrain.com.my/v3/index.php/about-us/
it display well.
I am really wondering why does it happening.
Any can help me? Any suggestion, recommendations?
I think problem is with URL.
It work http://www.itrain.com.my/v3/ but doesnt work on http://itrain.com.my/v3/
Set on your server redirection (301) from non-www URL to www URL.
I would wager you have the font installed on your local machine. I don't see it on any browser. Instead, I get two 404 errors.
In other words: please make sure the font files are available at the locations their respective locations: http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/big_noodle_titling-webfont.woff and http://www.itrain.com.my/v3/wp-content/themes/itrain/img/fonts/bebas__-webfont.woff.
[EDIT]
I've just looked at the fonts directory listing on your site. The ttf and eot versionf of your fonts are available, the woff and svg are listed, but result in a 404 error. Furthermore, the ttf version (downloaded instead of woff in Firefox, after getting a 404) seems to generate an empty HTTP response.
So... Make sure the fonts are there, make sure they have proper privileges set (like 0644). I can't see any other issues than the font files themselves as the CSS appears to be correct.
[EDIT 2]
#kubedan provides a great tip that seems to fit your concern about the htaccess: the domain the fonts are downloaded from is always preceded with www. Firefox will refuse to download such content, you need to use the same domain.
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/