Remove the ability to receive, keep in memory, and use HTTP/2 and gQUIC push streams sent by the server. Send SETTINGS_ENABLE_PUSH = 0 at the beginning of every HTTP/2 and gQUIC connection to request that servers not send them.
https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY?pli=1
Should we consider deprecating push and maybe skip it for http3?
@jasnell @nodejs/web-server-frameworks
I think pushStreams are or might be used by GRPC.
Eventually deprecation will make sense, but for now we should wait. There's no reason to rush. There is code in the wild using push and there are use cases outside of browsers.
I'm mostly interested in whether we should put effort into adding push to future API work we are doing over at @nodejs/web-server-frameworks. I think push was one of the things that were causing some difficulties with preferred API.
For http (2 or 3), I think the future lack of browser support for push is going to end up superseding anything else -- the other possible use cases are interesting but will be completely overshadowed and limited by the lack of browser support. Moving forward with QUIC, those use cases can be addressed using server-initiated QUIC streams, independent of what http/3 specifically allows so I'm thinking that we'd be fine there. So, at this point, I'd say it's likely best to table any support for http push in future API design work.
Most helpful comment
For http (2 or 3), I think the future lack of browser support for push is going to end up superseding anything else -- the other possible use cases are interesting but will be completely overshadowed and limited by the lack of browser support. Moving forward with QUIC, those use cases can be addressed using server-initiated QUIC streams, independent of what http/3 specifically allows so I'm thinking that we'd be fine there. So, at this point, I'd say it's likely best to table any support for http push in future API design work.