Intent to Ship: Fetch API: Request.cache

[Yutaka Hirano]

Contact emails

yhi...@chromium.org

Spec

https://fetch.spec.whatwg.org/#dom-request-cache

Summary

Request.prototype.cache and RequestInit.cache enables developers to observe / control cache mode for a Request.

By setting RequestInit.cache, a developer can make a fetch which fails if the request is not stored in the cache, for example.

  fetch('/', {mode: 'same-origin', cache: 'only-if-cached'});

By observing Request.cache on a service worker, a developer can distinguish whether a request is a reload request or not, for example.

  self.addEventListener('fetch', e => {

    if (e.request.cache === 'no-cache') {

      // We can serve a stale request stored in the Cache storage

      ...

    }

  });

Link to “Intent to Implement” blink-dev discussion

None (Sorry - it looks we forgot to send an intent to implement when we started the effort)

Link to Origin Trial feedback summary

None

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Demo link

None

Debuggability

None

Risks

Interoperability and Compatibility

The risks are low as the spec is stable and Firefox already shipped the feature.

Edge: No signals

Firefox: Shipped

Safari: No signals

Web developers: No Signals

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with? Service Worker

Could the default usage of this API make it hard for Chrome to maintain good performance (i.e. synchronous return, must run on a certain thread, guaranteed return timing)?

No

Activation

Will it be challenging for developers to take advantage of this feature immediately, as-is?

No

Would this feature benefit from having polyfills, significant documentation and outreach, and/or libraries built on top of it to make it easier to use?

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

Tests are available as web platform tests: fetch/api/request/request-cache* and fetch/api/request/request-error.html

Entry on the feature dashboard

https://www.chromestatus.com/features/5166560033374208

[Ben Kelly]

On Thu, Nov 9, 2017 at 10:01 PM, Yutaka Hirano <yhi...@chromium.org> wrote:

Interoperability and Compatibility

The risks are low as the spec is stable and Firefox already shipped the feature.

Edge: No signals

Firefox: Shipped

Safari: No signals

As far as I can tell Request.cache is shipped in safari.  While wpt.fyi claims safari fails the tests, I ran them manually in safari 11.0.1 via w3c-test.org and safari passes all the cases I checked.

 

Ben

[Yutaka Hirano]

Thank you. You're right, they have shipped it.

 - https://webkit.org/blog/7030/release-notes-for-safari-technology-preview-16/

 - https://trac.webkit.org/changeset/207086/webkit

 - https://bugs.webkit.org/show_bug.cgi?id=162281

I will fix the feature dashboard.

[Chris Harrelson]

LGTM1

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6EzZbU7UVskme%3DezaSpShxJ%2BpMv5mh%3D-tbFP8kS-NepoQ%40mail.gmail.com.

[Yoav Weiss]

LGTM2

On Thu, Nov 9, 2017 at 10:01 PM Yutaka Hirano <yhi...@chromium.org> wrote:

Contact emails

yhi...@chromium.org

Spec

https://fetch.spec.whatwg.org/#dom-request-cache

Summary

Request.prototype.cache and RequestInit.cache enables developers to observe / control cache mode for a Request.

By setting RequestInit.cache, a developer can make a fetch which fails if the request is not stored in the cache, for example.

  fetch('/', {mode: 'same-origin', cache: 'only-if-cached'});

By observing Request.cache on a service worker, a developer can distinguish whether a request is a reload request or not, for example.

  self.addEventListener('fetch', e => {

    if (e.request.cache === 'no-cache') {

      // We can serve a stale request stored in the Cache storage

Is this comment correct? I'd think it should be that we *cannot* serve stale resources in this case.

 

--

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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6Gf662CarK-6rDnQRuDBdTJA5HdrFsSvNNJEFff6Sf%3DWQ%40mail.gmail.com.

[Yutaka Hirano]

  self.addEventListener('fetch', e => {

    if (e.request.cache === 'no-cache') {

      // We can serve a stale request stored in the Cache storage

 

> Is this comment correct? I'd think it should be that we *cannot* serve stale resources in this case.

Sorry, I left a stale comment (the option in the example was originally force-cache). The comment is not correct.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

LGTM3

I tried to verify that the tests were passing about the same as the other browsers, but it looks like something is broken with wpt.fyi at the moment.  Are there any known failures for tests that pass in Firefox or Safari?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABihn6FdTUYcPGaukbpg8Wop6nBpX_iaG6Eihv4z2HqF2y5T%3DQ%40mail.gmail.com.

[Yoav Weiss]

Looking at https://chromium-review.googlesource.com/c/chromium/src/+/758376 it's not immediately obvious how the restrictions around redirects and only-if-cached work. I see it is tested, so I'm assuming it does, but could you point me to the relevant code?

[Yutaka Hirano]

wpt.fyi uses an old Chrome (63.0).

You can use flakiness dashboard with code search for -expected.txt.

As far as I know all related tests pass.

[Yutaka Hirano]

It's tested in request-error.js imported from request-error.html. We allow only-if-cached only with mode: "same-origin" which rejects all cross-origin redirects. Does this answer your question?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Yoav Weiss]

Discussed this with Yutaka and the right redirect behavior simply falls off from our restrictions on cross-origin redirects for same origin requests. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.