CloudFront ignores my cache header and my pictures have to be picked up from the server again after a while.
~$ curl -I http://d2573vy43ojbo7.cloudfront.net/attachments/store/limit/64/3720c5574063aebc90511061b99de858740ad764c6981d2bf30ff121ada0/image.jpg
HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 1645
Connection: keep-alive
Server: nginx/1.4.1
Date: Thu, 12 Feb 2015 14:37:41 GMT
Status: 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Headers:
Access-Control-Allow-Method:
Cache-Control: public, must-revalidate, max-age=31536000
Expires: Fri, 12 Feb 2016 14:37:41 GMT
Content-Disposition: inline; filename="image.jpg"
Last-Modified: Thu, 12 Feb 2015 14:37:41 GMT
X-Content-Type-Options: nosniff
X-Request-Id: 239b0fda-cae9-452f-9d1b-ccbf035bbf69
X-Runtime: 3.457939
X-Cache: Miss from cloudfront
Via: 1.1 6cde3c778df412041adc7610331b57bc.cloudfront.net (CloudFront)
X-Amz-Cf-Id: yicAkZYc5XpowKRFMOXDKSJKBMWZ4kq2B3vLK8Q-Py124D8lQq_1lg==
I tried to get the same file yesterday and then it was the same, after the second time i tried it was reached and served by CloudFront but not anymore. It's the same for all my images. They are cached but are removed from the cache after a couple of hours.
What's wrong? My cache behavior settings on CloudFront is set to default and it uses Origin Cache Headers.
Take a look here: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
If an object in an edge location isn't frequently requested, CloudFront might evict the object—remove the object before its expiration date—to make room for objects that are more popular.
It means that object is not popular enough to stay in cache for a longer time. If you have enough viewers hitting this object AND this particular CloudFront location, it would have stayed in cache longer
Related
I have a resource that is served with the following headers:
Cache-Control: private, max-age=0
Connection: keep-alive
Content-Encoding: gzip
Content-Type: application/javascript;charset=utf-8
Date: Wed, 05 May 2021 12:22:58 GMT
etag: "1609459200000-gzip"
expires: Wed, 05 May 2021 12:22:58 GMT
last-modified: Fri, 01 Jan 2021 00:00:00 GMT
Vary: Accept-Encoding
Yesterday we updated this resource and we noted that about 10% of the traffic is, 24h later, still using the stale resource. In those cases, the browser uses the old cached resource without hitting the server (to revalidate or get a fresh version).
Why some browsers don't honor max-age and don't revalidate (or get a fresh version) of this resource?
Is it mandatory to use, in this case, no-cache to force a revalidation?
If I want to use the cached resource and revalidate only after 10 seconds, will this be enough for any modern browser?
Cache-Control: private, must-revalidate, max-age=10
Bit of an odd one.
I noticed some query string stopped working on page load for a page on my website. Upon checking the network console of chrome and firefox, I can see that the page is returning a 403 forbidden error. This is odd, since the page seems to be loading correctly (except for query string not applying on page load).
It's the only page on the site that seems to be doing it.
Response Headers:
cache-control: no-cache, must-revalidate, max-age=0
cf-cache-status: MISS
cf-ray: 463904819f55a71f-DUB
content-encoding: br
content-type: text/html; charset=UTF-8
date: Tue, 02 Oct 2018 17:51:33 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
expires: Wed, 11 Jan 1984 05:00:00 GMT
link: <https://ygoprodeck.com/wp-json/>; rel="https://api.w.org/", <https://ygoprodeck.com/?p=7620>; rel=shortlink
pragma: no-cache
server: cloudflare
status: 403
vary: Accept-Encoding,Cookie,User-Agent
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-ua-compatible: IE=edge,chrome=1
x-xss-protection: 1; mode=block
I'm not sure how it can both get a 403 and load properly at the same time, very odd.
The page in question: https://ygoprodeck.com/deck-search/
Found the issue.
On the root of my site, I had a folder called "deck-search". No idea how it got there but it was causing issues. Removing it fixed it.
I want to install & configure my WordPress site in /journal like:
https://example.com/journal/
After my installation, when I try to access /wp-admin, they say cookie settings haven't been configured within my browser and I fail to log in. When I hit curl:
$ curl -I localhost/journal/wp-login.php
HTTP/1.1 200 OK
Date: Tue, 13 Feb 2018 12:02:28 GMT
Server: Apache/2.4.6 (Amazon Linux 2) PHP/7.2.0
X-Powered-By: PHP/7.2.0
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Set-Cookie: wordpress_test_cookie=WP+Cookie+check; path=/journal/journal/; secure
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=UTF-8
I suppose the cookie path being /journal/journal/ is the reason I can't log in properly. What kind of additional configuration is needed to set my cookies properly?
I have the newest wp e-coomerce plugin (Version 3.8.12.1) on my wordpress Version 3.6.1 installed
I'm just trying to change username (email address) in paypal standard settings of the store and it simply doesn't work - the address is not being updated neither with Update button for the option nor with Save changes button below all options.
Is it a bug? Or I'm doing something wrong?
I did check with Live HTTP headers and I can see the new values are captures correctly but then passed to the address which gives 302 error:
HTTP/1.0 302 Moved Temporarily
Date: Mon, 23 Sep 2013 08:04:17 GMT
Server: Apache
X-Powered-By: PHP/5.2.17
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Location: /wp-admin/options-general.php?page=wpsc-settings&tab=gateway&settings-updated=1
Content-Length: 0
Content-Type: text/html
X-Cache: MISS from proxy1
X-Cache-Lookup: MISS from proxy1:3128
Connection: keep-alive
But then on tabs which are saved correctly I get the same headers for /wp-admin/options-general.php as above so looks like this is not where the issue lies?
I have some static content going through a CDN. I am using IIS6's built in compression (gzip & deflate) for static content and this is working fine when I request it. However, when the CDN makes the initial request for the content, it is not being returned compressed. They therefore don't have compressed content to forward to people requesting it. (Yes this raises the issue of people requesting [the zipped] content from the CDN with a browser that can't handle the compression. - We'll put that to one side for now though)
Here's an example of requesting without the 'Via' header:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
accept-encoding: gzip
And it returns a compressed response:
HTTP/1.1 200 OK
Content-Length: 4357
Content-Type: application/x-javascript
Content-Encoding: gzip
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:52 GMT
Accept-Ranges: bytes
Vary: Accept-Encoding
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:27:50 GMT
However, if I include a 'Via' header in the request (as the CDN does) then the result comes back uncompressed:
Request:
HEAD /flash/swfobject.js HTTP/1.1
User-Agent: curl/7.19.7 (i386-pc-win32)
Host: localhost:9120
Accept: */*
Connection: Keep-Alive
Via: 1.1 204.160.105.17:80 (Footprint 4.5/FPMCP)
accept-encoding: gzip
Response:
HTTP/1.1 200 OK
Content-Length: 14602
Content-Type: application/x-javascript
Expires: Wed, 01 Jan 2020 00:00:00 GMT
Last-Modified: Wed, 18 Nov 2009 15:36:54 GMT
Accept-Ranges: bytes
Server: Microsoft-IIS/6.0
Date: Thu, 19 Nov 2009 10:29:52 GMT
Yes these demos use 'localhost' in the request. I get the same result using the actual domain name from various machines on various networks though.
Two questions then:
Could this be IIS not applying the compression due to the extra header? and if so what can I do about it?
How can I tell if the proxy is decompressing the content before returning it?
Bonus question 3 - What can I do to investigate this problem further?
I am aware of question 332049, but that has the header in the response, not the request.
I stumbled across your question while researching this myself. I uncovered an article on MSDN and the short answer is that the Via header is used for proxies and proxies typically mess up compression. You either have the option of removing the header or you can change the setting in the IIS metabase (HcNoCompressionForProxies="FALSE"). I had success with both options.