ASP.NET MVC Page with ResponseCache on action DOES return new content instead of cache
I followed this tutorial (https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-2.1) to implement ResponseCache on my controller-action.
In short, I added
services.AddResponseCaching();
and app.UseResponseCaching();
in the startup and this tag [ResponseCache( Duration = 30)]
on my controller.
Then I added a <h2>@DateTime.Now</h2>
in my view and what I expected.... was the same datetime.now for 30 seconds.
But it doesn't, it just shows the new time on every reload (F5).
I made sure my devtools in chrome do not say 'disable cache'.
It's both with and without the chrome devtools open, on my local machine, now trying on a brandnew .net core mvc project.
One thing I noticed (with devtools open) is that the request has this header: Cache-Control: max-age=0
. Does this influence the behaviour?
I thought it would mean something because it looks like the request says 'no cache' but that strikes me as weird because I didn't put the header in and I would say the default behaviour of chrome wouldn't be to ignore caches?
caching asp.net-core-mvc
add a comment |
I followed this tutorial (https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-2.1) to implement ResponseCache on my controller-action.
In short, I added
services.AddResponseCaching();
and app.UseResponseCaching();
in the startup and this tag [ResponseCache( Duration = 30)]
on my controller.
Then I added a <h2>@DateTime.Now</h2>
in my view and what I expected.... was the same datetime.now for 30 seconds.
But it doesn't, it just shows the new time on every reload (F5).
I made sure my devtools in chrome do not say 'disable cache'.
It's both with and without the chrome devtools open, on my local machine, now trying on a brandnew .net core mvc project.
One thing I noticed (with devtools open) is that the request has this header: Cache-Control: max-age=0
. Does this influence the behaviour?
I thought it would mean something because it looks like the request says 'no cache' but that strikes me as weird because I didn't put the header in and I would say the default behaviour of chrome wouldn't be to ignore caches?
caching asp.net-core-mvc
add a comment |
I followed this tutorial (https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-2.1) to implement ResponseCache on my controller-action.
In short, I added
services.AddResponseCaching();
and app.UseResponseCaching();
in the startup and this tag [ResponseCache( Duration = 30)]
on my controller.
Then I added a <h2>@DateTime.Now</h2>
in my view and what I expected.... was the same datetime.now for 30 seconds.
But it doesn't, it just shows the new time on every reload (F5).
I made sure my devtools in chrome do not say 'disable cache'.
It's both with and without the chrome devtools open, on my local machine, now trying on a brandnew .net core mvc project.
One thing I noticed (with devtools open) is that the request has this header: Cache-Control: max-age=0
. Does this influence the behaviour?
I thought it would mean something because it looks like the request says 'no cache' but that strikes me as weird because I didn't put the header in and I would say the default behaviour of chrome wouldn't be to ignore caches?
caching asp.net-core-mvc
I followed this tutorial (https://docs.microsoft.com/en-us/aspnet/core/performance/caching/response?view=aspnetcore-2.1) to implement ResponseCache on my controller-action.
In short, I added
services.AddResponseCaching();
and app.UseResponseCaching();
in the startup and this tag [ResponseCache( Duration = 30)]
on my controller.
Then I added a <h2>@DateTime.Now</h2>
in my view and what I expected.... was the same datetime.now for 30 seconds.
But it doesn't, it just shows the new time on every reload (F5).
I made sure my devtools in chrome do not say 'disable cache'.
It's both with and without the chrome devtools open, on my local machine, now trying on a brandnew .net core mvc project.
One thing I noticed (with devtools open) is that the request has this header: Cache-Control: max-age=0
. Does this influence the behaviour?
I thought it would mean something because it looks like the request says 'no cache' but that strikes me as weird because I didn't put the header in and I would say the default behaviour of chrome wouldn't be to ignore caches?
caching asp.net-core-mvc
caching asp.net-core-mvc
edited Nov 26 '18 at 10:55
Michel
asked Nov 26 '18 at 7:39
MichelMichel
10.5k39126202
10.5k39126202
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
A header like Cache-Control: max-age=0
effectively disables all caching. Resources are basically expired as soon as they come off the wire, so they are always fetched. This header originates from the server. The client has nothing to do with it.
Assuming you haven't disabled response caching manually in some way by accident. Then, the most likeliest situation is that you're doing something where the response caching middleware will never cache. The documentation lists the following conditions that must be satisfied before responses will be cached, regardless of what you do:
- The request must result in a server response with a 200 (OK) status code.
- The request method must be GET or HEAD.
- Terminal middleware, such as Static File Middleware, must not process the response prior to the Response Caching Middleware.
- The Authorization header must not be present.
- Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
- The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
- The Set-Cookie header must not be present.
- Vary header parameters must be valid and not equal to *.
- The Content-Length header value (if set) must match the size of the response body.
- The IHttpSendFileFeature isn't used.
- The response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
- Response buffering must be successful, and the size of the response must be smaller than the configured or default SizeLimit.
- The response must be cacheable according to the RFC 7234 specifications. For example, the no-store directive must not exist in request or response header fields. See Section 3: Storing Responses in Caches of RFC 7234 for details.
However, in such situations, the server should be sending Cache-Control: no-cache
, not max-age=0
. As a result, I'm leaning towards some misconfiguration somewhere, where you have set this max age value and either forgot or overlooked it.
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the headerCache-Control: public,max-age=100
. So something must have changed, but I don't know what.
– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. TheCache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.
– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53476579%2fasp-net-mvc-page-with-responsecache-on-action-does-return-new-content-instead-of%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
A header like Cache-Control: max-age=0
effectively disables all caching. Resources are basically expired as soon as they come off the wire, so they are always fetched. This header originates from the server. The client has nothing to do with it.
Assuming you haven't disabled response caching manually in some way by accident. Then, the most likeliest situation is that you're doing something where the response caching middleware will never cache. The documentation lists the following conditions that must be satisfied before responses will be cached, regardless of what you do:
- The request must result in a server response with a 200 (OK) status code.
- The request method must be GET or HEAD.
- Terminal middleware, such as Static File Middleware, must not process the response prior to the Response Caching Middleware.
- The Authorization header must not be present.
- Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
- The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
- The Set-Cookie header must not be present.
- Vary header parameters must be valid and not equal to *.
- The Content-Length header value (if set) must match the size of the response body.
- The IHttpSendFileFeature isn't used.
- The response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
- Response buffering must be successful, and the size of the response must be smaller than the configured or default SizeLimit.
- The response must be cacheable according to the RFC 7234 specifications. For example, the no-store directive must not exist in request or response header fields. See Section 3: Storing Responses in Caches of RFC 7234 for details.
However, in such situations, the server should be sending Cache-Control: no-cache
, not max-age=0
. As a result, I'm leaning towards some misconfiguration somewhere, where you have set this max age value and either forgot or overlooked it.
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the headerCache-Control: public,max-age=100
. So something must have changed, but I don't know what.
– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. TheCache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.
– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
add a comment |
A header like Cache-Control: max-age=0
effectively disables all caching. Resources are basically expired as soon as they come off the wire, so they are always fetched. This header originates from the server. The client has nothing to do with it.
Assuming you haven't disabled response caching manually in some way by accident. Then, the most likeliest situation is that you're doing something where the response caching middleware will never cache. The documentation lists the following conditions that must be satisfied before responses will be cached, regardless of what you do:
- The request must result in a server response with a 200 (OK) status code.
- The request method must be GET or HEAD.
- Terminal middleware, such as Static File Middleware, must not process the response prior to the Response Caching Middleware.
- The Authorization header must not be present.
- Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
- The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
- The Set-Cookie header must not be present.
- Vary header parameters must be valid and not equal to *.
- The Content-Length header value (if set) must match the size of the response body.
- The IHttpSendFileFeature isn't used.
- The response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
- Response buffering must be successful, and the size of the response must be smaller than the configured or default SizeLimit.
- The response must be cacheable according to the RFC 7234 specifications. For example, the no-store directive must not exist in request or response header fields. See Section 3: Storing Responses in Caches of RFC 7234 for details.
However, in such situations, the server should be sending Cache-Control: no-cache
, not max-age=0
. As a result, I'm leaning towards some misconfiguration somewhere, where you have set this max age value and either forgot or overlooked it.
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the headerCache-Control: public,max-age=100
. So something must have changed, but I don't know what.
– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. TheCache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.
– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
add a comment |
A header like Cache-Control: max-age=0
effectively disables all caching. Resources are basically expired as soon as they come off the wire, so they are always fetched. This header originates from the server. The client has nothing to do with it.
Assuming you haven't disabled response caching manually in some way by accident. Then, the most likeliest situation is that you're doing something where the response caching middleware will never cache. The documentation lists the following conditions that must be satisfied before responses will be cached, regardless of what you do:
- The request must result in a server response with a 200 (OK) status code.
- The request method must be GET or HEAD.
- Terminal middleware, such as Static File Middleware, must not process the response prior to the Response Caching Middleware.
- The Authorization header must not be present.
- Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
- The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
- The Set-Cookie header must not be present.
- Vary header parameters must be valid and not equal to *.
- The Content-Length header value (if set) must match the size of the response body.
- The IHttpSendFileFeature isn't used.
- The response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
- Response buffering must be successful, and the size of the response must be smaller than the configured or default SizeLimit.
- The response must be cacheable according to the RFC 7234 specifications. For example, the no-store directive must not exist in request or response header fields. See Section 3: Storing Responses in Caches of RFC 7234 for details.
However, in such situations, the server should be sending Cache-Control: no-cache
, not max-age=0
. As a result, I'm leaning towards some misconfiguration somewhere, where you have set this max age value and either forgot or overlooked it.
A header like Cache-Control: max-age=0
effectively disables all caching. Resources are basically expired as soon as they come off the wire, so they are always fetched. This header originates from the server. The client has nothing to do with it.
Assuming you haven't disabled response caching manually in some way by accident. Then, the most likeliest situation is that you're doing something where the response caching middleware will never cache. The documentation lists the following conditions that must be satisfied before responses will be cached, regardless of what you do:
- The request must result in a server response with a 200 (OK) status code.
- The request method must be GET or HEAD.
- Terminal middleware, such as Static File Middleware, must not process the response prior to the Response Caching Middleware.
- The Authorization header must not be present.
- Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
- The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
- The Set-Cookie header must not be present.
- Vary header parameters must be valid and not equal to *.
- The Content-Length header value (if set) must match the size of the response body.
- The IHttpSendFileFeature isn't used.
- The response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
- Response buffering must be successful, and the size of the response must be smaller than the configured or default SizeLimit.
- The response must be cacheable according to the RFC 7234 specifications. For example, the no-store directive must not exist in request or response header fields. See Section 3: Storing Responses in Caches of RFC 7234 for details.
However, in such situations, the server should be sending Cache-Control: no-cache
, not max-age=0
. As a result, I'm leaning towards some misconfiguration somewhere, where you have set this max age value and either forgot or overlooked it.
answered Nov 26 '18 at 20:41
Chris PrattChris Pratt
159k21241309
159k21241309
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the headerCache-Control: public,max-age=100
. So something must have changed, but I don't know what.
– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. TheCache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.
– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
add a comment |
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the headerCache-Control: public,max-age=100
. So something must have changed, but I don't know what.
– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. TheCache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.
– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the header
Cache-Control: public,max-age=100
. So something must have changed, but I don't know what.– Michel
Nov 27 '18 at 12:20
Thanks for your reply. My first reaction was that I didn't do anything special because I isolated the problem in a new basic asp.net mvc core project. Yesterday I 'used' the index action, now I retried with a new action method, and for some reason I do not understand, it now sends the header
Cache-Control: public,max-age=100
. So something must have changed, but I don't know what.– Michel
Nov 27 '18 at 12:20
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
I also noticed that when I navigate via the menu, the browser respects the caching (the time stays the same and the result in the devtools says 'from disk cache') but when I hit F5 the browser decides to reload the page.
– Michel
Nov 27 '18 at 12:21
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. The
Cache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.– Chris Pratt
Nov 27 '18 at 13:58
It's hard to say exactly without being able to see your codebase. However, it is important to realize that caching client-side is entirely up to the client. The
Cache-Control
header merely allows the server to make recommendations about what resources can be cached and how. The client is free to totally disregard it. As such, cache behavior will be largely dependent on the client (i.e. web browser) and different web browsers may choose to handle it differently, i.e. one may decide to handle F5 by requesting everything new from the server.– Chris Pratt
Nov 27 '18 at 13:58
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
Thanks very much for the explanation.
– Michel
Nov 28 '18 at 12:16
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53476579%2fasp-net-mvc-page-with-responsecache-on-action-does-return-new-content-instead-of%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown