Skip to content

Add AntiforgeryOptions.AllowBackForwardCache - #68738

Open
astralmaster wants to merge 1 commit into
dotnet:mainfrom
astralmaster:antiforgery-allow-bfcache
Open

Add AntiforgeryOptions.AllowBackForwardCache#68738
astralmaster wants to merge 1 commit into
dotnet:mainfrom
astralmaster:antiforgery-allow-bfcache

Conversation

@astralmaster

Copy link
Copy Markdown

Summary

Fixes #54464. By default the antiforgery system sets Cache-Control: no-cache, no-store on responses that carry a token (DefaultAntiforgery.SetDoNotCacheHeaders). Browsers treat no-store as opting the response out of the back/forward cache, so using the back button re-fetches the page from the server, which is slower and shows up as a page diagnostics warning.

Change

Add an opt-in AntiforgeryOptions.AllowBackForwardCache (default false, so existing behavior is unchanged). When set to true, the header becomes Cache-Control: no-cache, private instead of no-cache, no-store: dropping no-store lets the browser use the back/forward cache, and private keeps the response out of shared caches.

This follows the triage note on the issue, which suggested marking the header private to avoid storage in shared caches. I kept it opt-in so the default does not change and no existing behavior regresses. If you would rather change the default instead (the triage note mentioned that is reasonable, pending browser end-to-end testing), I am happy to adjust.

Testing

Added tests to DefaultAntiforgeryTest verifying that with the option set the header is no-cache, private, and that an existing no-cache, no-store header is replaced, while all existing tests for the default no-cache, no-store behavior continue to pass. The full Antiforgery test suite (187 tests) passes on Linux and Windows.

By default the antiforgery system sets Cache-Control: no-cache, no-store on
responses that carry a token. Browsers treat no-store as opting the response
out of the back/forward cache, so navigating back re-fetches the page from the
server.

Add an opt-in AntiforgeryOptions.AllowBackForwardCache. When set, the header is
no-cache, private instead, which keeps the response out of shared caches while
allowing the browser's back/forward cache. The default is unchanged.

Fixes dotnet#54464
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow backwards-forwards navigation caching with antiforgery tokens

1 participant