When darkhttpd knows it's behind a proxy (--forward-https) - it makes more sense for logging purposes to set the client ip from a header rather than the source ip address of the connection.
So that these changes are a one time event - the following changes should be sufficient:
If --forward-https is enabled:
by default read the header X-Forwarded-For (this header is added automatically by most proxies nowadays by default - e.g Azure Front Door / Caddy server)
if a new option is set --log-proxy-header "Some-Header" use that header instead for the remote ip to be logged
Slightly OT - darkhttpd worked perfectly in a rootless podman pod behind caddy. Your docker container is also very nice with no shell / no users / no other binaries
When
darkhttpd
knows it's behind a proxy (--forward-https
) - it makes more sense for logging purposes to set theclient
ip from a header rather than the source ip address of the connection.So that these changes are a one time event - the following changes should be sufficient:
If
--forward-https
is enabled:X-Forwarded-For
(this header is added automatically by most proxies nowadays by default - e.g Azure Front Door / Caddy server)--log-proxy-header "Some-Header"
use that header instead for the remote ip to be loggedSlightly OT -
darkhttpd
worked perfectly in arootless
podman pod behind caddy. Your docker container is also very nice with no shell / no users / no other binaries