3 ms·

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

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.

PikachuEXE 4y ago
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...
- simmervigor 4y ago
  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.
- francislavoie 4y ago
  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)
  - gedw99 4y ago
    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
simmervigor 4y ago
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-prioritization/ https://blog.cloudflare.com/adopting-a-new-approach-to-http-... [2] https://www.rfc-editor.org/info/rfc9218 https://www.rfc-editor.org/info/rfc9218 Edit: typo fix
MuffinFlavored 4y ago
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?
- Matthias247 4y ago
  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/Using_readable_streams https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...
  - deleted 4y ago
    [deleted]

PikachuEXE 4y ago

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

simmervigor 4y ago
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.
francislavoie 4y ago
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)
- gedw99 4y ago
  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

simmervigor 4y ago

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-prioritization/ https://blog.cloudflare.com/adopting-a-new-approach-to-http-... [2] https://www.rfc-editor.org/info/rfc9218 https://www.rfc-editor.org/info/rfc9218 Edit: typo fix

MuffinFlavored 4y ago

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?

Matthias247 4y ago
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/Using_readable_streams https://developer.mozilla.org/en-US/docs/Web/API/Streams_API...
- deleted 4y ago
  [deleted]