Re: [whatwg/fetch] How are reloads mapped to cache modes? (#524)

> If (2) should not be specified, I feel using "reload" name is confusing. I expect the cache mode to be "reload" when I hit a reload button (if there is "reload" option). In other words, if the value means "bypass the cache", (setting the compatibility aside) I think changing "reload" to "bypass the cache" would be good.

So `RequestCache` and its `reload` value can be reasoned about solely via the Fetch API.  Is it not reasonable for code to want "reload" the URL its passing to fetch?  The defined before seems reasonable for the name:

> Fetch behaves as if there is no HTTP cache on the way to the network. Ergo, it creates a normal request and updates the HTTP cache with the response. 

Now, we just happen to also expose the value the browser UX triggers when its reload/refresh/whatever button is pushed via the FetchEvent.  For a "force reload" UX interaction we use the `reload` type in Firefox and for a "normal reload" UX interaction we use a different type.  Why should the UX button behavior force the naming for all uses of `fetch()`?  The two just seem like different things to me.

Now, I don't care overly much about names normally, but we've been shipping the `reload` value for a year now:

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

Usage is probably low, so it could possibly be changed.  It would be nice, however, to have a stronger reason.  There is cost to changing at this point.

In regards to `isReload` I think part of the reason it was removed was that it was poorly defined for navigation-vs-subresource loads.  For example, some people thought it should be set for all subresources from a reloaded page for all time.  Others expected it only to be set on the navigation request, etc.  I wouldn't object to restoring `isReload` if we can sort out those issues.  It does seems to provide an additional signal in that the browser can note "this was a UX reload vs someone calling fetch with a RequestCache value".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/524#issuecomment-294504782