Re: Server Push and Caching

[Tom Bergan <[e-mail]>]

Thanks for starting this thread. I have questions about the following quote
from the RFC:

On Tue, Aug 23, 2016 at 9:50 PM, Mark Nottingham <[e-mail]> wrote:
>
> RFC7540, Section 8.2 says:
>
> > Pushed responses are considered successfully validated on the origin
> server (e.g., if the "no-cache" cache response directive is present
> (RFC7234, Section 5.2.2)) while the stream identified by the promised
> stream ID is still open.
>
> This implies that, while that stream is open, the pushed response can be
> used by the cache, even when it contains any (or all) of the following
> cache directives:
>
> * max-age=0
> * no-cache
> * s-maxage=0 (for shared caches)
>
> The underlying principle here is that while the response stream is still
> open, it's semantically equivalent to a "normal" response to a just-issued
> request; it would be senseless to require it to be immediately revalidated
> before handing it to the application for use.
>
> The cache can also store the response, but once the stream is closed, if
> that response is stale -- either because of the presence of one of the
> directives above, or some combination of `Expires`, `Age`, `Date`, and
> `Cache-Control`, it will need to be revalidated before use.
>

Chrome does not implement this. Some discussion starting here:
https://groups.google.com/a/chromium.org/d/msg/net-dev/CCNLknIbzYs/hdMw8qYRAgAJ

I can see why the above sentence was added to the RFC -- there needs to be
some semantics for pushing immediately-stale responses, and the above
sentence seems like reasonable semantics at first glance. However, I'm
concerned that these semantics are not implementable in practice. On the
client side, the user agent will typically store pushed responses in a side
cache until they are matched with an actual request. On the server side,
the server will send END_STREAM with the last DATA frame in the pushed
response. This creates a race where the client may see END_STREAM before
it's done enough processing to realize that it needs the pushed response.
For example, consider cases where the server tries to push an "inlined"
resource, but happens to push the inlined resource before the referencing
HTML tag.

A server might try to avoid this race by holding the stream open, but how
long should it keep the stream open? There's no way for the client to
signal that a pushed response has matched a request. Further, the client
cannot know (in general) if the server is holding a stream open to preserve
validity of the no-cache response or because it's slow to send the final
DATA frames.

I'm not sure what the right semantics are. One option is to allow the user
agent optional leeway to consider the response validated for a longer
period, perhaps using a timeout as Chrome does. Or, perhaps, a browser
might consider a pushed response validated for the duration of the parent
navigation event. Thoughts?