- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 26 Aug 2014 14:22:53 -0700
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
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. ....Roy
Received on Tuesday, 26 August 2014 21:23:17 UTC