You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Should also truncate the IP in the common_log part of the JSON output, otherwise its kind of pointless ? Maybe I'm missing something but what's the point of the default behaviour truncating remote_addr but not truncating common_log ?
I know I can take a hammer to the proverbial nail with common_log delete but that's not really the real answer to the problem, its more of a hack.
Also the docs (https://caddyserver.com/docs/caddyfile/directives/log#format-modules) should not really be making a suggestion for something that only half-works. Many people operating under GDPR jurisdiction will need a fully-functional IP truncating function, and the docs should not really be giving them false-hope of a "quick fix" if the IP is actually still left in the logs. The docs are silent on request>remote_addr ip_mask leaving the full IP in common_log (I note you previously promised enhancing the docs in this area #3837 .... obviously never happened since I just fell into the same trap despite looking in the section of the docs where I might have expected this to be made clear )
The text was updated successfully, but these errors were encountered:
Hi,
Surely:
Should also truncate the IP in the
common_log
part of the JSON output, otherwise its kind of pointless ? Maybe I'm missing something but what's the point of the default behaviour truncatingremote_addr
but not truncatingcommon_log
?I know I can take a hammer to the proverbial nail with
common_log delete
but that's not really the real answer to the problem, its more of a hack.Also the docs (https://caddyserver.com/docs/caddyfile/directives/log#format-modules) should not really be making a suggestion for something that only half-works. Many people operating under GDPR jurisdiction will need a fully-functional IP truncating function, and the docs should not really be giving them false-hope of a "quick fix" if the IP is actually still left in the logs. The docs are silent on
request>remote_addr ip_mask
leaving the full IP incommon_log
(I note you previously promised enhancing the docs in this area #3837 .... obviously never happened since I just fell into the same trap despite looking in the section of the docs where I might have expected this to be made clear )The text was updated successfully, but these errors were encountered: