Only-if-cached

[mnot]

As discussed in #39, it might be possible to bring back the only-if-cached mode if it's restricted to same-origin.

[tyoshino]

@KenjiBaheux said in #39 (comment) that same-origin would be too restrictive. The idea suggested by him that we attach some info to cache entries so that we don't reveal the fact the URL has been accessed by another origin would complicate cache logic much. So, the first step would be restricting it to same-origin only, and then let's hear what developers would say.

[annevk]

@ehsan, thoughts?

Do we want to require mode to be "same-origin" or do we want to enforce it in the same place where we enforce mode, but also support this feature when mode is "cors", but it just happens to be a same-origin fetch?

[ehsan]

krijnhoetmer.nl is currently inaccessible so I can't read the discussion that led to removing only-if-cached. I'm assuming the attack vector there was a privacy leak using this cache mode to see if an arbitrary URL has already been visited.

It's unclear to me what same-origin here means exactly, as @annevk mentioned. Also, if it's about the origin actually being fetched, how is a redirect from same-origin to cross-origin and back to same-origin supposed to be handled?

[annevk]

Yeah, "only-if-cached" would give extremely precise results whether the target URL has been visited at some point by the user.

I think we would not support cached redirects for this feature so that would return a network error. I guess we don't need to require a particular mode then, either the URL is same-origin and in the cache, or it's a network error. The advantage of requiring a particular mode though might be that we can then more easily expand this feature by allowing more modes going forward, that would now just throw when used. Thoughts?

[ehsan]

I have difficulty imagining what modes we'd want to allow this for in the future.

Not supporting cached redirects for this sounds good to me.

[tyoshino]

The advantage of requiring a particular mode though might be that we can then more easily expand this feature by allowing more modes going forward, that would now just throw when used. Thoughts?

+1

Not supporting cached redirects for this sounds good to me.

+1

[annevk]

It seems there is some implementer support for adding this. I will do so unless someone else wants to pick it up.

[ehsan]

https://bugzilla.mozilla.org/show_bug.cgi?id=1272436

[asutherland]

The spec change didn't address the "not supporting cached redirects" decision reached. Should this be accomplished by requiring that redirect mode be set to "error" like the requirement that the request mode be "same-origin"?

Specifically, line 22 of the Request constructor is currently If request's cache mode is "only-if-cached" and request's mode is not "same-origin", then throw a TypeError. but it could be augmented to be: If request's cache mode is "only-if-cached" and request's mode is not "same-origin" and request's redirect mode is not "error", then throw a TypeError.

This shares the advantage with the same-origin strategy that if the constraint is relaxed in the future then existing code will not observe a change in behavior until the code is changed. (And the code can somewhat detect the presence of the constraint or not by whether the request constructor throws.)