ASP.Net Core 2.0 - ResponseCaching Middleware - Not Caching on Server
I want to use server-side response caching (output cache) with asp.net core 2.0 and found out about Response Caching Middleware and wanted to give it a try with a brand new asp.core mvc project.
Here is the description from the link above which makes me think this could be used like output cache.
The middleware determines when responses are cacheable, stores responses, and serves responses from cache.
Here is how my startup.cs looks like.
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddMvc();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCaching();
if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
}
and here is the HomeController.cs
[ResponseCache(Duration = 60)]
public class HomeController : Controller
{
public IActionResult Index()
{
return View();
}
public IActionResult About()
{
ViewData["Message"] = "Your application description page.";
return View();
}
public IActionResult Contact()
{
ViewData["Message"] = "Your contact page.";
return View();
}
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
there is also a timestamp at the bottom of _Layout.cshtml file so i can tell when the page is rendered, like below.
<p>© 2018 - ResponseCachingMiddleware - @DateTime.UtcNow</p>
Cache-Control headers seem to be fine, this is what I get in headers when I load the page but time stamp keeps getting updated on every refresh every second.
Cache-Control:public,max-age=60
What I'm understanding from MS documentations is Response Caching Middleware is the server-side caching mechanism that takes care of caching the response while Response Caching seems to be just a filter to manipulate response headers for caching.
Can't tell if there is something wrong with my understanding or code and I wanna complain that I'm feeling this way too often since I started prototyping with ASP.Net Core. Maybe you could also suggest better resources as a side topic.
I've checked out this post before
ASP.NET Core 2.0 - Http Response Caching Middleware - Nothing cached
Also checked this out but it seems like the only difference is I'm using mvc.
https://github.com/aspnet/ResponseCaching/blob/dev/samples/ResponseCachingSample/Startup.cs
Thanks
Edit: I'm seeing the message below in the output window, cannot find anything about it on google except the few places I already checked for response caching middleware.
Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware:Information:
The response could not be cached for this request.
Note: I wish I could create #response-caching-middleware tag. Not sure #responsecache is relevant.
asp.net caching asp.net-core-2.0 outputcache responsecache
add a comment |
I want to use server-side response caching (output cache) with asp.net core 2.0 and found out about Response Caching Middleware and wanted to give it a try with a brand new asp.core mvc project.
Here is the description from the link above which makes me think this could be used like output cache.
The middleware determines when responses are cacheable, stores responses, and serves responses from cache.
Here is how my startup.cs looks like.
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddMvc();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCaching();
if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
}
and here is the HomeController.cs
[ResponseCache(Duration = 60)]
public class HomeController : Controller
{
public IActionResult Index()
{
return View();
}
public IActionResult About()
{
ViewData["Message"] = "Your application description page.";
return View();
}
public IActionResult Contact()
{
ViewData["Message"] = "Your contact page.";
return View();
}
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
there is also a timestamp at the bottom of _Layout.cshtml file so i can tell when the page is rendered, like below.
<p>© 2018 - ResponseCachingMiddleware - @DateTime.UtcNow</p>
Cache-Control headers seem to be fine, this is what I get in headers when I load the page but time stamp keeps getting updated on every refresh every second.
Cache-Control:public,max-age=60
What I'm understanding from MS documentations is Response Caching Middleware is the server-side caching mechanism that takes care of caching the response while Response Caching seems to be just a filter to manipulate response headers for caching.
Can't tell if there is something wrong with my understanding or code and I wanna complain that I'm feeling this way too often since I started prototyping with ASP.Net Core. Maybe you could also suggest better resources as a side topic.
I've checked out this post before
ASP.NET Core 2.0 - Http Response Caching Middleware - Nothing cached
Also checked this out but it seems like the only difference is I'm using mvc.
https://github.com/aspnet/ResponseCaching/blob/dev/samples/ResponseCachingSample/Startup.cs
Thanks
Edit: I'm seeing the message below in the output window, cannot find anything about it on google except the few places I already checked for response caching middleware.
Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware:Information:
The response could not be cached for this request.
Note: I wish I could create #response-caching-middleware tag. Not sure #responsecache is relevant.
asp.net caching asp.net-core-2.0 outputcache responsecache
add a comment |
I want to use server-side response caching (output cache) with asp.net core 2.0 and found out about Response Caching Middleware and wanted to give it a try with a brand new asp.core mvc project.
Here is the description from the link above which makes me think this could be used like output cache.
The middleware determines when responses are cacheable, stores responses, and serves responses from cache.
Here is how my startup.cs looks like.
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddMvc();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCaching();
if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
}
and here is the HomeController.cs
[ResponseCache(Duration = 60)]
public class HomeController : Controller
{
public IActionResult Index()
{
return View();
}
public IActionResult About()
{
ViewData["Message"] = "Your application description page.";
return View();
}
public IActionResult Contact()
{
ViewData["Message"] = "Your contact page.";
return View();
}
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
there is also a timestamp at the bottom of _Layout.cshtml file so i can tell when the page is rendered, like below.
<p>© 2018 - ResponseCachingMiddleware - @DateTime.UtcNow</p>
Cache-Control headers seem to be fine, this is what I get in headers when I load the page but time stamp keeps getting updated on every refresh every second.
Cache-Control:public,max-age=60
What I'm understanding from MS documentations is Response Caching Middleware is the server-side caching mechanism that takes care of caching the response while Response Caching seems to be just a filter to manipulate response headers for caching.
Can't tell if there is something wrong with my understanding or code and I wanna complain that I'm feeling this way too often since I started prototyping with ASP.Net Core. Maybe you could also suggest better resources as a side topic.
I've checked out this post before
ASP.NET Core 2.0 - Http Response Caching Middleware - Nothing cached
Also checked this out but it seems like the only difference is I'm using mvc.
https://github.com/aspnet/ResponseCaching/blob/dev/samples/ResponseCachingSample/Startup.cs
Thanks
Edit: I'm seeing the message below in the output window, cannot find anything about it on google except the few places I already checked for response caching middleware.
Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware:Information:
The response could not be cached for this request.
Note: I wish I could create #response-caching-middleware tag. Not sure #responsecache is relevant.
asp.net caching asp.net-core-2.0 outputcache responsecache
I want to use server-side response caching (output cache) with asp.net core 2.0 and found out about Response Caching Middleware and wanted to give it a try with a brand new asp.core mvc project.
Here is the description from the link above which makes me think this could be used like output cache.
The middleware determines when responses are cacheable, stores responses, and serves responses from cache.
Here is how my startup.cs looks like.
public class Startup
{
public Startup(IConfiguration configuration)
{
Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.AddResponseCaching();
services.AddMvc();
}
// This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
app.UseResponseCaching();
if (env.IsDevelopment())
{
app.UseBrowserLink();
app.UseDeveloperExceptionPage();
}
else
{
app.UseExceptionHandler("/Home/Error");
}
app.UseStaticFiles();
app.UseMvc(routes =>
{
routes.MapRoute(
name: "default",
template: "{controller=Home}/{action=Index}/{id?}");
});
}
}
and here is the HomeController.cs
[ResponseCache(Duration = 60)]
public class HomeController : Controller
{
public IActionResult Index()
{
return View();
}
public IActionResult About()
{
ViewData["Message"] = "Your application description page.";
return View();
}
public IActionResult Contact()
{
ViewData["Message"] = "Your contact page.";
return View();
}
public IActionResult Error()
{
return View(new ErrorViewModel { RequestId = Activity.Current?.Id ?? HttpContext.TraceIdentifier });
}
}
there is also a timestamp at the bottom of _Layout.cshtml file so i can tell when the page is rendered, like below.
<p>© 2018 - ResponseCachingMiddleware - @DateTime.UtcNow</p>
Cache-Control headers seem to be fine, this is what I get in headers when I load the page but time stamp keeps getting updated on every refresh every second.
Cache-Control:public,max-age=60
What I'm understanding from MS documentations is Response Caching Middleware is the server-side caching mechanism that takes care of caching the response while Response Caching seems to be just a filter to manipulate response headers for caching.
Can't tell if there is something wrong with my understanding or code and I wanna complain that I'm feeling this way too often since I started prototyping with ASP.Net Core. Maybe you could also suggest better resources as a side topic.
I've checked out this post before
ASP.NET Core 2.0 - Http Response Caching Middleware - Nothing cached
Also checked this out but it seems like the only difference is I'm using mvc.
https://github.com/aspnet/ResponseCaching/blob/dev/samples/ResponseCachingSample/Startup.cs
Thanks
Edit: I'm seeing the message below in the output window, cannot find anything about it on google except the few places I already checked for response caching middleware.
Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware:Information:
The response could not be cached for this request.
Note: I wish I could create #response-caching-middleware tag. Not sure #responsecache is relevant.
asp.net caching asp.net-core-2.0 outputcache responsecache
asp.net caching asp.net-core-2.0 outputcache responsecache
edited Jan 12 '18 at 19:37
Engin
asked Jan 12 '18 at 19:31


EnginEngin
236312
236312
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
I had this same confusion recently.
ASP.Net Core's ResponseCaching does provide both client-side caching (through HTTP response headers) & server-side (through a memory cache'd middleware that short-circuits other middlewares if the response is in the cache). The server-side portion reads the HTTP response cache headers to determine if it should do server-side caching (similar to what an ISP or CDN might do).
Unfortunately, debugging the server-side ResponseCaching is tricky because it has weird rules & there's not adequate logging. In my case I pulled down Microsoft's source code to step through it & find the issue with my code.
The note you found in the output window "The response could not be cached for this request" is a clue.
There's 2 parts to the server-side caching of a request. The server has to prime the cache the first time the url is requested. It will serve the cached version the 2nd time it's requested. Pay attention to when the error message shows up, if it's on the 1st or 2nd request. That'll tell you if it couldn't be stored in the cache or if it couldn't be retrieved from the cache.
The rules for both storage & retrieval are in this source code file:
https://github.com/aspnet/ResponseCaching/blob/3bf5f6a1ce69b65c998d6f5c739822a9bed4a67e/src/Microsoft.AspNetCore.ResponseCaching/Internal/ResponseCachingPolicyProvider.cs
Your "Cache-Control:public,max-age=60" header should match these rules just fine.
My guess is you actually had it working, but didn't know how to test it correctly.
There is a counter-intuitive portion of ResponseCaching noted in this issue: https://github.com/aspnet/Home/issues/2607
Essentially, if the browser sends a no-cache or no-store header (when you hit CTRL+F5 or have your debugger tools open), ASP.Net Core's ResponseCaching will honor the browser's request & re-generate the response.
So, to test if your code was working you probably loaded the page, which primed the cache, then you hit CTRL+F5 to force-refresh your browser & you expected the server-side to respond with a cached entry rather than running your WebAPI code. However, it honored the no-cache request header & bypassed the cache (& wrote that message in your output log).
The way to test this would be to clear your browser cache in-between requests (or switch to incognito), rather than using CTRL+F5.
On a side note, honoring the no-cache/no-store request headers was probably a poor design choice since ASP.Net Core's ResponseCache will most likely be used by a server who owns the response, rather than an intermediary cache like a CDN/ISP. I've extended the base ResponseCache with an option to disable honoring these headers (as well as serialize the cache to disk, rather than in-memory only). It's an easy drop-in replacement for the default cache.
You can find my extension here:
https://github.com/speige/AspNetCore.ResponseCaching.Extensions
https://www.nuget.org/packages/AspNetCore.ResponseCaching.Extensions
There are also a few other other gotchas with ResponseCaching to watch out for which you may have already read about in the blog urls you posted. Authenticated requests & responses with set-cookie won't be cached. Only requests using GET or HEAD method will be cached. If the QueryString is different, it'll make a new cache entry. Also, usually you'll want a "Vary" header to prevent caching if certain conditions of a request differ from the previously-cached request (example: user-agent, accept-encoding, etc). Finally, if a Middleware handles a request it'll short-circuit later Middlewares. Make sure your app.UseResponseCaching() is registered before app.UseMVC()
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Callingapp.UseResponseCaching();
beforeapp.UseMvc();
did the trick!
– Jérôme MEVEL
Mar 19 at 4:28
add a comment |
I had the same issue, I was about to pull my hairs over it, I'd set app.UseResponseCaching();
as well as services.AddResponseCaching();
and add ResponseCache
on top of my action exactly like what was told in Microsoft official Docs, despite the the cache-controll
header was set correctly on response returning from server but still nothing cached at server-side.
After couple of hours of sweating on this issue I figured out where the problem arises and why nothing cached at server.
Browsers by default set cache-controll
value to max-age=0
for the request (if the request is not caused by back or forward) even though you set cache-controller
correctly in your response by adding ResponseCache
attribute on top of you action (or controller) since the cache-controller
sent by request is set to max-age=0
, the server is unable to cache response, I think this must be added to list of Response Caching limitation as well
Anyway you can override browser default behavior by adding few line of code right before calling app.UseResponseCaching();
on the other hand you need to add a custom middle-ware to modify request cache-control
header value before calling app.UseResponseCaching();
.
See code below, worked for me hope work for you too
app.Use(async (ctx, next) =>
{
ctx.Request.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
{
Public = true,
MaxAge = TimeSpan.FromSeconds(60)
};
await next();
}
);
app.UseResponseCaching();
for ensuring that ResponseCaching works as expected you can also use postman but you must set 'Send no-cache Header' to off in the setting, see image below
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
add a comment |
If the Cache-Control
header is coming through, then it's working. That's all the server can do from that perspective. The client ultimately makes the decision whether or not to actually cache the resource. Sending the header doesn't force the client to do anything; in fact, the server, in general, cannot force the client to do anything.
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. setmax-age=60
because you specifiedDuration = 60
). Response caching, in general, only sets theCache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.
– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
|
show 12 more comments
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%2f48232911%2fasp-net-core-2-0-responsecaching-middleware-not-caching-on-server%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
I had this same confusion recently.
ASP.Net Core's ResponseCaching does provide both client-side caching (through HTTP response headers) & server-side (through a memory cache'd middleware that short-circuits other middlewares if the response is in the cache). The server-side portion reads the HTTP response cache headers to determine if it should do server-side caching (similar to what an ISP or CDN might do).
Unfortunately, debugging the server-side ResponseCaching is tricky because it has weird rules & there's not adequate logging. In my case I pulled down Microsoft's source code to step through it & find the issue with my code.
The note you found in the output window "The response could not be cached for this request" is a clue.
There's 2 parts to the server-side caching of a request. The server has to prime the cache the first time the url is requested. It will serve the cached version the 2nd time it's requested. Pay attention to when the error message shows up, if it's on the 1st or 2nd request. That'll tell you if it couldn't be stored in the cache or if it couldn't be retrieved from the cache.
The rules for both storage & retrieval are in this source code file:
https://github.com/aspnet/ResponseCaching/blob/3bf5f6a1ce69b65c998d6f5c739822a9bed4a67e/src/Microsoft.AspNetCore.ResponseCaching/Internal/ResponseCachingPolicyProvider.cs
Your "Cache-Control:public,max-age=60" header should match these rules just fine.
My guess is you actually had it working, but didn't know how to test it correctly.
There is a counter-intuitive portion of ResponseCaching noted in this issue: https://github.com/aspnet/Home/issues/2607
Essentially, if the browser sends a no-cache or no-store header (when you hit CTRL+F5 or have your debugger tools open), ASP.Net Core's ResponseCaching will honor the browser's request & re-generate the response.
So, to test if your code was working you probably loaded the page, which primed the cache, then you hit CTRL+F5 to force-refresh your browser & you expected the server-side to respond with a cached entry rather than running your WebAPI code. However, it honored the no-cache request header & bypassed the cache (& wrote that message in your output log).
The way to test this would be to clear your browser cache in-between requests (or switch to incognito), rather than using CTRL+F5.
On a side note, honoring the no-cache/no-store request headers was probably a poor design choice since ASP.Net Core's ResponseCache will most likely be used by a server who owns the response, rather than an intermediary cache like a CDN/ISP. I've extended the base ResponseCache with an option to disable honoring these headers (as well as serialize the cache to disk, rather than in-memory only). It's an easy drop-in replacement for the default cache.
You can find my extension here:
https://github.com/speige/AspNetCore.ResponseCaching.Extensions
https://www.nuget.org/packages/AspNetCore.ResponseCaching.Extensions
There are also a few other other gotchas with ResponseCaching to watch out for which you may have already read about in the blog urls you posted. Authenticated requests & responses with set-cookie won't be cached. Only requests using GET or HEAD method will be cached. If the QueryString is different, it'll make a new cache entry. Also, usually you'll want a "Vary" header to prevent caching if certain conditions of a request differ from the previously-cached request (example: user-agent, accept-encoding, etc). Finally, if a Middleware handles a request it'll short-circuit later Middlewares. Make sure your app.UseResponseCaching() is registered before app.UseMVC()
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Callingapp.UseResponseCaching();
beforeapp.UseMvc();
did the trick!
– Jérôme MEVEL
Mar 19 at 4:28
add a comment |
I had this same confusion recently.
ASP.Net Core's ResponseCaching does provide both client-side caching (through HTTP response headers) & server-side (through a memory cache'd middleware that short-circuits other middlewares if the response is in the cache). The server-side portion reads the HTTP response cache headers to determine if it should do server-side caching (similar to what an ISP or CDN might do).
Unfortunately, debugging the server-side ResponseCaching is tricky because it has weird rules & there's not adequate logging. In my case I pulled down Microsoft's source code to step through it & find the issue with my code.
The note you found in the output window "The response could not be cached for this request" is a clue.
There's 2 parts to the server-side caching of a request. The server has to prime the cache the first time the url is requested. It will serve the cached version the 2nd time it's requested. Pay attention to when the error message shows up, if it's on the 1st or 2nd request. That'll tell you if it couldn't be stored in the cache or if it couldn't be retrieved from the cache.
The rules for both storage & retrieval are in this source code file:
https://github.com/aspnet/ResponseCaching/blob/3bf5f6a1ce69b65c998d6f5c739822a9bed4a67e/src/Microsoft.AspNetCore.ResponseCaching/Internal/ResponseCachingPolicyProvider.cs
Your "Cache-Control:public,max-age=60" header should match these rules just fine.
My guess is you actually had it working, but didn't know how to test it correctly.
There is a counter-intuitive portion of ResponseCaching noted in this issue: https://github.com/aspnet/Home/issues/2607
Essentially, if the browser sends a no-cache or no-store header (when you hit CTRL+F5 or have your debugger tools open), ASP.Net Core's ResponseCaching will honor the browser's request & re-generate the response.
So, to test if your code was working you probably loaded the page, which primed the cache, then you hit CTRL+F5 to force-refresh your browser & you expected the server-side to respond with a cached entry rather than running your WebAPI code. However, it honored the no-cache request header & bypassed the cache (& wrote that message in your output log).
The way to test this would be to clear your browser cache in-between requests (or switch to incognito), rather than using CTRL+F5.
On a side note, honoring the no-cache/no-store request headers was probably a poor design choice since ASP.Net Core's ResponseCache will most likely be used by a server who owns the response, rather than an intermediary cache like a CDN/ISP. I've extended the base ResponseCache with an option to disable honoring these headers (as well as serialize the cache to disk, rather than in-memory only). It's an easy drop-in replacement for the default cache.
You can find my extension here:
https://github.com/speige/AspNetCore.ResponseCaching.Extensions
https://www.nuget.org/packages/AspNetCore.ResponseCaching.Extensions
There are also a few other other gotchas with ResponseCaching to watch out for which you may have already read about in the blog urls you posted. Authenticated requests & responses with set-cookie won't be cached. Only requests using GET or HEAD method will be cached. If the QueryString is different, it'll make a new cache entry. Also, usually you'll want a "Vary" header to prevent caching if certain conditions of a request differ from the previously-cached request (example: user-agent, accept-encoding, etc). Finally, if a Middleware handles a request it'll short-circuit later Middlewares. Make sure your app.UseResponseCaching() is registered before app.UseMVC()
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Callingapp.UseResponseCaching();
beforeapp.UseMvc();
did the trick!
– Jérôme MEVEL
Mar 19 at 4:28
add a comment |
I had this same confusion recently.
ASP.Net Core's ResponseCaching does provide both client-side caching (through HTTP response headers) & server-side (through a memory cache'd middleware that short-circuits other middlewares if the response is in the cache). The server-side portion reads the HTTP response cache headers to determine if it should do server-side caching (similar to what an ISP or CDN might do).
Unfortunately, debugging the server-side ResponseCaching is tricky because it has weird rules & there's not adequate logging. In my case I pulled down Microsoft's source code to step through it & find the issue with my code.
The note you found in the output window "The response could not be cached for this request" is a clue.
There's 2 parts to the server-side caching of a request. The server has to prime the cache the first time the url is requested. It will serve the cached version the 2nd time it's requested. Pay attention to when the error message shows up, if it's on the 1st or 2nd request. That'll tell you if it couldn't be stored in the cache or if it couldn't be retrieved from the cache.
The rules for both storage & retrieval are in this source code file:
https://github.com/aspnet/ResponseCaching/blob/3bf5f6a1ce69b65c998d6f5c739822a9bed4a67e/src/Microsoft.AspNetCore.ResponseCaching/Internal/ResponseCachingPolicyProvider.cs
Your "Cache-Control:public,max-age=60" header should match these rules just fine.
My guess is you actually had it working, but didn't know how to test it correctly.
There is a counter-intuitive portion of ResponseCaching noted in this issue: https://github.com/aspnet/Home/issues/2607
Essentially, if the browser sends a no-cache or no-store header (when you hit CTRL+F5 or have your debugger tools open), ASP.Net Core's ResponseCaching will honor the browser's request & re-generate the response.
So, to test if your code was working you probably loaded the page, which primed the cache, then you hit CTRL+F5 to force-refresh your browser & you expected the server-side to respond with a cached entry rather than running your WebAPI code. However, it honored the no-cache request header & bypassed the cache (& wrote that message in your output log).
The way to test this would be to clear your browser cache in-between requests (or switch to incognito), rather than using CTRL+F5.
On a side note, honoring the no-cache/no-store request headers was probably a poor design choice since ASP.Net Core's ResponseCache will most likely be used by a server who owns the response, rather than an intermediary cache like a CDN/ISP. I've extended the base ResponseCache with an option to disable honoring these headers (as well as serialize the cache to disk, rather than in-memory only). It's an easy drop-in replacement for the default cache.
You can find my extension here:
https://github.com/speige/AspNetCore.ResponseCaching.Extensions
https://www.nuget.org/packages/AspNetCore.ResponseCaching.Extensions
There are also a few other other gotchas with ResponseCaching to watch out for which you may have already read about in the blog urls you posted. Authenticated requests & responses with set-cookie won't be cached. Only requests using GET or HEAD method will be cached. If the QueryString is different, it'll make a new cache entry. Also, usually you'll want a "Vary" header to prevent caching if certain conditions of a request differ from the previously-cached request (example: user-agent, accept-encoding, etc). Finally, if a Middleware handles a request it'll short-circuit later Middlewares. Make sure your app.UseResponseCaching() is registered before app.UseMVC()
I had this same confusion recently.
ASP.Net Core's ResponseCaching does provide both client-side caching (through HTTP response headers) & server-side (through a memory cache'd middleware that short-circuits other middlewares if the response is in the cache). The server-side portion reads the HTTP response cache headers to determine if it should do server-side caching (similar to what an ISP or CDN might do).
Unfortunately, debugging the server-side ResponseCaching is tricky because it has weird rules & there's not adequate logging. In my case I pulled down Microsoft's source code to step through it & find the issue with my code.
The note you found in the output window "The response could not be cached for this request" is a clue.
There's 2 parts to the server-side caching of a request. The server has to prime the cache the first time the url is requested. It will serve the cached version the 2nd time it's requested. Pay attention to when the error message shows up, if it's on the 1st or 2nd request. That'll tell you if it couldn't be stored in the cache or if it couldn't be retrieved from the cache.
The rules for both storage & retrieval are in this source code file:
https://github.com/aspnet/ResponseCaching/blob/3bf5f6a1ce69b65c998d6f5c739822a9bed4a67e/src/Microsoft.AspNetCore.ResponseCaching/Internal/ResponseCachingPolicyProvider.cs
Your "Cache-Control:public,max-age=60" header should match these rules just fine.
My guess is you actually had it working, but didn't know how to test it correctly.
There is a counter-intuitive portion of ResponseCaching noted in this issue: https://github.com/aspnet/Home/issues/2607
Essentially, if the browser sends a no-cache or no-store header (when you hit CTRL+F5 or have your debugger tools open), ASP.Net Core's ResponseCaching will honor the browser's request & re-generate the response.
So, to test if your code was working you probably loaded the page, which primed the cache, then you hit CTRL+F5 to force-refresh your browser & you expected the server-side to respond with a cached entry rather than running your WebAPI code. However, it honored the no-cache request header & bypassed the cache (& wrote that message in your output log).
The way to test this would be to clear your browser cache in-between requests (or switch to incognito), rather than using CTRL+F5.
On a side note, honoring the no-cache/no-store request headers was probably a poor design choice since ASP.Net Core's ResponseCache will most likely be used by a server who owns the response, rather than an intermediary cache like a CDN/ISP. I've extended the base ResponseCache with an option to disable honoring these headers (as well as serialize the cache to disk, rather than in-memory only). It's an easy drop-in replacement for the default cache.
You can find my extension here:
https://github.com/speige/AspNetCore.ResponseCaching.Extensions
https://www.nuget.org/packages/AspNetCore.ResponseCaching.Extensions
There are also a few other other gotchas with ResponseCaching to watch out for which you may have already read about in the blog urls you posted. Authenticated requests & responses with set-cookie won't be cached. Only requests using GET or HEAD method will be cached. If the QueryString is different, it'll make a new cache entry. Also, usually you'll want a "Vary" header to prevent caching if certain conditions of a request differ from the previously-cached request (example: user-agent, accept-encoding, etc). Finally, if a Middleware handles a request it'll short-circuit later Middlewares. Make sure your app.UseResponseCaching() is registered before app.UseMVC()
edited Feb 16 '18 at 16:38
answered Feb 16 '18 at 7:41
Devin GarnerDevin Garner
1,036814
1,036814
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Callingapp.UseResponseCaching();
beforeapp.UseMvc();
did the trick!
– Jérôme MEVEL
Mar 19 at 4:28
add a comment |
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Callingapp.UseResponseCaching();
beforeapp.UseMvc();
did the trick!
– Jérôme MEVEL
Mar 19 at 4:28
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
Thank you for the detailed response. I've abandoned this problem for a while after finding a different solution but I'll check this out as soon as I got back to it. It makes more sense that I was testing it wrong than the functionality didn't exist.
– Engin
Sep 4 '18 at 14:46
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
@DevinGarner looked into your code and you should log exception(because there are). By the way, you should do a performance benchmark on your code compared to default response caching. Your implementation is quite slow :) and should support any IResponseCacheEntry. Regards.
– Fab
Feb 23 at 16:19
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thanks for the code review @Fab if you have time, please submit a pull request with your improvements. Thanks!
– Devin Garner
Feb 25 at 1:13
Thank god I read your answer until the end. Calling
app.UseResponseCaching();
before app.UseMvc();
did the trick!– Jérôme MEVEL
Mar 19 at 4:28
Thank god I read your answer until the end. Calling
app.UseResponseCaching();
before app.UseMvc();
did the trick!– Jérôme MEVEL
Mar 19 at 4:28
add a comment |
I had the same issue, I was about to pull my hairs over it, I'd set app.UseResponseCaching();
as well as services.AddResponseCaching();
and add ResponseCache
on top of my action exactly like what was told in Microsoft official Docs, despite the the cache-controll
header was set correctly on response returning from server but still nothing cached at server-side.
After couple of hours of sweating on this issue I figured out where the problem arises and why nothing cached at server.
Browsers by default set cache-controll
value to max-age=0
for the request (if the request is not caused by back or forward) even though you set cache-controller
correctly in your response by adding ResponseCache
attribute on top of you action (or controller) since the cache-controller
sent by request is set to max-age=0
, the server is unable to cache response, I think this must be added to list of Response Caching limitation as well
Anyway you can override browser default behavior by adding few line of code right before calling app.UseResponseCaching();
on the other hand you need to add a custom middle-ware to modify request cache-control
header value before calling app.UseResponseCaching();
.
See code below, worked for me hope work for you too
app.Use(async (ctx, next) =>
{
ctx.Request.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
{
Public = true,
MaxAge = TimeSpan.FromSeconds(60)
};
await next();
}
);
app.UseResponseCaching();
for ensuring that ResponseCaching works as expected you can also use postman but you must set 'Send no-cache Header' to off in the setting, see image below
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
add a comment |
I had the same issue, I was about to pull my hairs over it, I'd set app.UseResponseCaching();
as well as services.AddResponseCaching();
and add ResponseCache
on top of my action exactly like what was told in Microsoft official Docs, despite the the cache-controll
header was set correctly on response returning from server but still nothing cached at server-side.
After couple of hours of sweating on this issue I figured out where the problem arises and why nothing cached at server.
Browsers by default set cache-controll
value to max-age=0
for the request (if the request is not caused by back or forward) even though you set cache-controller
correctly in your response by adding ResponseCache
attribute on top of you action (or controller) since the cache-controller
sent by request is set to max-age=0
, the server is unable to cache response, I think this must be added to list of Response Caching limitation as well
Anyway you can override browser default behavior by adding few line of code right before calling app.UseResponseCaching();
on the other hand you need to add a custom middle-ware to modify request cache-control
header value before calling app.UseResponseCaching();
.
See code below, worked for me hope work for you too
app.Use(async (ctx, next) =>
{
ctx.Request.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
{
Public = true,
MaxAge = TimeSpan.FromSeconds(60)
};
await next();
}
);
app.UseResponseCaching();
for ensuring that ResponseCaching works as expected you can also use postman but you must set 'Send no-cache Header' to off in the setting, see image below
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
add a comment |
I had the same issue, I was about to pull my hairs over it, I'd set app.UseResponseCaching();
as well as services.AddResponseCaching();
and add ResponseCache
on top of my action exactly like what was told in Microsoft official Docs, despite the the cache-controll
header was set correctly on response returning from server but still nothing cached at server-side.
After couple of hours of sweating on this issue I figured out where the problem arises and why nothing cached at server.
Browsers by default set cache-controll
value to max-age=0
for the request (if the request is not caused by back or forward) even though you set cache-controller
correctly in your response by adding ResponseCache
attribute on top of you action (or controller) since the cache-controller
sent by request is set to max-age=0
, the server is unable to cache response, I think this must be added to list of Response Caching limitation as well
Anyway you can override browser default behavior by adding few line of code right before calling app.UseResponseCaching();
on the other hand you need to add a custom middle-ware to modify request cache-control
header value before calling app.UseResponseCaching();
.
See code below, worked for me hope work for you too
app.Use(async (ctx, next) =>
{
ctx.Request.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
{
Public = true,
MaxAge = TimeSpan.FromSeconds(60)
};
await next();
}
);
app.UseResponseCaching();
for ensuring that ResponseCaching works as expected you can also use postman but you must set 'Send no-cache Header' to off in the setting, see image below
I had the same issue, I was about to pull my hairs over it, I'd set app.UseResponseCaching();
as well as services.AddResponseCaching();
and add ResponseCache
on top of my action exactly like what was told in Microsoft official Docs, despite the the cache-controll
header was set correctly on response returning from server but still nothing cached at server-side.
After couple of hours of sweating on this issue I figured out where the problem arises and why nothing cached at server.
Browsers by default set cache-controll
value to max-age=0
for the request (if the request is not caused by back or forward) even though you set cache-controller
correctly in your response by adding ResponseCache
attribute on top of you action (or controller) since the cache-controller
sent by request is set to max-age=0
, the server is unable to cache response, I think this must be added to list of Response Caching limitation as well
Anyway you can override browser default behavior by adding few line of code right before calling app.UseResponseCaching();
on the other hand you need to add a custom middle-ware to modify request cache-control
header value before calling app.UseResponseCaching();
.
See code below, worked for me hope work for you too
app.Use(async (ctx, next) =>
{
ctx.Request.GetTypedHeaders().CacheControl = new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
{
Public = true,
MaxAge = TimeSpan.FromSeconds(60)
};
await next();
}
);
app.UseResponseCaching();
for ensuring that ResponseCaching works as expected you can also use postman but you must set 'Send no-cache Header' to off in the setting, see image below
edited Aug 10 '18 at 11:21
answered Aug 10 '18 at 11:16


Code_WormCode_Worm
87611520
87611520
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
add a comment |
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
1
1
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
Thank you, I've abandoned this problem for a while now but I'll get back to it shortly and give this a try.
– Engin
Sep 4 '18 at 14:50
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
@Engin happy coding :)
– Code_Worm
Sep 5 '18 at 7:41
add a comment |
If the Cache-Control
header is coming through, then it's working. That's all the server can do from that perspective. The client ultimately makes the decision whether or not to actually cache the resource. Sending the header doesn't force the client to do anything; in fact, the server, in general, cannot force the client to do anything.
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. setmax-age=60
because you specifiedDuration = 60
). Response caching, in general, only sets theCache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.
– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
|
show 12 more comments
If the Cache-Control
header is coming through, then it's working. That's all the server can do from that perspective. The client ultimately makes the decision whether or not to actually cache the resource. Sending the header doesn't force the client to do anything; in fact, the server, in general, cannot force the client to do anything.
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. setmax-age=60
because you specifiedDuration = 60
). Response caching, in general, only sets theCache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.
– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
|
show 12 more comments
If the Cache-Control
header is coming through, then it's working. That's all the server can do from that perspective. The client ultimately makes the decision whether or not to actually cache the resource. Sending the header doesn't force the client to do anything; in fact, the server, in general, cannot force the client to do anything.
If the Cache-Control
header is coming through, then it's working. That's all the server can do from that perspective. The client ultimately makes the decision whether or not to actually cache the resource. Sending the header doesn't force the client to do anything; in fact, the server, in general, cannot force the client to do anything.
answered Jan 12 '18 at 19:36
Chris PrattChris Pratt
160k21245310
160k21245310
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. setmax-age=60
because you specifiedDuration = 60
). Response caching, in general, only sets theCache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.
– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
|
show 12 more comments
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. setmax-age=60
because you specifiedDuration = 60
). Response caching, in general, only sets theCache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.
– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
Can you explain me what's the difference between Response Caching Middleware and Response Caching? As far I can tell, you're describing Response Caching filter's responsibility.
– Engin
Jan 12 '18 at 19:38
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. set
max-age=60
because you specified Duration = 60
). Response caching, in general, only sets the Cache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.– Chris Pratt
Jan 12 '18 at 19:44
There is none. They are two sides of the same coin. The middleware is what actually does the work, while the attribute informs the middleware as to what it should actually do (i.e. set
max-age=60
because you specified Duration = 60
). Response caching, in general, only sets the Cache-Control
header. It does nothing to cache the response server-side. And, like I said, it's 100% up to the client as to whether the header is actually honored. If you're looking for server-side caching, you need to employ in-memory cache or distributed caching.– Chris Pratt
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
Please see the description for Response Caching Middleware from the documentation page I referred to. It clearly states that it stores and serves responses. You might be confusing it with Response Caching.
– Engin
Jan 12 '18 at 19:44
1
1
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
This answer is incorrect. ResponseCaching in ASP.Net Core does both client-side caching (through headers) & Server-Side Caching (similar to OutputCache in previous versions of ASP.Net). OP was specifically asking why the server-side caching wasn't working.
– Devin Garner
Feb 16 '18 at 7:11
1
1
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
@ChrisPratt I have read the source. github.com/aspnet/ResponseCaching I have also successfully used it. You may have been correct about an earlier version of .net core's ResponseCaching, but it has also been a server-side cache for over a year now.
– Devin Garner
Feb 16 '18 at 15:49
|
show 12 more comments
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%2f48232911%2fasp-net-core-2-0-responsecaching-middleware-not-caching-on-server%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