Even with mode http:
defaults
mode http
log stdout local0
log-format 'path:%[path]'
it still fails.
What is more even if you use %[path] on http frontend:
defaults
mode http
log stdout local0
frontend front
mode http
# http-request set-var(txn.path) path
# log-format 'path:%[var(txn.path)]'
log-format 'path:%[path]'
bind 127.0.0.1:8888
default_backend back
backend back
mode http
server srv 127.0.0.1:80 check
it will also fail. The only way I know for using fetches in log-format is
through set-var()/var() (commented lines in above config).
Idea with named defaults is brilliant! :)
wt., 1 gru 2020 o 07:26 Willy Tarreau <[email protected]> napisał(a):
> On Tue, Dec 01, 2020 at 07:13:32AM +0100, Maciej Zdeb wrote:
> > For such defaults section:
> > defaults
> > log stdout local0
> > log-format 'path:%[path]'
> >
> > I'm getting following error:
> > [ALERT] 335/060923 (13259) : Parsing [haproxy.cfg:11]: failed to parse
> > log-format : sample fetch <path]}> may not be reliably used here because
> it
> > needs 'HTTP request headers' which is not available here.
> >
> > What I'm doing wrong? :)
>
> You're missing "mode http" in your defaults section. I tend to recommend
> not
> to mix TCP and HTTP defaults, because that tends to make TCP proxies
> inherit
> lots of HTTP settings. The checks are done everywhere (as you can see
> here),
> but this requires a lot of dedicated code to deal with corner cases, and I
> must admit I never know if from time to time an HTTP directive slips into a
> TCP proxy.
>
> The good practice instead is to have one "defaults" section for TCP and
> another one later for HTTP. I've long wanted to have named defaults that
> could be reused in proxies. This would require to extend the "frontend",
> "listen" and "backend" directives to take a section name at the declaration
> moment. For example:
>
> defaults tcp
> timeout client 1h
>
> defaults http
> mode http
> timeout client 10s
>
> frontend f1 from tcp
> bind :1234
>
> frontend f2 from http
> bind :80
>
> The last declared section would always set the current defaults though.
> If anyone is interested in working on this, it's not very difficult, the
> config parser currently knows about a single "defproxy", instead it could
> perform a lookup (or even copy it from the current designated one).
>
> Willy
>
