-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Log spam during attempt to append remote address to the XFF header when the transport is a unix domain socket #1538
Comments
Hi Jan, thanks for raising this issue. That sounds really annoying! Would it be better if we downgraded this to a debug log? Or would you like to have it removed? What can I do to help you bring this contribution in? |
I'm happy to fix this! I'm wondering if there is any reason to try to verify whether the request's transport is a Unix Domain Socket and, if so, append the loopback address to the XFF header. Otherwise, I think removing the log message is fine since it's probably not useful. LMK what you think! |
Yeah I don't think we're going to try to parse it as a domain socket, so lets just remove the message then. |
Sounds good, PR submitted! |
🐛 Bug Report
The
annotateContext
function cannot append the request's remote address if the request arrives via a Unix Domain Socket. The code attempts to parse thereq.remoteAddr
field and fails. This is not really a big problem except that an info level log message is printed every time thereq.remoteAddr
cannot be parsed.To Reproduce
Expected behavior
No info level log, maybe update the
X-Forwarded-For
header (though I'm not sure if appending the Unix Domain Socket path to the header contents is valid)Actual Behavior
While running a high traffic service, a lot of log messages are generated that look like this:
invalid remote addr: @
Your Environment
Linux (container running in kubernetes)
The text was updated successfully, but these errors were encountered: