Thanks Chad,
I found that setting the path in the frontend (instead of the backend)
removed the selection of backend based on the path via acl, presumably because
the rewrite is set before the acl is processed ; bit of a catch 22.
It's possible I misunderstand an implied concept of ordering the config but the
acl was before we altered the path, which is where I'd imagine it should be to
do the acl bit first. HA seems to like any backend selection stuff to be later
in the frontend config I think too, so no go there - I couldn't select the
backend before rewriting the path.
I also couldn't get the http-request capture path len 32 bit to work without
using the log display of capture.req.hdr(idx) instead of just %[path] or path
in there, said it needed access to the http headers which it didn't have, or
something similar.
I found that I can record the rewritten URL though - just for reference I ended
up realising from Cyril's example that I was using the wrong scope - setting a
variable in the backend against the "req" scope didn't work, but the "txn" did
record the necessary in the logs.
frontend ft_web_ssl
..
acl audioserve path_beg -i /audioserve
log-format %ci:%cp\ [id=%ID]\ [%t]\ %f\ %b/%s\ %Tq/%Tw/%Tc/%Tr/%Tt\ %ST\ %B\
%CC\ %CS\ %tsc\ %ac/%fc/%bc/%sc/%rc\ %sq/%bq\ {%hrl}\ {%hsl}\ %{+Q}r\
%{+Q}[var(txn.filteredurl)]
use_backend bk_audioserve_3000 if audioserve
..
backend bk_audioserve_3000
mode http
option httplog
# issue with double slashes on certain URLs - need to raise
with audioserve coder - https://github.com/izderadicka/audioserve
# also remove the /audioserve/ virtual directory as this app
works from the root as a node.js webapp.
http-request set-var(txn.filteredurl)
capture.req.uri,regsub(/audioserve[/]?,/,g),regsub(//,/,g)
http-request set-path %[var(txn.filteredurl)]
server www.andyjfranks.uk 127.0.0.1:3000
Thanks chaps!
Andy
From: Chad Lavoie [mailto:[email protected]]
Sent: 27 March 2018 18:04
To: [email protected]
Cc: Franks Andy (IT Technical Architecture Manager)
Subject: Re: Logging actual fetched URL after request is re-written
Greetings,
Sorry, pressed wrong button so didn't include on CC.
On 03/27/2018 01:03 PM, Chad Lavoie wrote:
Greetings,
On 03/27/2018 12:49 PM, Franks Andy (IT Technical Architecture Manager) wrote:
Hi all,
Logging with HTTP as standard, the %{+Q}r log variable records the requested
URL in the logs. I'd like to also record the URL that's actually fetch after an
http-request set-path directive is given (for debugging purposes). It's linked
to an application that provides next to no debugging, and tcpdump isn't much
help either - having it in haproxy logs would be really useful.
Can I do this or am I thinking too much outside the box? I tried setting a
dynamic variable and then setting that in the frontend log-format, but it
didn't seem to record anything even despite populating the variable.
You should be able to add "http-request capture path len 32" at the end of a
frontend to capture the path after all the modifications.
Variables should work too, though without knowing exactly what your variable
rules looked like I can't guess as to why it didn't capture anything.
- Chad
Thanks
