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

[Martin Thomson <[e-mail]>]

Unlimited pushes in HTTP/2 was a bug, not a feature.  The concurrency limit might have applied in theory, but the ability to run the entire stream lifecycle without feedback meant that there was no limit in practice other than those imposed by TCP - on either promises or responses.

The important feature, which we retained, was the ability to decouple the stream limits and the number of promises.  That's why we have push IDs.  Assuming the client is configured for that, the separate limit on push promises ensures that promises can greatly exceed the number of active streams.  I think that is the ideal situation if the client is somehow resource-limited, so it can accept N promises and then receive M (<N) responses for those promises.

In other words, I see no reason to change the current design.  If this is the result of general antipathy toward server push, that's fine, but we're not in a stage of development where we can afford to make changes at such a fundamental level without serious impact on our schedule.  Besides, I'm not seeing a proposal here that would be anything less than a regression in some way.

If someone wants to contribute text that walks through some of the trade-offs inherent in setting different limits (whether that be streams, flow control, or push IDs) for people who might want to implement or deploy HTTP, that seems fine.  As this is highly context-dependent, it might be hard to avoid certain biases.  I certainly wouldn't want to block publication if such guidance were absent.

-- 
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-561458016