RE: Cookie parsing issue...

On Tue, 20 Mar 2007, Laird, Brian wrote:

> Hey Yves,
>
> Well I spent some time trying to implement your fix and here is what I 
> found:
>
> The problem actually exists in the HttpParser.  What I think is 
> happening is that the third call to the parser (from the HttpCookieList 
> class) to get the value of the cookie is stopping on the equals sign 
> because that is the delimiter.
>
> I think this is easier to explain via an example.  Below is an example 
> cookie header.
>
> Cookie: HGS$$LocaleCookie=en_US; CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2; 
> CARDTYPE=card
>
> The first call to the parse routine using the cv (ParseState) yields the 
> following: CHALLENGE_COOKIE=Y3hBsq1lr9AxMTE2==
>
> This is correct.  The next call to the parse routine using the it 
> variable (ParseState) yields the following which is the name of cookie. 
> Now the it variable was initialized with the equals sign as the 
> separator.
>
> CHALLENGE_COOKIE
>
> The third call to the parse routine is where we lose the equals sign. 
> The routine returns the following:
>
> Y3hBsq1lr9AxMTE2
>
> In the HttpParser, as it runs through the bytes it is checking to see if 
> it hit the separator.  Once it does find the separator it assumes it is 
> complete.
>
> Now I looked to see how to fix this and I am kind of at a loss.  Here is 
> what we did try to do:
>
> - Tried implementing your fix but that resulted in an infinite loop.  I 
> think that has to do with how the ParseState is keeping track of the 
> position in the raw bytes and then where the separator shows up.

Yes, I know why now, the test should have been >= 0 instead of < 0. But 
see below:

> - Create a new ParseState object with a separator that would never be 
> found in a cookie.  Unfortunately, we could never get it work correctly. 
> I don't think we set the start & end variables correctly.
>
> - Change the existing it variables separator to something that would 
> never be found in a cookie.  Again that didn't work right.
>
> - We looked at just rewriting the whole parse routine but we were afraid 
> that we will introduce some bugs that you have long since resolved due 
> to browser compatibility type stuff.

That would be ideal for this special case, but another way would be to 
tweak the ParseState to go directly to the end of the buffer before 
calling it.toString(raw);
In that case, as we know the end of the buffer (above you can read 
it.bufend = cv.end;)
So the "right" fix is to do:
             } else {
 		c.setValue(it.toString(raw));
 	    }
=>
             } else {
                 // we know that we must read everything from the first
                 // separator (in case there are multiple instances)
 	        it.end = cv.end;
                 c.setValue(it.toString(raw));
             }

> We are perfectly willing to do the work if you could just provide some 
> direction as to how best to resolve this issue.

The HTTP parser has been optimized to reduce copying while parsing, that's 
why it may be a bit hairy in some cases, but that's the cost of trying to 
be efficient
Cheers,

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 20 March 2007 14:03:43 UTC