AutoValidateAntiforgeryTokenAttribute erase Cache-Control

[daikoz]

Hi,

I use .net core 2.1 preview 1.

In Startup.cs, I use:

     services.AddMvc(options =>
            {
                options.Filters.Add(new AutoValidateAntiforgeryTokenAttribute());
            }).SetCompatibilityVersion(CompatibilityVersion.Version_2_1);

AutoValidateAntiforgeryTokenAttribute is use to validate automatically antiforgery. AutoValidateAntiforgeryTokenAttribute add "cache-control: no-cache, no-store" to the header of http response.

On my controller:

        [HttpGet]
        [HttpHead]
        [Route("")]
        [NoCacheHttpHeaders]
        public ActionResult Index()
        {
            return View();
        }

I use NoCacheHttpHeaders attribute of NWebsec.AspNetCore.Mvc. to add this header:

Cache-Control: no-cache, no-store, must-revalidate Expires: -1 Pragma: no-cache

https://docs.nwebsec.com/en/latest/nwebsec/Configuring-cache-headers.html

Issue

AutoValidateAntiforgeryTokenAttribute rewrite value in cache-control instead of to add values: no-cache, no-store. must-revalidate is removed.

[mkArtakMSFT]

Thanks for contacting us, @zokiad. @javiercn, can you please look into this? Thanks!

[mkArtakMSFT]

Ping @javiercn

[javiercn]

@mkArtakMSFT This is by design. Antiforgery sets the cache-control to "no-cache no-store" which is the strongest level it can be, as it instruct proxies to not store the information and to not server the cached responses without validating with the server first.

must-revalidate tells proxies to validate the cache-entries when the response has become stale, so when used in conjunction with no-cache, I believe it's redundant.

Here are the relevant sections of the RFC that cover this. https://tools.ietf.org/html/rfc7234#section-5.2.2.2 https://tools.ietf.org/html/rfc7234#section-5.2.2.1

Here is the line of code that logs the fact that the cache-control header is being overriden: https://github.com/aspnet/Antiforgery/blob/dev/src/Microsoft.AspNetCore.Antiforgery/Internal/DefaultAntiforgery.cs#L386

While antiforgery overrides the cache-control header, it sets it to its most constraining level, so no action is needed here.

Thanks for reporting this.