Hacker News Reader

Comment by nateberkopec | Hacker News Reader

Why does HTTP3 still support server push? When Chrome dropped it from their HTTP/2 implementation, I thought it was dead.

Cloudflare has also said they’re not implementing server push in their HTTP/3 support and will instead encourage Early Hints.

View on HN

Co-chair of the QUIC WG here. Early in the process, we decided it was important that HTTP/3 provide parity with HTTP/2. That helps application developers to migrate back and forth between versions with less friction. So we include features of bidirectional stream multiplexing, request/response stream cancellation, server push, header compression, and graceful connection closure.

Some of those are more optional than others i.e. Server Push. Whether implementations choose to support a feature or not, at least the IETF maintain the close parity at the protocol level.

Stream prioritization is a different matter. That was very tricky in HTTP/3 [1], and through the process we designed Extensible Priorities, which is simpler and works over both H2 and H3. That was published today also as RFC 9218[2].

[1] https://blog.cloudflare.com/adopting-a-new-approach-to-http-...

[2] https://www.rfc-editor.org/info/rfc9218

Edit: typo fix

Dumb question/super out of the loop.

QUIC/HTTP2/HTTP3/whatever, are my options still only base64-encoded (in case of binary messages) server-side events and/or websockets, or is there some kind of bi-directional HTTP2/HTTP3 thing yet that's adoptable + usable?

It's more of a matter of libraries and implementations than of the standard. In ALL versions of HTTP, the request and response bodies are potentially infinite binary data streams. You can send a large file in them, but also e.g. lots of invidiual events with pauses in between (as e.g. utilized in gRPC streaming and for SSE).

However client and server libraries might not allow to access bodies as a stream, and would only provide a full response. That is e.g. the case for browser APIs, where the only APIs to access the response body either allowed to wait for the complete data to have arrived or allowed to parse SSE format. Newer APIs - e.g. fetch with ReadableStream [1] would lift some of those restrictions.

[1] https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...

I don't understand why server push is in the standard but not Early Hints.

I saw some articles but seems both server side & client side support are lacking.

(I can be wrong)

At least I don't see early hint in Nginx...

103 Early Hints is RFC 8297. It defines a status code. Because status codes are an HTTP semantic, they are common across all HTTP/1.1, HTTP/2, and HTTP/3. There's nothing special that needs to be done from a specification perspective, early hints _can_ work on any version. Whether implementations support that is a slightly different matter.

FYI early hints support is coming to Go, so it's possible that Caddy will gain support for it in a while (it'll need Caddy to have Go 1.19 as minimum so it's still like about a year or so away probably)

So the golang quic module will need to implement it .

I have been using quic with golang and am looking forward to trying this out

Reply on news.ycombinator.com