Original text:
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in <del> association with a previous client-initiated request.  This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. </del>  A client can request that server push be disabled, though this is negotiated for each hop independently.  The SETTINGS_ENABLE_PUSH

Reviewer comments:
NAME says: It's not very widely used and many implementations either don't support it at all or don't support it in a way that improves end-user performance. This sparked a lively discussion at URL
I’m open to dropping this, but I think the case needs to be be made for what the burden is. It’s one of the easiest protocol features to just ignore: send SETTINGSENABLEPUSH=0 and then you can remove all awareness of PUSH_PROMISE from your state machine altogether.
Crazy thought: what if we made part of HTTP/2, and then factored server push into an extension?
Or what if we minted a new ALPN () and flipped the default value?
Or left it as is, since it is used outside of browsers. The browsers have an API problem that has not been solved, and it is unlikely that push will be effective there (except as a competitor to inlining) until that changes.
I have no particular objection to flipping the default under a new ALPN. Factoring it out to an extension is harder, but not impossible -- it's pretty embedded in the state machine, but we might be able to abstract that away. Removing it entirely seems challenging for several reasons. The purely process one is that RFC 8030 requires Server Push, and removing a feature used by a Standards Track RFC presumably requires deprecating that other RFC.
I should note that my preferred outcome here is "do nothing". I'm just spitballing ideas.
Flipping the default if we mint a new alpn seems sensible based on the comments above. This would also align with HTTP/3. Moving it to an extension is probably more work than it's worth, I'll admit. I wasn't aware of RFC 8030. Is that an actively used RFC?
Push is being used outside of browsers (curl supports it, once implemented for a particular company that uses/used it pretty widely across the globe), although I suspect that outside of browsers we also have no real means of figuring out exactly how much or little. Saying "do it in extension" will probably equal killing it, but I also think that removing it from the spec is more work than its worth and just toggling the default seems like the best middle ground.
We may want to be a bit relaxed about flipping the default. As the setting is client-only the default value never really exists on a connection: the client’s SETTINGS are the first frame it sends. The reason to flip the default is to save 6 bytes on all connections. This is not nothing, but it’s not a huge win either.
I agree that it's not worth changing anything here, except if we want to be sure to cause some confusion between implementations. The first frame sent is the one indicating support (or lack thereof) by the client. Maybe we should just add a paragraph in the PUSH section mentioning that 5 years after the relerase, PUSH has still got very low adoption among implementations and should not be assumed as a granted feature for protocols sitting on top of H2.
I think NAME suggestion of adding a note about deployment and not expecting wide support would be very helpful. My biggest concern with keeping it in the spec is that people will expect it's widely supported and its use is recommended for most use cases.
Feeling here seems to be supportive of no normative changes, but possibly some editorial additions clarifying the status of push. If you feel otherwise, please say so soon.
SGTM. FYI, Chrome is expected to drop support for HTTP/2 server push in the= near future and has never implemented push for HTTP/3.
NAME has it been announced somewhere? I can't find it.
Several popular web frameworks actively use Server Push including (mostly for assets) and (for API relations). Server Push is also (currently) supported by most browsers as well as by NGINX, Apache and Caddy. On the APIs field, , which aims to replace GraphQL-like document compounding is also gaining adoption, and rely on Server Push (even if it can fallback on preload Link headers and Early Hints too). I just published a benchmark showing how useful Server Push is for the specific use case of web APIs. Under certain conditions, relying on it can be 4x times faster than using compound documents: URL As pointed in martinthomson/http2v2, for these use cases, Server Push could be replaced by Early Hints or maybe by something using WebTransport, but these specs aren't currently implemented while Server Push is broadly available. Removing support for Server Push in Chrome will hurt all this use case. What's really missing with HTTP/2 Server Push is a way to prevent pushing resources already stored by the client. could have been a solution, but the work on it looks stopped.
URL
NAME suggested calling out the current status: lack of support in browser APIs for push, pointy edges in the usage, and the limitations in the spread of its usage. I think this is a reasonable editorial change.
NAME to draft a document to encourage users to set the value to 0 by default and move on.
Discussed at Feb 2021 interim; intent to document concerns / caveats, recommend sending setting = 0. NAME to PR.
LGTMVery nice. Thanks Mark.

Revised text:
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in  <ins> association with a previous client-initiated request. Server push was designed to allow a server to improve client- perceived performance by predicting what requests will follow those that it receives, thereby removing a round trip for them.  For example, a request for HTML is often followed by requests for stylesheets and scripts referenced by that page.  When these requests are pushed, the client does not need to wait to receive the references to them in the HTML and issue separate requests. In practice, server push is difficult to use effectively, because it requires the server to correctly anticipate the additional requests the client will make, taking into account factors such as caching, content negotiation, and user behavior.  Errors in prediction can lead to performance degradation, due to the opportunity cost that the additional data on the wire represents.  In particular, pushing any significant amount of data can cause contention issues with more- important responses. </ins> A client can request that server push be disabled, though this is negotiated for each hop independently.  The SETTINGS_ENABLE_PUSH