RE: appsession fix

From: Ryan Warnick <warnickr_1#isp01.net>
Date: Thu, 14 Feb 2008 14:46:44 -0700


Sounds good. How about that first change that I proposed (the bug fix)? Here is the diff -u:

        /* only do insert, if lookup fails */
-       if (appsession_hash_lookup(&(t->be->htbl_proxy),
asession_temp->sessid) == NULL) {

+ asession_temp = appsession_hash_lookup(&(t->be->htbl_proxy),
asession_temp->sessid);
+ if (asession_temp == NULL)
if ((asession_temp = pool_alloc2(pool2_appsess)) == NULL) { /* free previously allocated memory */ pool_free2(apools.sessid, local_asession.sessid);

Thanks,
Ryan

-----Original Message-----
From: Willy Tarreau [mailto:w#1wt.eu]
Sent: Thursday, February 14, 2008 2:10 PM To: Ryan Warnick
Cc: haproxy#formilux.org
Subject: Re: appsession fix

On Thu, Feb 14, 2008 at 01:05:17PM -0700, Ryan Warnick wrote: > We would like to be able to use any query parameter that we want (without > out it having to start with a ;).

OK I see now. IIRC, the semi-colon was selected because of common use on existing applications (Aleks correct me if I'm wrong). The semi-colon was not the start of the parameter name, but used as a separator between previous
parameter and the one we care about. I think that we should just check that the parameter is either at the beginning of the query string, or preceeded by
a non-alphanum (nor any of '_', '-' and a few other ones).

> Also, thanks for your critique of our proposed change. You are absolutely > right, we should use something like memmem instead.

I'm just realizing that since the cookie name is fix and checked for every request, it may make sense to use a boyer-moore search method, and construct the table at configuration time. That way, the longer the cookie, the faster the scan. And with an average size around 10 chars (JSESSIONID, ...), it would make parsing 10 times faster.

Regards,
Willy

__________ NOD32 2873 (20080213) Information __________

This message was checked by NOD32 antivirus system. http://www.eset.com Received on 2008/02/14 22:46

This archive was generated by hypermail 2.2.0 : 2008/02/14 23:00 CET