No, you are right, as I told you I was wrong thinking Referer had to do with
the browser URL, I see only Referer in the header with wrong case, so I think
that.
It is only to understand haproxy regex match behavior so I've more control...
:D (but antislash before /demoj is not necessary to escape special character
"/" in pcre ?)
Thank you for the insights in the reqirep..
If I can, I ask you also another problem we have... tell me if you prefer I
send in a new mail.
I use this line to redirect request from http to https:
redirect scheme https if !leave_http !{ ssl_fc }
This work fine for all request, but we have a problem with an application
request that POSTing some data:
If I disable https redirection application works well:
0000000a:main_fe.accept(0005)=0008 from [xx.xxx.xx.xx:54812]
0000000a:main_fe.clireq[0008:ffffffff]: POST /app1/hslist.aspx HTTP/1.1
0000000a:main_fe.clihdr[0008:ffffffff]: Content-Type:
application/x-www-form-urlencoded
0000000a:main_fe.clihdr[0008:ffffffff]: Host: myhost.mydomain.net
0000000a:main_fe.clihdr[0008:ffffffff]: Content-Length: 118
0000000a:def_backend.srvrep[0008:0009]: HTTP/1.1 200 OK
0000000a:def_backend.srvhdr[0008:0009]: Cache-Control: private
0000000a:def_backend.srvhdr[0008:0009]: Content-Type: text/html; charset=utf-8
0000000a:def_backend.srvhdr[0008:0009]: Server: Microsoft-IIS/8.5
0000000a:def_backend.srvhdr[0008:0009]: X-AspNet-Version: 2.0.50727
0000000a:def_backend.srvhdr[0008:0009]: X-Powered-By: ASP.NET
0000000a:def_backend.srvhdr[0008:0009]: Date: Tue, 28 Jul 2015 09:22:30 GMT
0000000a:def_backend.srvhdr[0008:0009]: Connection: close
0000000a:def_backend.srvhdr[0008:0009]: Content-Length: 2156
If I enable https redirection this happen:
0000000b:main_fe.accept(0005)=0008 from [xx.xxx.xx.xx:54841]
0000000b:main_fe.clireq[0008:ffffffff]: POST /app1/hslist.aspx HTTP/1.1
0000000b:main_fe.clihdr[0008:ffffffff]: Content-Type:
application/x-www-form-urlencoded
0000000b:main_fe.clihdr[0008:ffffffff]: Host: myhost.mydomain.net
0000000b:main_fe.clihdr[0008:ffffffff]: Content-Length: 122
0000000b:main_fe.clihdr[0008:ffffffff]: Connection: Keep-Alive
0000000b:main_fe.clicls[0008:ffffffff]
0000000b:main_fe.closed[0008:ffffffff]
0000000c:main_fe.accept(0006)=0008 from [78.134.33.29:54842]
0000000c:main_fe.clireq[0008:ffffffff]: GET / app1/hslist.aspx HTTP/1.1
0000000c:main_fe.clihdr[0008:ffffffff]: Content-Type:
application/x-www-form-urlencoded
0000000c:main_fe.clihdr[0008:ffffffff]: Host: myhost.mydomain.net
0000000c:main_fe.clihdr[0008:ffffffff]: Connection: Keep-Alive
0000000c:def_backend.srvrep[0008:0009]: HTTP/1.1 500 MyError
0000000c:def_backend.srvhdr[0008:0009]: Cache-Control: private
0000000c:def_backend.srvhdr[0008:0009]: Content-Type: text/html
0000000c:def_backend.srvhdr[0008:0009]: Server: Microsoft-IIS/8.5
0000000c:def_backend.srvhdr[0008:0009]: X-AspNet-Version: 2.0.50727
0000000c:def_backend.srvhdr[0008:0009]: X-Powered-By: ASP.NET
0000000c:def_backend.srvhdr[0008:0009]: Date: Tue, 28 Jul 2015 09:30:40 GMT
0000000c:def_backend.srvhdr[0008:0009]: Connection: close
0000000c:def_backend.srvhdr[0008:0009]: Content-Length: 1208
As you can see, a client POST request with Data is redirected so client ask a
GET without DATA, so server return an error.
1. What HTTP method "redirect scheme https" do ? (301, 302, 303 or 307) ?
2.
3. On the haproxy debug I cannot found all communications, so I do not
find ie the redirect request haproxy send to client, so I do not know what
"...scheme https.." do (what HTTP redirect status it uses).
Also using tcpdump on haproxy machine I do not see real communication as
haproxy change http packet before these packet arrive to tcp level. tcpdump see
packet just modifice by haproxy...
There is a mechanism I can see in the debug (haproxy -c <config file> -d) this
info and/or more info ? Or there is other mechanism to have a complete
monitoring data without doing this on a up or down stream server (on the
client, on the server or on firewall between those) ?
4. Is the client behavior correct (I think yes, probably in a rigid
manner as for the standard if the redirect is done with 301, 302 and 303 are
redirected with GET instead 307 leave original Method, so POST...), but tell me
if I'm wrong.
Roberto
-----Original Message-----
From: Cyril Bonté [mailto:[email protected]]
Sent: martedì 28 luglio 2015 10.24
To: mlist
Cc: [email protected]
Subject: Re: Regex
Hi again,
On 28/07/2015 09:42, mlist wrote:
>
> I wrote in the first mail I used 2 different regex. The (1) probably doesn't
> match, but the (2) ?
>
>> (2) reqirep (.*)\/demoj(.*) \1/DemoJ\2
>
> This regex match https://<hostname<https://%3chostname>>, I'm Wrong ?
Good news for you, at this step, no, you are perfectly right (except
that there is an unneeded antislash before /demoj).
And I realize that you are also right about something unclear in the
documentation : headers transformations only apply when the request line
doesn't match. This is quite well documented in the code, not in the
documentation... Here comes the confusion on your side and mine.
This means that whatever you do, if your request line contains "/demoj"
a regex like (.*)/demoj(.*) will never apply to headers.
You have to sepcify 2 different regex which will ensure that will match
only one case at a time (request line OR headers).
But I still don't understand why you want to modify the referer.
--
Cyril Bonté
--
Il messaggio e' stato analizzato alla ricerca di virus o
contenuti pericolosi da MailScanner, ed e'
risultato non infetto.
