caddyhttp: add http.request.local{,.host,.port} placeholder

[emilylange]

This is the counterpart of http.request.remote{,.host,.port}.

http.request.remote operates on the remote client's address, while
http.request.local operates on the address the connection arrived on.

Take the following example:

• Caddy serving on 203.0.113.1:80
• Client on 203.0.113.2

http.request.remote.host would return 203.0.113.2 (client IP)

http.request.local.host would return 203.0.113.1 (server IP)
http.request.local.port would return 80 (server port)

I find this helpful for debugging setups with multiple servers and/or multiple network paths (multiple IPs, AnyIP, Anycast).

A version of this using respond http.request.local is currently deployed at https://localip.geklaute.cloud/ (but might not be there forever).
I successfully tested http versions 1.1, 2 and 3 with curl on that url.

cc @networkException

---

The implementation is heavily based on http.request.remote.

But I would like to comment on two code paths that I find a bit confusing:

caddy/modules/caddyhttp/replacer.go

Lines 130 to 135 in e65b97f

	case "http.request.remote.port":
	_, port, _ := net.SplitHostPort(req.RemoteAddr)
	if portNum, err := strconv.Atoi(port); err == nil {
	return portNum, true
	}
	return port, true

For http.request.remote.port we try to cast the port from net.SplitHostPort as integer.
But if the string -> int conversion fails, we return it as string.
I cannot think of a case where strconv.Atoi(port) would ever fail.
And if it actually does, I don't think returning it as string it a good fallback.
I would argue if the conversion fails, something went very wrong.

Similarly, for http.request.remote.host:

caddy/modules/caddyhttp/replacer.go

Lines 124 to 129 in e65b97f

	case "http.request.remote.host":
	host, _, err := net.SplitHostPort(req.RemoteAddr)
	if err != nil {
	return req.RemoteAddr, true
	}
	return host, true

If net.SplitHostPort(req.RemoteAddr) errors, we return req.RemoteAddr.

Would be cool if someone could comment on those two things :)
Because I feel like those are just dead code paths.

[mholt]

Nice, thank you! This will have my approval as soon as the tests finish running (assuming they pass)

I think the way you're handling the int conversion is fine.

[mholt]

Great, LGTM @emilylange ! Thank you for the contribution 😃