- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Sat, 18 Jul 2015 05:57:10 +1200
- To: ietf-http-wg@w3.org
On 18/07/2015 5:26 a.m., Guille -bisho- wrote: > On Fri, Jul 17, 2015 at 2:23 AM, Ben Maurer wrote: > >> On Thu, Jul 16, 2015 at 9:07 PM, Martin Thomson wrote: >>> >>> Like I said, you can implement your proposed solution today, without >>> writing any standards. Sure, only Chrome supports it right now, but >>> that's a whole lot more of the web than none of it. >>> >> >> Using unique URIs to define resources is a common behavior to many sites >> and is widely recommended in blogs/books/etc. It seems worth creating a >> standard way to implement this recommendation that is far simpler than a >> service worker. >> > > Agree! > > But again, why not just changing the page reload behavior by some directive > on the page reloaded, rather than changing the caching semantics of the > cached objects? Changing the caching semantics to make a url absolutely > permanent is dangerous as we discussed, you can freeze a page. Because a) this is about revalidation (Ctrl+r) rather than reloading (Ctrl+Shift+r) and b) revalidation also happens a lot from non-browser client and middleware. The latter is very unlikely to have even looked at the payload before trying its revalidation. If you put it in the payload it effectively becomes an end-to-end feature only of use to private caches (aka browser and closely related apps). > > My proposal to just specify the reload behavior for subresources (disabling > revalidation) on the page that causes the fetches looks a simple and less > dangerous. Just makes the reload button same as clicking on the url bar and > pressing enter again. > If this were a feature only of use to browsers. I would agree with you. But its also of potential use to shared/middleware caches for the same purpose of reducing revalidations. Which means header solutions are much preferrable over payload ones. Amos
Received on Friday, 17 July 2015 17:58:16 UTC