-
Notifications
You must be signed in to change notification settings - Fork 17.5k
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: Client should scope cookie to Request.Host before Request.URL #38988
Comments
@colinclerk Thanks for this bug report. There might be a real issue here. From https://tools.ietf.org/html/rfc6265#section-2.3
According to https://tools.ietf.org/html/rfc6265#section-5.4 domain matching works on the request-host (with the unclear definition above). On the other hand: curl seems to use the Host header.... |
@vdobler What is the intended purpose of allowing outbound requests where r.Host != r.URL.Host? When I issue outbound requests where r.Host != r.URL.Host, my intent is to mimic DNS resolution:
Having this separation allows me to mimic a server that has multiple hosts pointed at it, and generate different responses depending on the Host. Since I'm imagining r.Host is what my user has in their address bar, it's also where I'm expecting cookies to be set. But maybe I'm thinking about this all wrong? Another exercise that might be helpful is to think about things from the server's perspective. r.URL.Host doesn't exist on the server, so when it issues SetCookie it expects the cookie to be set on the incoming request's r.Host. That's not what happens when using Client and setting r.Host manually: |
I just ran into this issue. It seems pretty clear to me that a new Say my application does routing based on subdomain, and I'm testing with
I want any request to connect to I still need to let the server know what domain is being requested, and so I set The request is issued, and everything looks like it works fine. Except cookies are written with When doing a subsequent request for Currently the only workaround is to maintain your own cookiejar, and load/store the cookies before and after the request manually. Is this something the net/http maintainers would welcome a patch for? What would fixing the behavior mean for the compatibility promise? It seems to me that leaking data from one domain to another is a clear security concern. It doesn't seem like this is something that would be pervasive in a production application. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Created a
httptest.Server
with a handler that sets a cookie, then issued a request from ahttp.Client
with a customHost
field.https://play.golang.org/p/78mh9ZwYI_t
What did you expect to see?
I expected to see the cookie scoped to the Host field.
What did you see instead?
The cookie was scoped to httptest.Server.URL
I was seeing unexpected cookie behavior while testing and I believe this is the root of it:
go/src/net/http/client.go
Lines 170 to 186 in 57e32c4
Instead of the client always using
req.URL
for the cookie jar, I believe it should first look atreq.Host
, thenreq.Header.Get("Host")
, and then finallyreq.URL
.I think this would be consistent with the behavior of Request.Write described on the Request struct:
go/src/net/http/request.go
Lines 231 to 235 in 57e32c4
The text was updated successfully, but these errors were encountered: