RE: cookie prefix strange behavior
Hi Baptiste, as you can see using prefix or sticky table we found this invalid
cookie problem.
- Why without haproxy in the middle we do not have this problem ? why a browser
send an INVALID cookie ?
- How we can match absence of prefix ? can be done directly by haproxy ?
Roberto
-Original Message-
From: Baptiste [mailto:bed...@gmail.com]
Sent: venerdì 17 luglio 2015 22.09
To: mlist
Cc: haproxy@formilux.org
Subject: Re: cookie prefix strange behavior
Hi Roberto,
Look in your log lines, block 2, HAProxy says --IN. 'IN' is for
cookie persistence.
'I' means the cookie sent by the client is invalid and 'N' means
HAProxy did not perform any action on persistence.
In such case, you could try to match that there are no prefix in your
cookie and do a redirect to a page which cleans up the cookie then
redirect the user to the login page.
Baptiste
On Fri, Jul 17, 2015 at 5:49 PM, mlist ml...@apsystems.it wrote:
We found this behavior does not appears if we manually clean cookie in the
browser. There is a configuration option to invalidate old cookie so client
does not reuse this strange cookie not recognized by server ?
Roberto
From: mlist
Sent: venerdì 17 luglio 2015 16.19
To: 'haproxy@formilux.org'
Subject: cookie prefix strange behavior
We have compiled and installed haproxy version 1.6 dev2.
If we use cookie insert all works, but if we use cookie prefix
(ASP.NET_SessionId) or sticky table in which one have to specify cookie to
be sticked, so using cookie name = ASP.NET_SessionId) we have a strange
behavior.
BLOCK1
As you can see below, we open a browser and make a request, cookie prefix
mechanism works well, we can login and use the application (all subsequent
requests go on the some server).
BLOCK2
But if we open a new browser instance (chrome in this case, but this happen
also if we open IE) the client uses a strange “ASP.NET_SessionId” cookie
without haproxy prefix with back-end server, server does not ask client to
set a new cookie.
As of login, clearly, backend server does not recognize the cookie sent by
client (haproxy do a plain roundrobin distribution, no cookie management was
done) and so backend server return an error.
Can this be a bug of haproxy or a bad configuration by us ?
BLOCK1
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37322
[17/Jul/2015:14:55:49.414] front_end_https~ back_end_https/SERVER1
2/0/44/18/64 302 467 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} GET /app1/ HTTP/1.1
Jul 17 14:55:49 ha_server1 haproxy[5604]: client_ip:37324
[17/Jul/2015:14:55:49.484] front_end_https~ back_end_https/SERVER1
2/0/5/22/29 200 6449 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} GET /app1/login.aspx HTTP/1.1
Jul 17 14:55:52 ha_server1 haproxy[5604]: client_ip:37328
[17/Jul/2015:14:55:52.284] front_end_https~ back_end_https/SERVER1 2/0/1/3/7
404 1424 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
GET /app1/segreteria HTTP/1.1
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37344
[17/Jul/2015:14:55:59.452] front_end_https~ back_end_https/SERVER1 2/0/1/2/5
301 448 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 - --VN 0/0/0/0/0
0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, l}
GET /app1/anagrafenet HTTP/1.1
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37345
[17/Jul/2015:14:55:59.461] front_end_https~ back_end_https/SERVER1
2/0/1/32/36 302 435 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} GET /app1/anagrafenet/ HTTP/1.1
Jul 17 14:55:59 ha_server1 haproxy[5604]: client_ip:37346
[17/Jul/2015:14:55:59.501] front_end_https~ back_end_https/SERVER1
2/0/1/27/31 200 6625 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} GET /app1/login.aspx HTTP/1.1
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37359
[17/Jul/2015:14:56:06.515] front_end_https~ back_end_https/SERVER1
1/0/4/64/69 302 6712 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {|946|Mozilla/5.0 (Windows NT 6.2; WOW64)
AppleWebKit/537.36 (KHTML, l} POST /app1/login.aspx HTTP/1.1
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37361
[17/Jul/2015:14:56:06.588] front_end_https~ back_end_https/SERVER1
2/0/1/175/179 200 28897 ASP.NET_SessionId=SERVER1~fi2b5smpq33tgwfy0qqmog45 -
--VN 0/0/0/0/0 0/0 {||Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36
(KHTML, l} GET /app1/anagrafenet/default.aspx HTTP/1.1
Jul 17 14:56:06 ha_server1 haproxy[5604]: client_ip:37364
[17/Jul/2015:14:56:06.777]
Re: Server IP resolution using DNS in HAProxy
On 07/17/2015 10:37 PM, Baptiste wrote: First would be resolution of SRV records and actually using the port supplied by the SRV record as the port for the server. I looked at the code and it doesn't seem like too much work, most of it would probably be changing the config stuff accordingly. You're right, this could be an interesting option. Actually, we though about the SRV records to populate a full backend server list with IP, name, port, weight using a single DNS query. Awesome! That's exactly what I want :) It's what I tried to express in the second part of my request, probably in a slightly weird way. The other one is... well you asked for it ;) so here it goes: it would be great to express in the config something like resolve this name and use up to X servers from the reply. The backend then allocates X servers. Assuming that the initial lookup returns Y results, the (sorted) records get assinged to the first Y servers, the other X-Y servers get marked as down. Upon a new lookup, same procedure for a potentially changing value of Y. I realize this a pretty bold feature request for several reasons, but I have actually spent some thought on it think it might be doable without really violating any of HAProxy's design paradigms. I would also be willing to invest some time (code) into this myself. If you think this might be at least worth a discussion, I'd be happy to share some more detailed thoughts and it would be great to hear your thoughts on that, too. First, there are some limitations about creating servers on the fly in a backend. So instead, we propose you to pre-allocate servers by configuration and then wait for the DNS to populate it. It's kind of what I meant, although I had something in mind where you say once preallocate 20 servers for this backend instead of listing 20 servers with the same hostname. But that's syntactic sugar and I would happily use the solution listing a server for each desired allocation. I don't speak about a request per server, I speak here about one request for the whole farm :) Again, awesome! That's what I'm looking for! You go one step further than the design we have about SRV records to populate the backend. We thought using priority to decide whether a server is active or backup. The advantage is that you don't need to reload HAProxy to change your X value ;) Yes, perfect. And, what I tried to express above, HAProxy should mark some servers down if the number records received is less than the number of servers configured. I would welcome a contribution about SRV record type. That said, before this, I have to rewrite part of the response parser to store the response in a real DNS packet structure instead of keeping data in a buffer. Sounds good. I am not sure what you have in mind there or what parts of the code would be touched by that, so if you let me know when it's done I'll happily send some patches as a base for further discussion! Thanks, Baptiste, this get's me even more excited about HAProxy than I am already :) Cheers, Conrad -- Conrad Hoffmann Traffic Engineer SoundCloud Ltd. | Rheinsberger Str. 76/77, 10115 Berlin, Germany Managing Director: Alexander Ljung | Incorporated in England Wales with Company No. 6343600 | Local Branch Office | AG Charlottenburg | HRB 110657B
