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:clavoie@haproxy.com]
Sent: 27 March 2018 18:04
To:
haproxy@formilux.org
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