I’ve run into this issue in the past. It’d be great if someone could provide some insight. I ended up blogging about this in the past: http://jtslear.github.io/haproxy-url-rewrite-logging-double-take/
-- John Skarbek On February 7, 2017 at 14:00:25, Daniel Schneller ([email protected]<mailto:[email protected]>) wrote: Hello everyone! While I have since figured out what my original problem was, the original question remains. Is this intentional, am I missing something, or both? :) Cheers, Daniel > On 3. Feb. 2017, at 13:40, Daniel Schneller > <https://urldefense.proofpoint.com/v2/url?u=http-3A__daniel.schneller-40centerdevice.com&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BZ2S09kcMRiJIUh57WZsng&m=tQNdSzaKpC53d3kW9drHgsYezyVJJxmlQGYAj1yiKyA&s=1Be7yWuGw-a_Bs7_WTLP5-Okxoc46siKz_9DhE0JMGE&e= > > wrote: > > Hi there! > > I currently trying to figure out a problem with request and response header > rewriting. > To make things easier I run haproxy in debug mode, so I get the client/server > conversation all dumped to my terminal. > I am wondering, however, if I am missing something, because apparently the > output of the response shows only what the backend server sent in response to > a request, but any changes I make to the response headers are not to be seen > in haproxy’s output. > > In my case I have a > > http-response replace-header Location '(http|https):\/\/my.domain\/(.*)' '/\2' > > which appears to work, because the client gets the rewritten response, but > the debug output looks like this (somewhat redacted) > > 002:front.accept(000b)=0012 from [1.2.3.4:62699] > 002:front.clireq[0012:ffffffff]: GET > /authorize?client_id=xxx&redirect_uri=yyy&state=zzz&response_type=code > HTTP/1.1 > 002:front.clihdr[0012:ffffffff]: Host: my.domain > > > 002:back.srvrep[0012:0013]: HTTP/1.1 302 Found > 002:back.srvhdr[0012:0013]: Server: Apache-Coyote/1.1 > 002:back.srvhdr[0012:0013]: Location: > https://urldefense.proofpoint.com/v2/url?u=https-3A__my.domain_login-3Fclient-5Fid-3Dxxx-26redirect-5Furi-3Dyyy-26response-5Ftype-3Dcode&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BZ2S09kcMRiJIUh57WZsng&m=tQNdSzaKpC53d3kW9drHgsYezyVJJxmlQGYAj1yiKyA&s=jfynFggrAFl0-lUX55K44O2ShY1NkyLx4i9aGXDUR2k&e= > ^^^^^^^^^^^^^^^^^ > | to be removed | > > > 003:front.clireq[0012:0013]: GET > /login?client_id=xxx&redirect_uri=yyy&response_type=code HTTP/1.1 > ^^^ > | obviously removed > > 003:front.clihdr[0012:0013]: Host: my.domain > … > > > This is just one of the rewrites that happen, and it makes things more > cumbersome to debug, because I need to capture both the server’s and the > client’s logs and merge them together. > > Is there a switch or config setting I am missing that would show what the > server actually puts on the wire towards the client? > > Thanks > Daniel > > > > -- > Daniel Schneller > Principal Cloud Engineer > > CenterDevice GmbH | Hochstraße 11 > | 42697 Solingen > tel: +49 1754155711 | Deutschland > [email protected] | > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.centerdevice.de&d=DwIFaQ&c=_hRq4mqlUmqpqlyQ5hkoDXIVh6I6pxfkkNxQuL0p-Z0&r=BZ2S09kcMRiJIUh57WZsng&m=tQNdSzaKpC53d3kW9drHgsYezyVJJxmlQGYAj1yiKyA&s=e0a21qW1lqHIwjNXhxKj23f1y6CowSCnPercr38zfVk&e= > > Geschäftsführung: Dr. Patrick Peschlow, Dr. Lukas Pustina, > Michael Rosbach, Handelsregister-Nr.: HRB 18655, > HR-Gericht: Bonn, USt-IdNr.: DE-815299431 > >
