[quicwg/base-drafts] Pushes "associated" with parent stream(s) (#3334)

[Mike Bishop <[e-mail]>]

@RyanAtGoogle and I had an enlightening discussion on #3309, which highlighted a philosophical difference in our view of how push works, the filters through which we read RFC 7540, and the purpose of PUSH_PROMISE on multiple streams.  It might be worth expanding the text in HTTP/3 to give the reader the sense of both viewpoints, especially since disagreement between server and client implementations might have some sharp edges.

RFC 7540 says:
> Pushed responses are always associated with an explicit request from the client.  The PUSH_PROMISE frames sent by the server are sent on that explicit request's stream.

This "association" is only leveraged one other place in H2 directly; the push response is dependent on the associated stream for priority purposes.  What does it mean to be "associated"?

- One implementation path ignores it totally, keeping a global cache of pending pushes.  In this viewpoint, the purpose of PUSH_PROMISE on multiple streams is to make sure that *some* PUSH_PROMISE arrives before a reference to a resource that's being pushed, so the client knows it's already coming and can suppress requests.  Subsequent PUSH_PROMISEs are entirely superfluous.
- Another view says that pushes are tied to requests which are related, and might not be applicable to a request for that resource made in a different context (different navigations, different clients of a proxy, etc.); this is especially true if the response is not cacheable.  In this viewpoint, the purpose of PUSH_PROMISE/DUPLICATE_PUSH is to signal which request contexts the pushed response is applicable to.

These views are mostly identical if the response is cacheable or has appropriate Vary headers set, but they're subtly different views of the system.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3334