I set up cache-control and expires headers via .htaccess but already it doesn't load from browser cache. When I enter the URI, I am waiting for load from web site.
URI: http://www.btgmaslak.com/static/images/main_container_background_11.jpg
It works for me. The subsequent request is loaded from cache.
This is what you are sending down in the header:
Cache-Control: max-age=2592000
Expires: Tue, 29 Jun 2010 08:50:09 GMT
Related
I'm noticing this behavior on Varnish 6.5 where it's not making backend calls per the max-age cache control origin response, if the request is not frequently requested by clients.
Below's the expected behavior I see for a cache requested every 1 second. It has 20 seconds max-age cache-control header from origin:
Request 1:
HTTP/2 200
date: Tue, 20 Jul 2021 02:02:02 GMT
content-type: application/json
content-length: 33692
server: Apache/2.4.25 (Debian)
x-ua-compatible: IE=edge;chrome=1
pragma:
cache-control: public, max-age=20
x-varnish: 1183681 1512819
age: 17
via: 1.1 varnish (Varnish/6.5)
vary: Accept-Encoding
x-cache: HIT
accept-ranges: bytes
Request 2:
HTTP/2 200
date: Tue, 20 Jul 2021 02:02:04 GMT
content-type: application/json
content-length: 33692
server: Apache/2.4.25 (Debian)
x-ua-compatible: IE=edge;chrome=1
pragma:
cache-control: public, max-age=20
x-varnish: 891620 1512819
age: 19
via: 1.1 varnish (Varnish/6.5)
vary: Accept-Encoding
x-cache: HIT
accept-ranges: bytes
Request 3:
HTTP/2 200
date: Tue, 20 Jul 2021 02:02:05 GMT
content-type: application/json
content-length: 33692
server: Apache/2.4.25 (Debian)
x-ua-compatible: IE=edge;chrome=1
pragma:
cache-control: public, max-age=20
x-varnish: 1183687 1512819
age: 20
via: 1.1 varnish (Varnish/6.5)
vary: Accept-Encoding
x-cache: HIT
accept-ranges: bytes
Request 4:
HTTP/2 200
date: Tue, 20 Jul 2021 02:02:06 GMT
content-type: application/json
content-length: 33692
server: Apache/2.4.25 (Debian)
x-ua-compatible: IE=edge;chrome=1
pragma:
cache-control: public, max-age=20
x-varnish: 854039 1183688
age: 1
via: 1.1 varnish (Varnish/6.5)
vary: Accept-Encoding
x-cache: HIT
accept-ranges: bytes
You can see the Request #4 above makes a new origin request with the cache request id being 1183688.
Now if I wait a long while and make that same request, the cache age is pretty old and varnish does not make an origin request to cache a fresh object:
Request 5 after a while:
HTTP/2 200
date: Tue, 20 Jul 2021 02:10:08 GMT
content-type: application/json
content-length: 33692
server: Apache/2.4.25 (Debian)
x-ua-compatible: IE=edge;chrome=1
pragma:
cache-control: public, max-age=20
x-varnish: 1512998 1183688
age: 482
via: 1.1 varnish (Varnish/6.5)
vary: Accept-Encoding
x-cache: HIT
accept-ranges: bytes
I suppose I could start adding the Expires header from origin, but looking for explanation why varnish behaves this way if the request is infrequent. Thanks.
TTL header precedence in Varnish
Varnish does check the max-age directive, but there might be other factors can cause the TTL to be an unexpected value.
Here's the TTL precedence:
The Cache-Control header's s-maxage directive is checked.
When there's no s-maxage, Varnish will look for max-age to set its TTL.
When there's no Cache-Control header being returned, Varnish will use the Expires header to set its TTL.
When none of the above apply, Varnish will use the default_ttl runtime parameter as the TTL value. Its default value is 120 seconds.
Only then will Varnish enter vcl_backend_response, letting you change the TTL.
Any TTL being set in VCL using set beresp.ttl will get the upper hand, regardless of any other value being set via response headers.
Your specific situation
The best way to figure out what's going on is by running varnishlog and adding a filter for the URL you want to track.
Here's an example for the homepage:
varnishlog -g request -q "ReqUrl eq '/'"
The output will be extremely verbose, but will contain all the info you need.
Tags that are of particular interest are:
TTL see https://varnish-cache.org/docs/6.5/reference/vsl.html#varnish-shared-memory-logging
BerespHeader (specifically the Cache-Control backend response header)
RespHeader (specifically the Cache-Control response header)
Please also have a look at your VCL and check whether or not the TTL is changed by set beresp.ttl =.
What do I need to help you
In summary, if you want further assistance, please provide your full VCL, as well as a varnishlog extract for the transactions that is giving you to unexpected behavior.
Based on that information, we'll have a pretty good idea what's going on.
How can I enable GZIP compression on Azure Functions (v2) ?
I checked with postman it is not showing GZIP
POST /api/values HTTP/1.1
Host: HOSTNAMEHERE.azurewebsites.net
Content-Type: application/json
Cache-Control: no-cache
Postman-Token: e2c3967b-f562-df35-a3d1-01bd56cb4b76
It was my mistake.
GZip seems to be configured ON by default when the function is reached :)
On my case I was hitting the local functions, it does not come with Gzip:
Content-Type →application/json; charset=utf-8
Date →Mon, 19 Mar 2018 00:55:06 GMT
Server →Kestrel
Transfer-Encoding →chunked
I noticed that, when I call the correct URL on Azure, then it comes:
Content-Encoding →gzip
Content-Type →application/json; charset=utf-8
Date →Sat, 17 Mar 2018 17:29:46 GMT
Server →Kestrel
Transfer-Encoding →chunked
Vary →Accept-Encoding
X-Powered-By →ASP.NET
I'm trying to load a page from CloudFront, and the svg is showing up as a missing image.
When I look into the response headers, I see that when I load the S3 bucket directly, the response contains the proper content type: image/svg+xml
$ curl -I https://s3-eu-west-1.amazonaws.com/pages.ivizone.com/1/19/1509969889/images/kenzo-logo-v2.svg
HTTP/1.1 200 OK
x-amz-id-2: k3+bRpJLp+avBaUWO4VSgB+Djxb+nebnGJs3u6kQ0rMeX95h3XeLHA03XYaWioat+JqNG6x61x8=
x-amz-request-id: 43D8ED0E9EB4490C
Date: Mon, 06 Nov 2017 15:06:13 GMT
Last-Modified: Mon, 06 Nov 2017 14:08:00 GMT
ETag: "4b8f9e399ec9bc166040a2641cf33fb3"
Accept-Ranges: bytes
Content-Type: image/svg+xml
Content-Length: 9484
Server: AmazonS3
However when I pass through CloudFront, the header is missing:
$ curl -I https://pages.ivizone.com/1/19/1509969889/images/kenzo-logo-v2.svg
HTTP/1.1 200 OK
Content-Length: 9484
Connection: keep-alive
Date: Mon, 06 Nov 2017 14:01:01 GMT
Last-Modified: Mon, 06 Nov 2017 12:04:52 GMT
ETag: "4b8f9e399ec9bc166040a2641cf33fb3"
Server: AmazonS3
X-Cache: RefreshHit from cloudfront
Via: 1.1 ed9babcd75a95b818a6df1694ba95225.cloudfront.net (CloudFront)
X-Amz-Cf-Id: va4AIkAzw7-tNZ-qQo4KA_czM29tFQAzmNH_P0wjYd_TiboSBAyohA==
As a result, this is causing problems rendering my images.
Would anyone know why Cloudfront strips the header, and how to fix it?
Thanks!
Ok, It looks like I screwed up somewhere. When uploading the svg image to S3, I had to add the content type string to the S3 Object metadata:
"image/svg+xml"
(no spaces)
Once I added this on upload, the image was served properly.
S3 doesn't send a content-type header by default, so my browser probably interpreted the svg in an incorrect format. By specifying the header, it knew how to handle it
I use Privoxy or Proxomitron to inject custom Javascript tags into websites which then load scripts from a local python server (on localhost:8888):
... <script type="text/javascript"
src="http://localhost:8888/tweakscript.js"
></script></body>
Some of these script tags are huge third party javascript libraries which are also stored on my computer. They never change but are reloaded each time. I want to cache them.
i tried these headers, without success:
HTTP/1.1 200 OK
Content-type: text/javascript; charset=UTF-8
Vary: Accept-Encoding
Date: Sun, 04 Oct 2015 03:24:14 GMT # the current date
Last-Modified: Fri, 02 Oct 2015 06:34:40 GMT # never changes
Expires: Fri, 01 Apr 2016 03:24:14 GMT # one month in future
Cache-Control: public, max-age=15552000 # cache for one year
Access-Control-Allow-Origin: * # Content Security Policy
Access-Control-Allow-Methods: GET, POST, OPTIONS
Connection: close
(javascript code here)
How can i make the webbrowser cache these files?
OK, i found the solution:
When requesting files, the browser adds an If-Modified-Since request header, eg:
If-Modified-Since: Tue, 28 Jul 2015 22:48:42 GMT
If the server then sends as response ...
HTTP/1.1 304 Not Modified
... then the browser will load the file from cache.
I'm serving static files (images, javascript, css files) from a (hopefully) cookieless domain also mapped to my cloudcontrol deployment. Here are the request and reponse headers. I see no cookie header in the request, ETag and date check should satisfy, so I would expect that the varnish proxy in front of the cloudcontrol deployment would fetch the request and serve it, but everytime I try it out all static files are served from the Apache processes according to the response header. Any tipps appreciated.
Request URL:http://static.hotelpress.mobi/bundles/viermediamagazine/icons/social/Facebook_64.png
Request Method:GET
Status Code:304 Not Modified
Request Headers
Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cache-Control:max-age=0
Connection:keep-alive
Host:static.hotelpress.mobi
If-Modified-Since:Sat, 20 Apr 2013 18:23:31 GMT
If-None-Match:"6008d436-1108-4daceeec74ec0"
Referer:---stripped out or my boss kills me---
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.65 Safari/537.31
Response Headers
Accept-Ranges:bytes
Age:0
Connection:keep-alive
Date:Sat, 20 Apr 2013 18:31:33 GMT
ETag:"6008d436-1108-4daceeec74ec0"
Last-Modified:Sat, 20 Apr 2013 18:23:31 GMT
Server:Apache
Via:1.1 varnish
X-Varnish:995972028
X-varnish-cache:MISS
Assuming that Varnish is passing through all your Apache headers, it appears that you are not setting any headers telling Varnish to cache.
Varnish does cache silently for 2 minutes by default with no headers, but you probably want more than that.
You should also remove the Etag, for the reasons you say. More information on Etags is here.
If you have fingerprinted assets (per deploy/change), you should set those in Apache for 1 year.
Any others can be as long as you can stand (remembering that this may stop you frequently updating those assets, because they may be cached somewhere).
Here are the lines you need in apache:
<LocationMatch "^/path/to/fingerprinted/assets/.*$">
Header unset ETag
FileETag None
# RFC says only cache for 1 year
ExpiresActive On
ExpiresDefault "access plus 1 year"
Header append Cache-Control "public"
</LocationMatch>
and for others:
<LocationMatch "^/bundles/viermediamagazine/icons/.*$">
Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault "access plus 1 week"
Header append Cache-Control "public"
</LocationMatch>
You can use as many locations as you want - just make sure they do not overlap!
The example request you posted contains
Cache-Control:max-age=0
which prevents cached answers iirc. You could also try if setting a Cache-Control: max-age=<x> header in your response helps.
Extending the other answers: Here's a sample request to an app on cloudControl, that caches (when the ?c=1). In any case send requests multiple times until you get hits consistently to make sure all Varnish instances have cached the response.
$ curl -v http://impresstw.cloudcontrolled.com/?c=1
* About to connect() to impresstw.cloudcontrolled.com port 80 (#0)
* Trying 46.137.184.215...
* connected
* Connected to impresstw.cloudcontrolled.com (46.137.184.215) port 80 (#0)
> GET /?c=1 HTTP/1.1
> User-Agent: curl/7.27.0
> Host: impresstw.cloudcontrolled.com
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=UTF-8
< Server: TornadoServer/2.4.1
< Cache-Control: max-age=36000, must-revalidate
< Expires: Tue, 23 Apr 2013 20:18:12 GMT
< Content-Length: 13
< Accept-Ranges: bytes
< Date: Tue, 23 Apr 2013 10:18:28 GMT
< X-Varnish: 1434600184 1434599691
< Age: 16
< Via: 1.1 varnish
< Connection: keep-alive
< X-varnish-cache: HIT
<