net/http: support for the 103 status code

[dunglas]

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:

• HTTP/1: net/http: allow sending 1xx responses #42597
• HTTP/2: x/net/http2: allow sending 1xx responses net#96
• HTTP/3 (in lucas-clemente/quic-go): allow sending 1xx responses quic-go/quic-go#3047

[ianlancetaylor]

CC @neild @bradfitz

[rhysh]

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]

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

[gopherbot]

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

[dunglas]

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

[rhysh]

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]

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]

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

[rsc]

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