This is potentially a naive question, since I'm not familiar with all of the CC headers, but how would the following situation work (or rather how is this meant to work?):
I have an "overview" page that lists some items that come from a database. This page has an input box with a button to add a new item. The way the button works is it POSTs to the same page to add an entry into some database, and then redirects to a new "details" page. The "overview" page also currently sends CCNS, so that when the user clicks back from the "details" page, they see an updated list which was re-fetched from the server. Without CCNS, going back hits BFCache and the list is not up to date. Is there a simple solution to this if CCNS doesn't prevent BFCache? This is a toy example: https://rocky-merciful-creek.glitch.me/nostore/one.html?nostore=1 if you click the link and go back, the number changes. If query nostore=0 then it doesn't. The query parameter just controls whether CCNS is sent Thanks! vmpstr On Thu, Sep 7, 2023 at 5:40 AM 'Mingyu Lei' via blink-dev < blink-dev@chromium.org> wrote: > (Not to answer how the 3 minutes was originally decided, but just to share > a bit of the context.) > > The default BFCache timeout was set to 3 minutes on Chrome for a long > time. Only after Sep 2022, it was increased to 10 minutes after evaluating > the hit rate improvement and other impacts (https://crbug.com/1305878). > For CCNS pages, we will follow the old timeout of 3 minutes, or in other > words, the changes that increase BFCache timeout from last year won't be > applied to CCNS pages. > > > On Thu, Sep 7, 2023 at 12:21 AM Daniel Bratell <bratel...@gmail.com> > wrote: > >> Thanks for your answers. I think we are on the same page since I too >> consider this to be of high value to users. The difference in perceived >> performance is so large that I understand that it is worth adding some >> magic for. >> >> On the other hand, as you also know, there is a risk and I want to be >> sure that it is fully understood. You have mentioned a shorter timeout a >> couple of times, and the explainer says it will be 3 minutes instead of the >> default 10 minute cache timeout. I'm well aware of sites that time out >> authentications server side after a couple of minutes of inactivity and I >> guess 3 would be in the same ball park. Did you pick that particular number >> for any particular reason. Is it the lowest number that still gives any >> benefits? >> >> /Daniel >> On 2023-09-01 10:05, 'Fergal Daly' via blink-dev wrote: >> >> Sorry for the slow reply, I've had to focus on some other things in the >> last month. The reply below covers a few overlapping topics that were >> brought up in this thread by Yoav Weiss and Daniel Bratell. >> >> >> On Sat, 29 Jul 2023 at 03:03, Mike Taylor <miketa...@chromium.org> wrote: >> >>> Thanks for the additional analysis. Another question I have, if a site >>> sends: >>> >>> "Cache-Control: no-cache, no-store, must-revalidate" (copypasta from >>> https://stackoverflow.com/a/2068407), >>> would it be treated differently as "Cache-Control: no-store"? I'm trying to >>> think of signals that might be useful as >>> heuristics for "no seriously don't ever cache this"... >>> >>> >> We would prefer not to do this and other browsers are in agreement >> <https://github.com/whatwg/html/issues/5744>. If we give any kind of >> simple header that prevents BFCaching, it will become the wide-spread >> stack-exchange-documented way to opt out of BFCache. Any site that truly >> cannot tolerate its data entering BFCache and doesn't already fall under >> one of our conditions for avoiding BFCache, can erase content in a >> `pagehide` handler as they enter BFCache and reload it in a `pageload` >> handler if restored. This is pretty simple to do for anyone who truly needs >> it >> (worst case they trigger a reload from JS when leaving BFCache, obviously >> not a good user experience but we have to weight that against block BFCache >> for many users) but it still provides a little bit of a barrier, so >> hopefully people think twice and instead correctly support BFCache rather >> than casually opting out, >> >> F >> >> On 7/27/23 9:04 AM, Mingyu Lei wrote: >>> >>> Hi Mike, >>> >>> Following our previous response, we would like to share the usage data >>> that we have collected from the beta channel. 18.76% of history navigations >>> are not restored from BFCache because of the CCNS header only. The >>> following are the breakdowns: >>> >>> - No RPC containing CCNS response header: 8.63% >>> - *No cookie modification: 6.70%* >>> - With non-HttpOnly cookie modifications only: 1.38% >>> - With HttpOnly or non-HttpOnly cookie modifications: 0.55% >>> - With RPC containing CCNS response header: 10.13% >>> - No cookie modification: 1.01% >>> - With non-HttpOnly cookie modifications only: 7.86% >>> - With HttpOnly or non-HttpOnly cookie modifications: 1.26% >>> >>> Based on these figures, we will update the proposal to evict the BFCache >>> entry with any cookie modification for the current phase. This should give >>> us 6.70% improvement in cache hit rate. >>> >>> We could continue the HttpOnly cookie discussion in the future. >>> >>> On Sat, Jul 22, 2023 at 12:46 AM Mingyu Lei <le...@google.com> wrote: >>> >>>> Hi Mike, >>>> >>>> Thanks for the comments. We have discussed the concerns you raised >>>> before and please find the replies below. >>>> >>>> >>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies >>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure" >>>>> cookies. >>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute >>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something >>>>> else? >>>>> >>>> >>>> >>>>> Later in >>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api, >>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only" >>>>> cookies have changed. Are these cookies setting only the "HttpOnly" >>>>> attribute, or is this intended to say "HTTPS-only" as above? >>>>> >>>> >>>> The short answer is that we will only monitor HttpOnly cookies, >>>> regardless of whether they are secure or not. The terms in the explainer >>>> were unclear, and we will fix them. >>>> >>>> I see that >>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477 >>>>> references this work. Did we learn anything from experimentation in the >>>>> wild (not sure if y'all ran an experiment)? >>>>> >>>>> I'm curious if y'all have looked at stats on the uptake of >>>>> secure/httponly cookies vs "non-secure" cookies being set by pages >>>>> returned >>>>> from RPCs sent with an Authorization header (though I wouldn't be >>>>> surprised >>>>> if we don't have UMA for that... perhaps just globally would be useful to >>>>> consider). >>>>> >>>> >>>> We are currently conducting a Finch experiment to collect the hit rate >>>> on beta, and the data will be available next week. We will share it with >>>> you again after we have the data. >>>> >>>> With that data, we will be able to tell the percentage of page loads >>>> that observe HttpOnly cookie changes, any cookie changes, or no cookie >>>> changes. There will also be another dimension about whether the page had >>>> sent out RPC with CCNS response. There is no pre-existing UMA for this, but >>>> we have recorded the reasons why BFCache is not restored. >>>> >>>> My only concern (which may not be grounded in reality) would be for >>>>> sites not following best practices... >>>> >>>> >>>> We expect that there will be cases where pages are restored >>>> inappropriately where sites are not following good practice. We don't have >>>> an idea of the size of this problem. We will have data from the beta >>>> channel soon that will tell us what the difference would be in terms of >>>> BFCache hit-rate between *monitoring all cookies* and *only monitoring >>>> HttpOnly cookies*. Our thought process looks like this: >>>> >>>> If *monitoring all cookies* already gives us large hit-rate >>>> improvement, *or* the difference between *monitoring all cookies* and *only >>>> monitoring HttpOnly cookies* is small, then we are happy to just be >>>> conservative and go with *monitoring all cookies*. Otherwise*, we >>>> would like to discuss this further. >>>> >>>> >>>> ** "Otherwise" means monitoring all cookies will only give us >>>> negligible cache hit-rate improvement, and monitoring HttpOnly cookies will >>>> give us a much larger increase.* >>>> >>>> Thanks, >>>> Mingyu >>>> >>>> On Wed, Jul 12, 2023 at 12:11 AM Mike Taylor <miketa...@chromium.org> >>>> wrote: >>>> >>>>> On 7/11/23 2:19 AM, 'Fergal Daly' via blink-dev wrote: >>>>> >>>>> [BCC chrome-bfca...@google.com] >>>>> >>>>> On Tue, 11 Jul 2023 at 15:16, Mingyu Lei <le...@google.com> wrote: >>>>> >>>>>> +chrome-bfcache <chrome-bfca...@google.com> >>>>>> >>>>>> On Tue, Jul 11, 2023 at 1:08 PM Mingyu Lei <le...@google.com> wrote: >>>>>> >>>>>>> Contact emails kenjibah...@chromium.org, fer...@chromium.org, >>>>>>> denom...@chromium.org, le...@chromium.org >>>>>>> >>>>>>> Specification >>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md >>>>>>> >>>>>>> Design docs >>>>>>> https://docs.google.com/document/d/1qX1w6L6laTzpFTh78dvT7wwC1060Z3he2Azp4BAwsUE/edit?usp=sharing >>>>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md >>>>>>> >>>>>> This is a really well-written explainer, thank you! >>>>> >>>>> One point of clarification: >>>>> >>>>> >>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#secure-cookies >>>>> references "HTTPS-only" cookies, as well as "secure" vs "insecure" >>>>> cookies. >>>>> By "HTTPS-only", do you mean a cookie that sets the "secure" attribute >>>>> (including "__Secure-" prefixes), _and_ sets "HttpOnly"? Or something >>>>> else? >>>>> >>>>> Later in >>>>> https://github.com/fergald/explainer-bfcache-ccns/blob/main/README.md#allow-ccns-documents-to-be-bfcached-without-the-api, >>>>> the proposal is that CCNS pages are safe to bfcache if no "HTTP-only" >>>>> cookies have changed. Are these cookies setting only the "HttpOnly" >>>>> attribute, or is this intended to say "HTTPS-only" as above? >>>>> >>>>> Summary >>>>>>> >>>>>>> A behavior change to safely store (and restore) pages in the >>>>>>> Back/Forward Cache despite the presence of a "Cache-control: no-store" >>>>>>> HTTP >>>>>>> header on HTTPS pages. This would allow pages to enter BFCache and be >>>>>>> restored as long as there are no changes to cookies or to RPCs using the >>>>>>> `Authorization:` header. >>>>>>> >>>>>>> >>>>>>> Blink component UI>Browser>Navigation>BFCache >>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:UI%3EBrowser%3ENavigation%3EBFCache> >>>>>>> >>>>>>> Search tags bfcache <https://chromestatus.com/features#tags:bfcache> >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>> I see that >>>>> https://github.com/w3ctag/design-reviews/issues/786#issuecomment-1515742477 >>>>> references this work. Did we learn anything from experimentation in the >>>>> wild (not sure if y'all ran an experiment)? >>>>> >>>>> >>>>>>> >>>>>>> TAG review status Not applicable >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>> I'm curious if y'all have looked at stats on the uptake of >>>>> secure/httponly cookies vs "non-secure" cookies being set by pages >>>>> returned >>>>> from RPCs sent with an Authorization header (though I wouldn't be >>>>> surprised >>>>> if we don't have UMA for that... perhaps just globally would be useful to >>>>> consider). >>>>> >>>>> My only concern (which may not be grounded in reality) would be for >>>>> sites not following best practices... >>>>> >>>>> >>>>>>> >>>>>>> *Gecko*: No signal >>>>>>> >>>>>>> *WebKit*: No signal >>>>>>> >>>>>> Can we request signals? >>>>> >>>>> >>>>>>> *Web developers*: No signals >>>>>>> >>>>>>> *Other signals*: >>>>>>> >>>>>>> WebView application risks >>>>>>> >>>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>>> that it has potentially high risk for Android WebView-based >>>>>>> applications? >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? No >>>>>>> >>>>>>> BFCache is not supported on WebView, so this change has no impact >>>>>>> there. >>>>>>> >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? No >>>>>>> >>>>>>> Flag name on chrome://flags >>>>>>> >>>>>>> Finch feature name CacheControlNoStoreEnterBackForwardCache >>>>>>> >>>>>>> Requires code in //chrome? False >>>>>>> >>>>>>> Tracking bug >>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1228611 >>>>>>> >>>>>>> Launch bug https://launch.corp.google.com/launch/4251651 >>>>>>> >>>>>>> Estimated milestones >>>>>>> DevTrial on desktop 116 >>>>>>> DevTrial on Android 116 >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> Open questions about a feature may be a source of future web compat >>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>> issues in the project for the feature specification) whose resolution >>>>>>> may >>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>> structure of >>>>>>> the API in a non-backward-compatible way). >>>>>>> None >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> https://chromestatus.com/feature/6705326844805120 >>>>>>> >>>>>>> Links to previous Intent discussions >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://chromestatus.com/>. >>>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "blink-dev" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to blink-dev+unsubscr...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHLkbL7vmubNOsrA2PKngz4xeV%3DXyuLN73oS4XBea50Xe9A%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+unsubscr...@chromium.org. >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAozHL%3D0vS96LyxmMgf7C7U93FudaP6k7OLX0MKq5jdW5fNZzA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAN_fHtmo4p9pYZ3HNGqped8MCBfTWXuNd_VC%3DoV4PHEVi73W%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2OitQJkqpb4MU41rpR%2BPU34BCcHU-Xk7VQBqyfe6TNT%3Dg%40mail.gmail.com.
