net/http: add Request.LocalAddr

[gopherbot]

by joijoi360:

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1.http://play.golang.org/p/-DIhMc_XjT
2.http://play.golang.org/p/55V_nyuKPR(There is revised code net/http/server.go)
3.http://play.golang.org/p/jroO70Cno8(There is revised code net/http/request.go)

What is the expected output?
Request.LocalAddr

What do you see instead?
The LocalAddr isn't here.

Which compiler are you using (5g, 6g, 8g, gccgo)?
gccgo

Which operating system are you using?
os x 10.9

Which version are you using?  (run 'go version')
go version go1.1.2 darwin/amd64

Please provide any additional information below.
because the network line and the operators do IP,there isn't LocalAddr in Rep
resource.requiring different

[gopherbot]

Comment 1 by joijoi360:

1.http://play.golang.org/p/-DIhMc_XjT
2.http://play.golang.org/p/55V_nyuKPR  (There is revised code net/http/server.go)
3.http://play.golang.org/p/jroO70Cno8  (There is revised code net/http/request.go)

[gopherbot]

Comment 2 by vslene:

LGTM. I think this means need a small enhanced. Add a new variable LocalAddr to
http.Request. When bind *:80, it can be used detect the http request which net address .

[rsc]

Comment 3:

Labels changed: added go1.3maybe.

[dsymonds]

Comment 4:

Labels changed: added priority-later, feature, packagechange, removed priority-triage.

[rsc]

Comment 5:

Labels changed: added release-none, removed go1.3maybe.

[rsc]

Comment 6:

Labels changed: added repo-main.

[davecheney]

Comment 7:

Marking this as long term, I haven't seen a request for this in close to a year so
further justification would need to be provided.

Status changed to LongTerm.

[gopherbot]

Comment 8 by luke@hydrantlabs.org:

I am in need of this feature. In fact, I am currently running the same server bound to
different ips to get around this issue.

[davecheney]

Comment 9:

Luke, please write to golang-dev and explain why you need this feature, and specifically
what you cannot do today that justifies its addition.

[bradfitz]

Comment 10:

Yeah, it seems like there are plenty of ways to do this already with a wrapper for
people who care (two people?). I'm inclined to say WontFix as I don't think it justifies
the API surface increase, nor the memory/CPU increase.

[gopherbot]

Comment 11 by sajal83:

I need this as well. I have a usecase where I want to return (very) slightly modified
response based on which IP the client used to connect to. And for a particular reason I
would like to use the same process to serve all IP. I could perhaps get away with
registering multiple servers each listening to a different IP and using custom handler
for each server... but it sounds ugly.

[fiorix]

I also need this feature.

[bradfitz]

Sorry, I'm going to close this issue without action. There are few enough cases where this is required that I don't think it's worth complicating the net/http package API and making the Request struct larger.

There's an easy enough workaround: run a Server on each interface with a Handler that sets a magic HTTP request header and then delegates to a shared root handler.

[fiorix]

Well, the reason I needed this is to detect loops in a proxy. Using ConnState works for me.

[staunch]

Listening on 0.0.0.0 and then using LocalAddr for ACLs/partitioning traffic is an extremely efficient, convenient, and common pattern among unix servers. It's a real shame net/http can't do it. In my case, my program listens on hundreds of dynamic IPs and it's a real problem not having access to LocalAddr. Just another +1. Thanks for all your hard work.

[gopherbot]

CL https://golang.org/cl/22672 mentions this issue.

[SpComb]

With Go 1.7, there is a httpRequest.Context().Value(http.LocalAddrContextKey).(net.Addr), but this value is always the same listen address as passed to http.ListenAndServe. So for a server having multiple interfaces/local addresses, and starting a Go http server on :8000, it will always be [::]:8000, regardless of which server address the client connected to.

That makes this feature somewhat useless.

I think the desired behavior would be to return the actual net.Conn.LocalAddr() for the accepted connection. This would return different values for clients connecting to different local addresses on the same server having a single http.Sever listening on 0.0.0.0/::.

Workaround

Hijack the http.ResponseWriter and then get at the conn.LocalAddr()

[bradfitz]

@SpComb, thanks for the note, but in general comments on closed issues are where action items go to die. I've opened #18686 so this can actually be tracked.