- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 25 Aug 2014 10:01:01 +1000
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, Patrick McManus <mcmanus@ducksong.com>, William Chow <wchow@mobolize.com>, HTTP Working Group <ietf-http-wg@w3.org>
I made those requirements because we're really stepping outside the bounds of the traditional HTTP caching model here, although I do see Gabriel's point. I'm happy if the editor wants to adjust. Cheers, On 23 Aug 2014, at 4:56 am, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > Actually, Gabriel pointed out that since you can't validate the MAY from external observation, it should be non-normative, and the MUST NOT (presumably) duplicates an existing requirement that uncacheable things not be cached. > > -----Original Message----- > From: Martin Thomson [mailto:martin.thomson@gmail.com] > Sent: Friday, August 22, 2014 10:58 AM > To: Mike Bishop > Cc: Mark Nottingham; Patrick McManus; William Chow; HTTP Working Group > Subject: Re: Push and Caching > > On 22 August 2014 10:30, Mike Bishop <Michael.Bishop@microsoft.com> wrote: >> "While the stream identified by the promised stream ID is still open" - meaning that as long as the client has asked for it before the server has finished sending it? That's a fairly small amount of time, particularly if the resource is very small, but sounds like a good starting point. > > I'm sure that clients can fail to notice the END_STREAM flag for as long as they need to in order to ensure that the various races resolve in the right way... > > Trying to determine how long the window is after END_STREAM arrives in which clients can consider the response validated is nasty. I don't know how to finesse this other than turning a blind eye to small violations, the likes of which you (and Firefox too) are committing in this regard. -- Mark Nottingham https://www.mnot.net/
Received on Monday, 25 August 2014 00:01:32 UTC