Create an account

Very important

  • To access the important data of the forums, you must be active in each forum and especially in the leaks and database leaks section, send data and after sending the data and activity, data and important content will be opened and visible for you.
  • You will only see chat messages from people who are at or below your level.
  • More than 500,000 database leaks and millions of account leaks are waiting for you, so access and view with more activity.
  • Many important data are inactive and inaccessible for you, so open them with activity. (This will be done automatically)


Thread Rating:
  • 924 Vote(s) - 3.4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
ASP.NET MVC OutputCacheAttribute with external cache providers

#1
After switching an ASP.NET MVC 5 application to Azure Redis (`Microsoft.Web.RedisOutputCacheProvider` Nuget package) I was surprised to see that `OutputCacheAttribute` when set to use either `OutputCacheLocation.Any` or `OutputCacheLocation.ServerAndClient`

[Route("Views/Orders")]
[OutputCache(Duration = 600, Location = OutputCacheLocation.Any)]
public ActionResult Orders()
{
}

randomly generates the following error:

> When using a custom output cache provider like 'RedisOutputCache',
> only the following expiration policies and cache features are
> supported: file dependencies, absolute expirations, static
> validation callbacks and static substitution callbacks.

which is weird as the declaration above clearly defines just absolute expiration without any advanced stuff like `varybyparam`. After some searching it looks like there is no fix to [this issue][1] which is extremely frustrating. Are there any external cache providers compatible with ASP.NET caching mechanics? If not, how do you implement server side HTTP output caching in cluster scenarios in MVC/WebApi apps?


[1]:

[To see links please register here]

Reply

#2
The issue is that if the endpoint is authenticated, then by definition the output varies by the user. So basically all external output cache providers are no longer an option.

Your options are either:

1. Unprotect the endpoints if they could allow anonymous safely
2. Use local caching that can vary by user
3. Split up your endpoints so that you use child actions, and/or AJAX calls for protected data. This can allow you to make most things public, but keep the actual data un-cached and protected
4. Cache at a different tier than output. Is your app server request/response and view rendering really your scale pain point? Or is it more likely the DB, and any service tier calculations? Caching in those layers are easy, and can vary by user easily as needed.
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

©0Day  2016 - 2023 | All Rights Reserved.  Made with    for the community. Connected through