W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2014

Re: [whatwg] More effective model for handling resources

From: Tingan Ho <tingan87@gmail.com>
Date: Fri, 14 Mar 2014 12:02:35 +0800
Message-ID: <CAOr4atVpza1kqG7vAocWT3uoOZQfegYNHs6SbtNyiBeTCXQHMQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:17 UTC