• Resolved p15h

    (@prestonwordsworth)


    It’s come to our notice that when setting the plugin to bypass certain types of pages such as is_archive, a no-store is set for the Cache-Control header in addition to no-cache and max-age=0, a setup that prevents the pages in question being stored in browsers’ back/forward cache.

    I wonder if you see any drawbacks for the plugin to not use no-store in this case in the light of the web.dev piece linked to above?

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Contributor iSaumya

    (@isaumya)

    Hi @prestonwordsworth,
    Thanks for posting this. I will look into it and if possible remove the no-store value from cache-control header. Will keep you posted.

    Update: I don’t think removing the no-store will be a good idea as the same bypass logic is also used for logged-in user sessions and for that the bfcache can cause an issue if the login token is expired.

    • This reply was modified 1 year, 8 months ago by iSaumya.
    Thread Starter p15h

    (@prestonwordsworth)

    @isaumya, are you referring to cases where pages selected for bypass (eg is_archive) may also be pages behind login?

    Plugin Contributor iSaumya

    (@isaumya)

    I’m taking about the entire bypassing logic. The same logic is used for bypassing logged-in users and the pages you select to bypass like archive.

    Thread Starter p15h

    (@prestonwordsworth)

    Many thanks for clarifying this! So, short of refactoring the bypass logic to take account of these different purposes, I guess for now we would use CF’s transform rules to modify the header for the pages in question.

    Plugin Contributor iSaumya

    (@isaumya)

    Hi @prestonwordsworth,
    Yes that’s a great idea. If there are some specific pages where you would like to remove the no-store then I think CF Transform rule to modify the Response Header would be the best.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘Cache-Control: no-store prevents bfcache’ is closed to new replies.