Re: Push and Caching

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.


On 23 Aug 2014, at 4:56 am, Mike Bishop <> 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 [] 
> 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 <> 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

Received on Monday, 25 August 2014 00:01:32 UTC