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

Closed
dunglas opened this issue Mar 24, 2022 · 10 comments
Closed

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

dunglas opened this issue Mar 24, 2022 · 10 comments

Comments

@dunglas
Copy link
Contributor

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

CC @neild @bradfitz

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

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

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

@dunglas
Copy link
Contributor Author

dunglas commented May 31, 2022

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

@rhysh
Copy link
Contributor

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 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 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 (old) Jun 1, 2022
@rsc rsc moved this from Likely Accept to Accepted in Proposals (old) Jun 8, 2022
@rsc
Copy link
Contributor

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 modified the milestones: Proposal, Backlog Jun 8, 2022
dunglas added a commit to dunglas/go that referenced this issue Jul 12, 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 added a commit to dunglas/go that referenced this issue Aug 8, 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
@dmitshur dmitshur modified the milestones: Backlog, Go1.20 Aug 15, 2022
dunglas added a commit to dunglas/go that referenced this issue Aug 30, 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
@gopherbot
Copy link

Change https://go.dev/cl/450515 mentions this issue: doc/go1.20: add release notes for net/http and net/http/httputil

gopherbot pushed a commit that referenced this issue Nov 15, 2022
For #41773
For #41773
For #50465
For #51914
For #53002
For #53896
For #53960
For #54136
For #54299

Change-Id: I729d5eafc1940d5706f980882a08ece1f69bb42c
Reviewed-on: https://go-review.googlesource.com/c/go/+/450515
Auto-Submit: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Damien Neil <dneil@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
@golang golang locked and limited conversation to collaborators Nov 15, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

6 participants