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.