- From: Tingan Ho <tingan87@gmail.com>
- Date: Fri, 14 Mar 2014 12:02:35 +0800
- To: Qebui Nehebkau <qebui.nehebkau+whatwg@gmail.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>
> > (Ideally, by the way, we would bake cache expiration and any other > relevant response header metadata into the archive format. Of course, > this puts the onus on the browser to decide whether to send a separate > request for a particular resource in case it has changed, not on the > server to know and supply the new version - but I think this is a > better way to do things, personally.) I'm not sure I understand fully what you mean. I guess the suggested solution is an archive format? In most/all cache solution the server needs to handle etag and invalidate caches. The client could handle the expires, which the suggested solution does. On Fri, Mar 14, 2014 at 3:39 AM, Qebui Nehebkau < qebui.nehebkau+whatwg@gmail.com> wrote: > On Thu, Mar 13, 2014 at 6:57 AM, Tingan Ho <tingan87@gmail.com> wrote: > > Thought and feedback is welcomed > > Surely it would be better to send an archive file containing the > resources the server expects the client to need, employing the Accept > header to decide whether to do so (ie, in order to request only the > lone file without whatever else the server feels should go along, the > client should exclude archives from the acceptable types), &c.? > > I suppose it is possible that some intermediate caches may handle this > poorly, but, if so, that's fundamentally just bad design on the part > of those caches; I really think we just have to accept it and do the > sensible thing anyway. > > (Ideally, by the way, we would bake cache expiration and any other > relevant response header metadata into the archive format. Of course, > this puts the onus on the browser to decide whether to send a separate > request for a particular resource in case it has changed, not on the > server to know and supply the new version - but I think this is a > better way to do things, personally.) > -- Sincerely, Tingan Ho
Received on Friday, 14 March 2014 04:03:06 UTC