-
Notifications
You must be signed in to change notification settings - Fork 17.7k
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
Comments
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 That leaves the request for support in net/http/httputil. Is that right, @dunglas ? |
Exactly. I already have a working patch for net/http/httputil. I'll open a PR on Monday. |
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
Change https://go.dev/cl/409536 mentions this issue: |
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. |
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. |
Based on the discussion above, this proposal seems like a likely accept. |
No change in consensus, so accepted. 🎉 |
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
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
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
Change https://go.dev/cl/450515 mentions this issue: |
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>
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 callingResponseWriter.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 toWriteHeader()
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:
lucas-clemente/quic-go
): allow sending 1xx responses quic-go/quic-go#3047The text was updated successfully, but these errors were encountered: