I have nextjs app. If I add getServerSideProps export to the page (this means that page will be server side rendered, read more) nextjs adds cache-control header:
cache-control: private, no-cache, no-store, max-age=0, must-revalidate
But according to this documentation these are conflicting headers and in theory it should be the same as no-store header. Citing the acticle:
# conflicted
Cache-Control: private, no-cache, no-store, max-age=0, must-revalidate
# equivalent to
Cache-Control: no-store
Is there any reason these multiple headers are used instead of simply using no-store?
Related
My application is build using EmberJs and is served on Nginx. I am able to set Cache-Control header in response using add_header in nginx.conf
location ~* \.(css|eot|gif|jpe?g|js|png|svg|ttf|woff2?)$ {
expires max;
add_header Pragma public;
add_header Cache-Control "public, must-revalidate, proxy-revalidate";
}
But this alone doesn't work as request header is set to no-cache. So, browser always goes to backend and doesn't use its cache ever.
Response Headers
cache-control: max-age=315360000
cache-control: public, must-revalidate, proxy-revalidate
expires: Thu, 31 Dec 2037 23:55:55 GMT
pragma: public
Request Headers
Cache-Control: no-cache
Pragma: no-cache
I understand that Cahce-Control in request is causing the problem. But I am not able to find how to set this header with some other value. Does ember build or nginx conf support this?
This is the index.html generated by ember which has links for vendor js and css which are supposed to be reused using cache by browser.
I am trying to understand the difference between these two cache headers.
In the first header, I have max-age twice - one with value 0 and another with value 600
Cache-Control →no-cache, no-store, max-age=0, must-revalidate, max-age=600
Cache-Control →max-age=600
Can some help me with technically if both are same?
I want to make sure that some of my responses will not be cached by anyone.
One of the advised options is to set Vary: *.
Unfortunately my nginx which has enabled gzip support returns me two Vary headers if i add add_header "Vary" "*";
HTTP/1.1 200 OK
Server: nginx/1.11.1
Date: Mon, 16 Jan 2017 14:56:16 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Vary: *
Any idea how to force having only Vary: * in responses and gzip support for the request on?
gzip_vary off;
should stop gzip from auto-adding Vary header.
docs: http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip_vary
I read about Pragma header on Wikipedia which says:
"The Pragma: no-cache header field is an HTTP/1.0 header intended for
use in requests. It is a means for the browser to tell the server and
any intermediate caches that it wants a fresh version of the resource,
not for the server to tell the browser not to cache the resource. Some
user agents do pay attention to this header in responses, but the
HTTP/1.1 RFC specifically warns against relying on this behavior."
But I haven't understood what it does? What is the difference between the Cache-Control header whose value is no-cache and Pragma whose value is also no-cache?
Pragma is the HTTP/1.0 implementation and cache-control is the HTTP/1.1 implementation of the same concept. They both are meant to prevent the client from caching the response. Older clients may not support HTTP/1.1 which is why that header is still in use.
There is no difference, except that Pragma is only defined as applicable to the requests by the client, whereas Cache-Control may be used by both the requests of the clients and the replies of the servers.
So, as far as standards go, they can only be compared from the perspective of the client making a requests and the server receiving a request from the client. The http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.32 defines the scenario as follows:
HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
sent "Cache-Control: no-cache". No new Pragma directives will be
defined in HTTP.
Note: because the meaning of "Pragma: no-cache as a response
header field is not actually specified, it does not provide a
reliable replacement for "Cache-Control: no-cache" in a response
The way I would read the above:
if you're writing a client and need no-cache:
just use Pragma: no-cache in your requests, since you may not know if Cache-Control is supported by the server;
but in replies, to decide on whether to cache, check for Cache-Control
if you're writing a server:
in parsing requests from the clients, check for Cache-Control; if not found, check for Pragma: no-cache, and execute the Cache-Control: no-cache logic;
in replies, provide Cache-Control.
Of course, reality might be different from what's written or implied in the RFC!
Stop using (HTTP 1.0)
Replaced with (HTTP 1.1 since 1999)
Expires: [date]
Cache-Control: max-age=[seconds]
Pragma: no-cache
Cache-Control: no-cache
If it's after 1999, and you're still using Expires or Pragma, you're doing it wrong.
I'm looking at you Stackoverflow:
200 OK
Pragma: no-cache
Content-Type: application/json
X-Frame-Options: SAMEORIGIN
X-Request-Guid: a3433194-4a03-4206-91ea-6a40f9bfd824
Strict-Transport-Security: max-age=15552000
Content-Length: 54
Accept-Ranges: bytes
Date: Tue, 03 Apr 2018 19:03:12 GMT
Via: 1.1 varnish
Connection: keep-alive
X-Served-By: cache-yyz8333-YYZ
X-Cache: MISS
X-Cache-Hits: 0
X-Timer: S1522782193.766958,VS0,VE30
Vary: Fastly-SSL
X-DNS-Prefetch-Control: off
Cache-Control: private
tl;dr: Pragma is a legacy of HTTP/1.0 and hasn't been needed since Internet Explorer 5, or Netscape 4.7. Unless you expect some of your users to be using IE5: it's safe to stop using it.
Expires: [date] (deprecated - HTTP 1.0)
Pragma: no-cache (deprecated - HTTP 1.0)
Cache-Control: max-age=[seconds]
Cache-Control: no-cache (must re-validate the cached copy every time)
And the conditional requests:
Etag (entity tag) based conditional requests
Server: Etag: W/“1d2e7–1648e509289”
Client: If-None-Match: W/“1d2e7–1648e509289”
Server: 304 Not Modified
Modified date based conditional requests
Server: last-modified: Thu, 09 May 2019 19:15:47 GMT
Client: If-Modified-Since: Fri, 13 Jul 2018 10:49:23 GMT
Server: 304 Not Modified
last-modified: Thu, 09 May 2019 19:15:47 GMT
Although I have set Expires to a date in the past, and Cache-Control to no-store, no-cache, I still get one of my web pages cached.
Here are the HTTP headers sent to the browser:
Date: Tue, 02 Nov 2010 09:13:23 GMT
Server: Apache/2.2.15 (el)
X-Powered-By: PHP/5.2.13
Set-Cookie: PHPSESSID=2luvb7b316lfc8ht570s1l1v84; path=/
Set-Cookie: Newsletter_Counter=17; expires=Wed, 02-Nov-2011 09:13:23 GMT; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Connection: close
Content-Type: text/html; charset=UTF-8
Same behavior for FF 3.6, Safari and IE 8.
How do I get browsers to stop caching the page?
Browsers decide caching themselves. You can use a random GET parameter to force browsers not to cache, e.g.
http://www.foo.com/yourfile.zip?id=1234
The following headers have always worked well for me (for HTTP/1.1). You should not need Pragma: no-cache.
Cache-Control: no-cache
Expires: <some date in the past>
Vary: *
Try changing your Vary value to the asterisk from my example.
Per http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44:
"A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation."
Using Cache-Control: no-store should forbid any storage:
no-store
[…] If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. […]
You certainly seem to be doing the right things (but like a lot of people seem to assume that sending a 'Pragma: no-cache' response header has some effect on browser side caching - it should not).
What do you mean its getting cached? It will not (usually) be fetched again from the server if the user clicks on the 'back button' and was retrieved using a GET operation.