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

net/http: support for the 103 status code #51914

Open
dunglas opened this issue Mar 24, 2022 · 9 comments · May be fixed by #53164
Open

net/http: support for the 103 status code #51914

dunglas opened this issue Mar 24, 2022 · 9 comments · May be fixed by #53164

Comments

@dunglas
Copy link
Contributor

@dunglas dunglas commented Mar 24, 2022

Currently, it's not possible to send informational HTTP responses with, for example, the 103 Early Hints or 102 Processing status codes.

Using Early Hints is proposed as a (partial) alternative to Server Push, which is going to be removed from Chrome.

Chrome 95 added experimental support for the 103 status code (currently behind a flag). Support is being implemented in Firefox. Fastly and Google are also running a joint experiment to measure real-life benefits of this new status code.

I propose to change the API of net/http to allow calling ResponseWriter.WriteHeader() multiple times in order to send informational responses before the final one. In conformance with RFC 8297, if the status code is 103 the current content of the header map will also be sent. Its content will not be removed after the call to WriteHeader() because the headers must also be included in the final response.

I also propose adding support for 103 responses to net/http/httputil. I suggest introducing a new exported field, ReverseProxy.Forward103Responses, to enable this feature (I think that forwarding 103 responses should be opt-in, as it may cause compatibility issues with some legacy software).

I already crafted the patch implementing this proposal for HTTP/1, HTTP/2, and HTTP/3. Patches for HTTP/1 and 2 have been reviewed by @bradfitz. The one for HTTP/3 is already merged in lucas-clemente/quic-go.

Related patches:

@gopherbot gopherbot added this to the Proposal milestone Mar 24, 2022
@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 24, 2022

CC @neild @bradfitz

@ianlancetaylor ianlancetaylor added this to Incoming in Proposals Mar 24, 2022
@rhysh
Copy link
Contributor

@rhysh rhysh commented May 26, 2022

It looks like the changes to implement this in net/http have been merged, so are on track to be part of the Go 1.19 release.

For HTTP/1 in 770e0e5
For HTTP/2 in golang/net@9564170, which per b2ae2f5 seems to have been re-bundled into net/http.

That leaves the request for support in net/http/httputil. Is that right, @dunglas ?

@dunglas
Copy link
Contributor Author

@dunglas dunglas commented May 27, 2022

Exactly. I already have a working patch for net/http/httputil. I'll open a PR on Monday.

dunglas added a commit to dunglas/go that referenced this issue May 31, 2022
Support for 1xx responses has recently been merged in
net/http (golang#42597).

As discussed in this CL
(https://go-review.googlesource.com/c/go/+/269997/comments/1ff70bef_c25a829a),
support for forwarding 1xx responses in ReverseProxy has been extracted
in this separate patch.

According to RFC 7231, "a proxy MUST forward 1xx responses unless the
proxy itself requested the generation of the 1xx response".
Consequently, all received 1xx responses are automatically forwarded as long as the
underlying transport supports ClientTrace.Got1xxResponse.

Fixes golang#26088
Fixes golang#51914
@dunglas dunglas linked a pull request May 31, 2022 that will close this issue
@gopherbot
Copy link

@gopherbot gopherbot commented May 31, 2022

Change https://go.dev/cl/409536 mentions this issue: net/http: reverseproxy: forward 1xx responses

@dunglas
Copy link
Contributor Author

@dunglas dunglas commented May 31, 2022

@rhysh I'm a bit late but here is the last patch #53164.

@rhysh
Copy link
Contributor

@rhysh rhysh commented May 31, 2022

Hi @dunglas , I'm interested in net/http but I'm not the decider on what goes in. Per https://dev.golang.org/owners, that's @neild .

Apologies if you're familiar with all this already, but I wanted to make sure you know about Go's release cycle (https://github.com/golang/go/wiki/Go-Release-Cycle), which entered the Go 1.19 release freeze around May 16 (https://groups.google.com/g/golang-dev/c/EDstQLuReWE/m/aQC55F0hBAAJ). It's possible that the remaining change(s) would need a freeze exception, which the wiki page describes. The at-golang/release team would be able to clarify how this interacts with the freeze and the proposal process.

@rsc
Copy link
Contributor

@rsc rsc commented Jun 1, 2022

Sounds like the net/http changes have already landed, and people are generally in favor of the support for the 103 status code. (Maybe we should have waited, but so be it.)

As far as reverseproxy, that code can be forked if necessary (unlike net/http), so we should probably wait on that one.

Going to mark this "likely accept" and have it cover just the net/http changes, so it can appear in the minutes in case anyone objects to 103 support in Go 1.19.

@rsc
Copy link
Contributor

@rsc rsc commented Jun 1, 2022

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

@rsc rsc moved this from Incoming to Likely Accept in Proposals Jun 1, 2022
@rsc rsc moved this from Likely Accept to Accepted in Proposals Jun 8, 2022
@rsc
Copy link
Contributor

@rsc rsc commented Jun 8, 2022

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

@rsc rsc changed the title proposal: net/http: support for the 103 status code net/http: support for the 103 status code Jun 8, 2022
@rsc rsc removed this from the Proposal milestone Jun 8, 2022
@rsc rsc added this to the Backlog milestone Jun 8, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Proposals
Accepted
Development

Successfully merging a pull request may close this issue.

5 participants