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/httputil: ReverseProxy change conflicts with future ReverseProxy plans #23009

Closed
rsc opened this issue Dec 6, 2017 · 6 comments
Closed

Comments

@rsc
Copy link
Contributor

rsc commented Dec 6, 2017

CL 54030 makes the suspicious change that after

res, err := roundtripper.RoundTrip(...)

the error condition is now detected by res == nil instead of err != nil. That seems wrong. Commented more on the CL itself but we should resolve this one way or the other for Go 1.10.

@rsc rsc added this to the Go1.10 milestone Dec 6, 2017
@rsc
Copy link
Contributor Author

rsc commented Dec 6, 2017

I'm also not even convinced the main part of the change is correct. The docs for the ModifyResponse field say:

// ModifyResponse is an optional function that
// modifies the Response from the backend.
// If it returns an error, the proxy returns a StatusBadGateway error.

The whole point of CL 54030 is to now call ModifyResponse on a fake Response that is not from the backend. Why is that correct?

/cc @bradfitz @tombergan

@smasher164
Copy link
Member

smasher164 commented Dec 6, 2017

Replied on the CL, but you're correct in that err != nil should be used to construct the fake Response.

As to why the fake res not from the backend is constructed, ModifyResponse needs some way of mutating the res when it is nil. I assumed that the correct default response to construct was one that returned a StatusBadGateway error.

The change was intended to adapt ModifyResponse's current API to support the case when err != nil. A more robust change for this would be to add an api like http://golang.org/issue/22700 which allows the ErrorHandler to take advantage of the error value.

@rsc
Copy link
Contributor Author

rsc commented Dec 6, 2017

It seems to me that CL 54030 and CL 77410 have different, conflicting ideas of how to process a RoundTrip error. If we think that CL 77410 may be the right choice in Go 1.11, then it doesn't make sense to include CL 54030 in Go 1.10.

Given the uncertainty around the API decision here I suggest we revert CL 54030 for Go 1.10 and decide the API question in the next round without having painted ourselves into a corner.

@rsc rsc changed the title net/http/httputil: ReverseProxy change appears to assume res != nil => err == nil from RoundTrip net/http/httputil: ReverseProxy change conflicts with future ReverseProxy plans Dec 6, 2017
@smasher164
Copy link
Member

I am fine with that, especially considering that the ErrorHandler in CL 77410 is only called when err != nil. That means that ModifyResponse is only invoked on a successful response.

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/86435 mentions this issue: Revert "net/http/httputil: allow ReverseProxy to call ModifyResponse on failed requests"

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/86476 mentions this issue: doc/go1.10: remove ReverseProxy TODO

gopherbot pushed a commit that referenced this issue Jan 6, 2018
No longer needs to be done.

Updates #23009
Updates #21255

Change-Id: I78e9e29a923dc03dea89ff3a5bf60f2e0bd0c0aa
Reviewed-on: https://go-review.googlesource.com/86476
Reviewed-by: Ian Lance Taylor <iant@golang.org>
jasonwbarnett pushed a commit to jasonwbarnett/fileserver that referenced this issue Jul 11, 2018
…on failed requests"

This reverts commit https://golang.org/cl/54030

Reason for revert: to not paint ourselves into a corner.
See golang/go#23009

Fixes #23009
Updates #21255

Change-Id: I68caab078839b9d2bf645a7bbed8405a5a30cd22
Reviewed-on: https://go-review.googlesource.com/86435
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@golang golang locked and limited conversation to collaborators Jan 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants