W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Push and Caching

From: Roy T. Fielding <fielding@gbiv.com>
Date: Tue, 26 Aug 2014 14:22:53 -0700
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <6C31ED5C-2609-40BD-B6DA-5DCA59BB3443@gbiv.com>
To: Martin Thomson <martin.thomson@gmail.com>
On Aug 26, 2014, at 2:14 PM, Martin Thomson wrote:

> On 26 August 2014 12:05, Roy T. Fielding <fielding@gbiv.com> wrote:
>> I would expect them to push another.  Isn't that sufficient?
> It might be.  Though you have to accept that the opportunity to push
> might not reappear.
>>> I'm a little leery of implying something about regular response
>>> validity in this context.  I couldn't find anything concrete in RFC
>>> 7234 about the period over which a response can be considered valid
>>> once it arrives at the client.  The best I could find was: "A cache
>>> need not validate a response that merely became stale in transit."
>> Hmm, that effectively has the same meaning as what I proposed -- a
>> pushed response can be considered in-transit until it is used.
> If that is the case, that's writing a blank check.  Practically
> speaking, that's how people use responses anyway: they use them when
> they are ready to (which is usually as quickly as possible :).  The
> point being not to prevent use, but to discourage reuse.
> So if you are ok with that, then I am.  I still don't think that
> binding to the connection lifetime is particularly useful though.

Yes, it was just the most convenient lifetime I could think of ...
"used at least once" is probably the minimum.  I would be surprised
if anyone pushed something that was not "good until replaced",
and I suspect UAs will use the configured default of "check at most
once in 24 hours or after restart".  But that's just guessing.

Received on Tuesday, 26 August 2014 21:23:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC