- From: Mike Bishop <Michael.Bishop@microsoft.com>
- Date: Fri, 22 Aug 2014 18:56:33 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: Mark Nottingham <mnot@mnot.net>, Patrick McManus <mcmanus@ducksong.com>, William Chow <wchow@mobolize.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
Received on Friday, 22 August 2014 18:57:13 UTC