Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sudheesh001 opened this issue Sep 17, 2022 · 6 comments
Open
Labels
Milestone

Comments

@sudheesh001
Copy link

sudheesh001 commented Sep 17, 2022

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

@gopherbot gopherbot added this to the Proposal milestone Sep 17, 2022
@seankhliao
Copy link
Member

seankhliao commented Sep 17, 2022

cc @neild

@neild
Copy link
Contributor

neild commented Sep 19, 2022

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
Copy link

jhoyla commented Sep 20, 2022

@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
Copy link
Contributor

neild commented Sep 20, 2022

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
Copy link

jhoyla commented Sep 21, 2022

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
Copy link
Contributor

rsc commented Sep 28, 2022

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: Active
Development

No branches or pull requests

6 participants