Hi Aleks,
On 11/10/2015 10:56 PM, Aleksandar Lazic wrote:
Dear Sylvain Faivre,
Am 10-11-2015 12:48, schrieb Sylvain Faivre:
On 11/10/2015 12:00 AM, Aleksandar Lazic wrote:
Hi Sylvain Faivre.
Am 09-11-2015 17:31, schrieb Sylvain Faivre:
[snipp]
So, I've got this so far :
backend http
stick-table type string len 24 size 10m expire 1h peers prod
stick on urlp(JSESSIONID,;)
stick on cookie(JSESSIONID)
Does this seem right ?
The help for "stick on" tells it defines a request pattern, so I guess
this would not match JSESSIONID cookie ou url parameter set in the
reply ?
I have no java server here to test this commands but with this commands
haproxy does not warn you about some config errors ;-).
###
backend dest01
mode http
stick-table type string len 24 size 10m expire 1h peers prod
stick on urlp(JSESSIONID,;)
stick on cookie(JSESSIONID)
stick store-response cookie(JSESSIONID)
# stick store-response res.hdr(JSESSIONID,;)
stick store-request cookie(JSESSIONID)
stick store-request urlp(JSESSIONID,;)
server srv_dest01 dest01.com:80
###
I have not seen a good option to read the JSESSIONID from the response
header in case it is not in a cookie.
Have anyone I idea?!
Please can you post a full response header which was created from the
app or appserver when the app or appserver have detected that the client
does not allow cookies.
[snipp]
In fact, the server sends the JSESSIONID as a cookie even if the
client does not support cookies, *and* it adds the JSESSIONID as a URL
parameter in all links, so this should be all right.
This would be helpfully to see the full response.
Maybe some appserver behaves different.
As far as I know, there is no way for the server to detect if the client
has cookies enabled, by looking only at the first request from that client.
According to a quick Google search, the most common ways to detect
cookies support are either to use Javascript (so client-side check) or
to reply with a redirect response with the cookie set, then when
processing the redirected URL, check if the client sent the cookie along
with the request (so this case will be covered by the proposed HAproxy
settings).
I don't feel comfortable giving our application server version on a
public list, but I will send it to you in private.
Here are the headers from a client request and server reply, with a
brand new profile on the client (with cookies disabled) :
- request :
GET /front/url1.do?m=booking&langcode=FR HTTP/1.1
Host: redacted.host.domain
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0)
Gecko/20100101 Firefox/42.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
- reply :
HTTP/1.1 200 OK
Date: Mon, 16 Nov 2015 15:25:41 GMT
Content-Type: text/html;charset=ISO-8859-15
Set-Cookie: JSESSIONID=uNmYNvgUME5-8LYPzimsCg__.8d15fc; Path=/front
Vary: Accept-Encoding
Content-Encoding: gzip
Transfer-Encoding: chunked
And here is a URL sample from the body of the reply. You will notice
that the jsessionid is there twice, first one after a semicolon and
second one after a question mark. I am not sure if this comes from the
application server of from our custom code.
<script
src="https://redacted.host.domain/front/url2.do;jsessionid=uNmYNvgUME5-8LYPzimsCg__.8d15fc?jsessionid=uNmYNvgUME5-8LYPzimsCg__.8d15fc&langcode=FR";
language="JavaScript"></script>
I just tried your config on a test server, and the session IDs are
rightly recorded in the table, whether the client accepts cookies or
not.
Perfect.
I still have some test cases to run, I will check this next week and
report back if needed.
Oh yes please tell us the results so that we can add this as migration
example for appsession.
OK, I will. This will not go into production yet, we still need to run
it on a test environment for at least 3 weeks...
Best regards.
Sylvain
