Re: [quicwg/base-drafts] Why are there two ways of associating push with requests? (#3275)

[Kazuho Oku <[e-mail]>]

@LPardue @martinthomson Apologies for not chiming in to the discussion in #1864.

@martinthomson 
> One advantage of the current design is the ability to exercise flexibility. There is nothing preventing someone from pushing the same thing twice in this design, thereby avoiding DUPLICATE_PUSH.

I do not think that is something that a server should do, as it would mean that the server would be pushing not only the headers but the entire response multiple times to the client.

@RyanAtGoogle 
> But unless all user-agents do the same thing it means that servers can't rely on particular client-side behavior which is a real bummer. Push is already hard enough to get right (in both clients and servers) it seems like adding more rough edges runs the risk of resulting in push being disabled/removed from some implementations. (I believe Brad Lassey from Chrome presented at IETF 102 data which suggested doing exactly this)

+1

I can see @martinthomson's view that push is feature that the server might use, and therefore that it can be complicated. But as the number of traps increases in the protocol, it becomes more likely that some stacks (or some combination of client- and server-side stacks) would have edge cases that lead to worse performance when push is used.

In HTTP/2, push is a feature that is often misused, leading to performance degradation, even though the protocol itself is designed correctly. The situation would become worse in HTTP/3, if we introduce uncertain behaviors to the protocol design (i.e., some clients might not block on DUPLICATE_PUSH).

-- 
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/3275#issuecomment-559292834