Separate log field for request port #4396
Comments
|
Related to #4148 |
|
Hey @ledlamp, thanks for participating and submitting feedback!
Why do you think that? Why is this needed? In my experience, the remote address is usually combined. |
|
I'm using the log formatter module to output pretty human-friendly
formatted logs with only the useful information, but all the client
addresses have useless port numbers with them. So I think it makes sense
that they should be separate fields as they are separate units of
information, and such way it won't be necessary to do special string
manipulation for the formatted log.
…On Tue, Oct 26, 2021, 1:14 PM Matt Holt ***@***.***> wrote:
Hey @ledlamp <https://github.com/ledlamp>, thanks for participating and
submitting feedback!
I think the port should be a separate field.
Why do you think that? Why is this needed? In my experience, the remote
address is usually combined.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4396 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF4LCHNW42OXZMYYHJSIMSTUI4D2BANCNFSM5GUKVOIQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
|
Having then separate would avoid having to do some extra processing to split them up in situations where only the IP address is desired (i.e. most of the time because the internal port of the connection is really not that useful to know about). This was a pain-point with the format-encoder module because Common Log specifically wants just the remote IP, not including the port. I kinda feel we should rip off the band-aid and split them up at the same time as we remove If both the remote IP and port are desired, they can be concatenated trivially. But if only one of the two is desired, then it's a lot more complicated, especially if IPv6 comes into play, etc. |
Closes #4396, related to #4148 This is a breaking change, but we're already planning on removing the`common_log` field as well at the same time, so might as well all do it together. In general, the remote IP is the useful part of the remote address. The port is rarely useful, because it only identifies ephemeral information about the connection from the client. But we were logging both in one field, so certain tooling that would want to only get the remote IP would need to split it up. Splitting is non-trivial, because of IPv4, IPv6, shenanigans. So it's best if we split it up-front before logging. If the log consumer actually cares about the remote port, it can re-assemble it.
Closes #4396, related to #4148 This is a breaking change, but we're already planning on removing the`common_log` field as well at the same time, so might as well all do it together. In general, the remote IP is the useful part of the remote address. The port is rarely useful, because it only identifies ephemeral information about the connection from the client. But we were logging both in one field, so certain tooling that would want to only get the remote IP would need to split it up. Splitting is non-trivial, because of IPv4, IPv6, shenanigans. So it's best if we split it up-front before logging. If the log consumer actually cares about the remote port, it can re-assemble it.
Closes #4396, related to #4148 This is a breaking change, but we're already planning on removing the`common_log` field as well at the same time, so might as well all do it together. In general, the remote IP is the useful part of the remote address. The port is rarely useful, because it only identifies ephemeral information about the connection from the client. But we were logging both in one field, so certain tooling that would want to only get the remote IP would need to split it up. Splitting is non-trivial, because of IPv4, IPv6, shenanigans. So it's best if we split it up-front before logging. If the log consumer actually cares about the remote port, it can re-assemble it.
request>remote_addrofhttp.log.accesslogs are in format of<ipa>:<port>. I think the port should be a separate field.The text was updated successfully, but these errors were encountered: