proposal: net/http: Enabling support for HTTP/2 ORIGIN Frames RFC 8336

[sudheesh001]

This proposal request extends the current implementation of HTTP/2 in net/http to support ORIGIN Frames standardised as RFC 8336. The ORIGIN Frames for HTTP/2 is an extension allowing web servers to give explicit indications to the clients about other hostnames that are reachable on the existing connection and are sent in the connection stream 0. As far as we're aware, no public ORIGIN Frame implementation exists.

The proposal involves the addition for a new "ORIGIN" FrameType for FrameOrigin with the value 0xC to the HTTP/2 frame type registry along with associated frame parsing and creation methods. Changes also would introduce a new interface for OriginPusher implemented by ResponseWriters to support pushing HTTP/2 ORIGIN Frames.

Recent experiments from Cloudflare (appearing at ACM Internet Measurement Conference, October 2022) indicate that the adoption of ORIGIN Frames could provide increased privacy by coalescing connections, without increasing operational complexities needed to help clients coalesce their connections by manipulating name-to-IP address mappings.

We are happy and would like to engage with the golang community to discuss, determine interest in this proposal, and then if or how best to upstream changes. Thanks.

@marwanfayed @jhoyla @Lekensteyn @SulemanAhmadd

---

Edit: We currently maintain a fork of our changes at go-originframe and net-originframe

[seankhliao]

cc @neild

[neild]

As far as we're aware, no public ORIGIN Frame implementation exists.

If nothing supports ORIGIN frames, what would use this? Just Go clients talking to Go servers?

Supporting draft RFCs that nobody else implements isn't really a goal for the standard library.

[jhoyla]

@neild As far as we know there are no server implementations, but Firefox supports ORIGIN Frames, and has done for a while. I think @sudheesh001 's comment was in reference to server-side support.
Further, RFC 8336 is not a draft specification, but a full RFC.

[neild]

So far as I can tell, the latest version of RFC 8336 is draft-ietf-httpbis-origin-frame-06. Maybe I'm missing something.

Firefox supporting ORIGIN frames is something, but if no servers or other browsers support them, I don't know how meaningful that is.

[jhoyla]

These are great questions. First on status and support, then importance.

RFC 8336 was published in 2018. It is a standard that has gained full IETF consensus (see the datatracker). This year, HTTP/3 was published as RFC 9114. The HTTP WG is expected to declare consensus on the definition of ORIGIN frame for HTTP/3 by the end of the year.

On the client-side Firefox already has full support. On the server-side, Cloudflare has a working implementation (see net/http2 and net/http changes), as described in this paper and is investigating its use on wider scale.

The main benefits of ORIGIN Frame are:

1. It improves client privacy, because fewer SNIs are leaked to the network, see Section 6.2.
2. It opens up scheduling opportunities at both endpoints that will not be violated by competing path characteristics, see Section 6.1.
3. It's much easier to implement / support coalescing on the server side without having to think about IP addresses (which creates risk of having to synchronise multiple systems and potentially means having to violate their SLAs), see Section 5.3.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[rsc]

The HTTP WG is expected to declare consensus on the definition of ORIGIN frame for HTTP/3 by the end of the year.

It sounds like we should wait for this consensus on the definition of ORIGIN frames before we add support for them. Everything sounds a bit up in the air right now.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group