When remote_addr_header is used, but not passed, remote_addr defaults to localhost

[Roguelazer]

Describe the bug
When the header option is passed to set_remote_address but the requisite header is not passed on a request, the request is attributed to localhost instead of to the actual peeraddr.

Puma config:

set_remote_address header: "X-Client-IP"

To Reproduce
Make an HTTP request from non-localhost without setting the X-Client-IP. Note that the Rack REMOTE_ADDR variable is set to 127.0.0.1 instead of your actual IP.

Expected behavior
When the header is not set, requests should have REMOTE_ADDR set to the actual remote addr. If it's not available, it is arguably more correct to use 0.0.0.0 rather than 127.0.0.1 but I'm less picky about that case.

Desktop (please complete the following information):

• OS: Linux
• Puma Version: 5.3.2

[nateberkopec]

If it's not available, it is arguably more correct to use 0.0.0.0 rather than 127.0.0.1 but I'm less picky about that case.

This is an API breakage and I'm not sure I agree. I think the choice is arbitrary and changing from one value to another doesn't have a big enough gain for the breakage.

When the header is not set, requests should have REMOTE_ADDR set to the actual remote addr.

Possibly... fallback to socket is not a bad idea.

[Roguelazer]

I would be satisfied with just having it fall back to the result of getpeeraddr; it seems unquestionably wrong that if I set set_remote_address header: "Foo" and someone sends a request without the "Foo" header, the request gets treated as coming from localhost (which might have elevated trust).

[nateberkopec]

Whoops, closed by #2653