I'm running the beta of Google Chrome (12.0.742.60)
My page displays fine, however for some reason, in the Developer Tools 'Resources' tab, it's CSS file is shown under the 'Images' disclosure triangle instead of 'Stylesheets' (where the typekit.com CSS is as expected.) Grateful for any ideas..
CSS tag:
<link rel="stylesheet" type="text/css" href="/styles/lofkch.css" />
CSS response headers (via 'Web Developer' extension):
Date: Sat, 21 May 2011 18:52:30 GMT
Content-Length: 9218
Last-Modified: Sat, 21 May 2011 18:40:50 GMT
Server: Apache
ETag: "5ff9-2402-4a3cd93cab080"
Content-Type: text/css
Accept-Ranges: bytes
200 OK
Live page - REMOVED - see answer for cause.
Aside: There was an excellent Google IO session on the new features in GDT earlier this month.
What happens if you remove the empty background-image?
Related
Site running Google Cloud CDN -
According to numerous test is not Caching webp images - potentially all images.
This was corroborated with GTMetrix.
Initially, I used the Cloud CDN configuration of "Cache Static Content".
and later upgraded to "Use origin settings based on cache-control headers"
Current Cache Settings:
I am still seeing images, particularly webp not being cached by CDN.
I have also updated the .htaccess file to increase the TTL for webp.
Htaccess images TTL
How can I get these images cached properly in cloud CDN?
Just adding to elving's answer - the report is wrong - your site is using CDN for images too.
I've fallowed official documentation on troubleshooting GCP's CDN.
Just run curl -s -D - -o /dev/null https://mydoginsurance.com.au/images/banner.webp and you should get:
HTTP/2 200
server: nginx
date: Thu, 25 Feb 2021 12:26:01 GMT
content-type: image/webp
content-length: 130564
last-modified: Fri, 16 Oct 2020 10:12:50 GMT
etag: "5f897222-1fe04"
x-powered-by: PleskLin
accept-ranges: bytes
via: 1.1 google
cache-control: max-age=86400,public
alt-svc: clear
and when I ran it again a few minutes later:
HTTP/2 200
server: nginx
date: Thu, 25 Feb 2021 12:26:01 GMT
content-type: image/webp
content-length: 130564
last-modified: Fri, 16 Oct 2020 10:12:50 GMT
etag: "5f897222-1fe04"
x-powered-by: PleskLin
accept-ranges: bytes
via: 1.1 google
age: 223
cache-control: max-age=86400,public
alt-svc: clear
Third last line is age: 223 which means that this reponse was served from cache created 223 seconds ago;
The last response in this example includes an Age header. Cloud CDN adds an Age header to responses that it serves from cache. Here, the header indicates that the response was successfully served from cache by using a cache entry that was created two seconds ago.
That GTmetrix report is simply wrong. They apparently don't correctly detect use of Cloud CDN. I see cache hits from Cloud CDN for images such as /images/banner.webp.
There's information on troubleshooting cache misses at https://cloud.google.com/cdn/docs/troubleshooting-steps#responses-not-cached that you can use to double check.
I am seeing circular redirects in the Facebook Sharing tool I cannot explain on a post written in Wordpress:
This is not as Facebook debugger reports "Circular redirect path detected" (301) on certain website : I have the og:url metadata defined in the page
WordPress post: http://tademo.trueanthem.com/evergreen/posting-just-fun/996/ -> You can see is has the right og:url meta: <meta property="og:url" content="http://tademo.trueanthem.com/evergreen/posting-just-fun/996/" /> and also <link rel="canonical" href="http://tademo.trueanthem.com/evergreen/posting-just-fun/996/" />
Facebook Sharing Debugging Tool: https://developers.facebook.com/tools/debug/sharing/?q=http%3A%2F%2Ftademo.trueanthem.com%2Fevergreen%2Fposting-just-fun%2F996%2F
The detected canonical page is chopping the last /996/ from the or:url/link canonical
These are the reported redirects
I run curl to check if there was a redirect, and there is no redirect:
$ curl -IL 'http://tademo.trueanthem.com/evergreen/check-ga-ia/986/'
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 06 Nov 2017 18:15:49 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=20
X-Pingback: http://tademo.trueanthem.com/xmlrpc.php
Link: <http://tademo.trueanthem.com/wp-json/>; rel="https://api.w.org/"
Link: <http://tademo.trueanthem.com/?p=986>; rel=shortlink
X-Cacheable: SHORT
Vary: Accept-Encoding,Cookie
Cache-Control: max-age=600, must-revalidate
X-Cache: MISS
X-Pass-Why:
X-Cache-Group: normal
X-Type: default
$
What is going on here?
Well, it looks like the Facebook crawler does not like the 3 digits at the end of the permalink. I removed the 3 digits in the permalink for all posts, and now the Facebook Sharing Tool has no problem.
Context
My github pages are not refreshing. After diagnosing my conclusion is it's a server side caching effect.
What I did + diagnostic results
The site is working OK.
I made a change in index.html in my local
repo, then commit and push
I completely cleared my browser cache (btw also using cache clear plugins, and Chrome dev tools set not using cache)
Reloaded the page, with ctrl+f5 and ctrl+R (change is not applied)
Checked using github.com read index.html, the change is there, committed.
Monitored the traffic with Fiddler. The request for index.html sent, full response received, the content is the old NOT changed.
Examined the response header with Fiddler, says: (see header exhibit)
Reverse diagnostic
I've issued a request with a usual trick typeing: index.html?v001orAnythingYouWant and I got the new version of the page
Problem
Problem solved one can say, but it is not true. When I refresh images, css, js still this effect will prevent me to see the new result.
Question
How can I configure or overcome this server side caching, of course only for development/testing time?
Response header exhibit
HTTP/1.1 200 OK
Server: GitHub.com
Content-Type: text/html; charset=utf-8
Last-Modified: Fri, 06 May 2016 12:24:29 GMT
Access-Control-Allow-Origin: *
Expires: Fri, 06 May 2016 12:45:44 GMT
Cache-Control: max-age=600
X-GitHub-Request-Id: B91F111E:5AA6:47804:572C8F9F
Content-Length: 43752
Accept-Ranges: bytes
Date: Fri, 06 May 2016 12:35:57 GMT
Via: 1.1 varnish
Age: 13
Connection: keep-alive
X-Served-By: cache-fra1238-FRA
X-Cache: HIT
X-Cache-Hits: 1
Vary: Accept-Encoding
X-Fastly-Request-ID: 1758f53052edbfb40a0044407d53d5654ad1e983
Hopefully its just a quick one just ran my my first html validation everything worked exception it keeps telling me no content-type found. I've compared it to other html5 sites and I have no idea what's going on. I'm also getting a MIME error when I try to validate my CSS sheet. I'm pretty sure they're related/
http://validator.w3.org/check?uri=http%3A%2F%2Fnathansachs.com%2F&charset=%28detect+automatically%29&doctype=Inline&ss=1&group=0&user-agent=W3C_Validator%2F1.3+http%3A%2F%2Fvalidator.w3.org%2Fservices
As the error message says, your server is failing to include a Content-Type header in the HTTP response. This header is mandatory. It has nothing to do with the HTML document itself.
You need to fix your server or server side program that generates your content.
% curl -I http://nathansachs.com/
HTTP/1.1 200 OK
Date: Sat, 11 Jan 2014 09:24:50 GMT
Server: Apache mod_fcgid/2.3.10-dev
Last-Modified: Tue, 07 Jan 2014 20:32:26 GMT
ETag: "bec00cb-11d5-4ef674648e9f0"
Accept-Ranges: bytes
Content-Length: 4565
I'd consider upgrading Apache. You are using an older version of a development branch. That branch has stabilised and on revision 7 now! (i.e. Apache 2.4.7 is out). Use of experimental code might be the cause of your problem.
Possibly related:
Apache2 not sending “Content-Type” in header
Try to add this inside the <head /> section.
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
For HTML5:
<meta charset="UTF-8"> <!-- try without quotes as well -->
I have a website containing a link to an RDP file. When the user clicks the link, the file should be offered as a download. It works with every browser, also in IE9 on localhost. But online, IE9 does not recognize the file type and the file name, and clicking on save causes an error. Did I forget a correct header? Or are there some trusted site settings I have to change since it works on localhost?
I get the following headers when accessing the rdp file:
Date: Mon, 19 Dec 2011 12:58:50 GMT
Content-Disposition: attachment; filename="Demo_WIN.rdp"
Content-Type: application/octet-stream;charset=UTF-8
Content-Length: 72
Keep-Alive: timeout=15, max=46
Connection: Keep-Alive
username:s:Tester431
full address:s:176.1.2.3
domain:s:MYRDP
I think you need to set the content type to "application/rdp". Here are the relevant headers I use, which work on every browser I've tried, including IE9:
Content-Type: application/rdp; charset=utf-8
Content-Disposition: attachment; filename=Application.rdp