RE: Cookie parsing issue...

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

> Hey Yves,
>
> Your fix worked perfectly plus it makes a lot more sense then some of 
> the other things we were trying.  I not too sure where you are on doing 
> a 2.2.6 release, but do you think you can integrate this fix and push 
> out a minor release (ex: 2.2.5b)?

I may do a 2.2.6 right before doing a separate CVS branch for jdk1.5 and 
beyond. I'll try to do so soon.
btw, the sources in CVS reflected the change.
Cheers,

>
> Thanks again for the help,
> Brian
>
> -----Original Message-----
> From: Yves Lafon [mailto:ylafon@w3.org]
> Sent: Tuesday, March 20, 2007 9:03 AM
> To: Laird, Brian
> Cc: www-jigsaw@w3.org; Mrozinski, Ken
> Subject: 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 15:43:50 UTC