ASP.NET MVC Page with ResponseCache on action DOES return new content instead of cache












0















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?










share|improve this question





























    0















    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?










    share|improve this question



























      0












      0








      0








      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?










      share|improve this question
















      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






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 26 '18 at 10:55







      Michel

















      asked Nov 26 '18 at 7:39









      MichelMichel

      10.5k39126202




      10.5k39126202
























          1 Answer
          1






          active

          oldest

          votes


















          1














          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.






          share|improve this answer
























          • 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











          • 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











          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
          });


          }
          });














          draft saved

          draft discarded


















          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









          1














          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.






          share|improve this answer
























          • 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











          • 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
















          1














          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.






          share|improve this answer
























          • 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











          • 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














          1












          1








          1







          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.






          share|improve this answer













          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.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          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 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











          • 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 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











          • 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 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




















          draft saved

          draft discarded




















































          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.




          draft saved


          draft discarded














          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





















































          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







          Popular posts from this blog

          Create new schema in PostgreSQL using DBeaver

          Deepest pit of an array with Javascript: test on Codility

          Costa Masnaga