On Sat, Jul 29, 2023 at 3:03 AM 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"... > > no-cache means it's ok to cache but you must revalidate before re-using what you have. must-revalidate seems more strict than no-cache because of the following bits <https://datatracker.ietf.org/doc/html/rfc7234#section-5.2.1:~:text=The%20must%2Drevalidate,Gateway%20Timeout)%20response.>: "In all circumstances a cache MUST obey the must-revalidate directive; in particular, if a cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.". no-cache doesn't have these extra details. So, maybe this 3 directives combo could be interpreted as this-is-quite-sensitive-stuff, or it could be a mix of that and folks copy-pasting cache-control recipes. *Note: there is also the "private" directive and guidance from Fastly to combine no-store and private <https://docs.fastly.com/en/guides/caching-best-practices>. On the other hand, MDN disagrees <https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cache-Control#:~:text=In%20theory%2C%20if%20directives%20are%20conflicted%2C%20the%20most%20restrictive%20directive%20should%20be%20honored.%20So%20the%20example%20below%20is%20basically%20meaningless%20because%20private%2C%20no%2Dcache%2C%20max%2Dage%3D0%20and%20must%2Drevalidate%20conflict%20with%20no%2Dstore.> that this even makes sense, but in practice it's apparently what folks have to do with some CDNs (discussion in Japanese <https://srad.jp/comment/4073928>) to avoid edge cases such as race conditions.* *Fergal*, should / could we add a histogram of cache-control values and combos? > 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/561ff7c5-45aa-0c9e-8157-924199f82fb4%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/561ff7c5-45aa-0c9e-8157-924199f82fb4%40chromium.org?utm_medium=email&utm_source=footer> > . > -- Kenji BAHEUX (my how-to <http://balance/kenjibaheux>) Product Manager - Chrome Google Japan -- 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/CADWWn7Uz7cBv1ux4oGkUG%3Dm6YxYpuZ5RDdNSEyT1ECVPVHC10Q%40mail.gmail.com.
