On Fri, 8 Sept 2023 at 02:21, Vladimir Levin <vmp...@chromium.org> wrote:
> 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.
>
That seems correct and is a problem with BFCache in general. E.g. you hit
back and your shopping cart has the wrong number of items.
> Is there a simple solution to this if CCNS doesn't prevent BFCache?
>
The one-size-fits-all solutions is something like
addEventListener("pageshow", e => {
if (e.persisted) {
document.body.innerHTML = "";
location.reload();
}
})
Which is not great for users but also not terrible, the time to load will
be increased by the duration of a BFCache restore which is mostly < 100ms
and much less on a fast device.
The better UX would be to have a `pageshow` handler that refreshes just the
data that needs refreshing. The difficulty of doing that is heavily
dependent on the site design,
F
> 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/CAAozHLmW2XCFC1d61x1r%2B1c8z_PqoukKOs0EDgDct9cPvRc4eQ%40mail.gmail.com.
