RE: Cookie parsing issue...

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.  

- 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.

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

Thanks again for the help,
Brian

-----Original Message-----
From: Yves Lafon [mailto:ylafonw3.org] 
Sent: Friday, March 16, 2007 7:50 AM
To: Laird, Brian
Cc: www-jigsaww3.org
Subject: Re: Cookie parsing issue...

On Fri, 16 Mar 2007, Yves Lafon wrote:

>
> On Fri, 16 Mar 2007, Laird, Brian wrote:
>
>> I hope things are well; it has been a while since
we have talked.  We
>> came across a problem I am hoping you (or someone
who knows the jigsaw
>> code well) can help us with.  In a majority of our
processing we are
>> using some randomly generated cookie values from a
third party as kind
>> of a session identifier.  Well a few days ago the
value being generated
>> started to look like this (without the double
quotes):
>> "0_0RbEAwflUxOTIxNjgyMDMzMw==".  We also
store this value in memory and
>> compare it to the cookie when the user comes back
to our site.

Ok, I located the issue, the parsing is done in 
org.w3c.www.http.HttpCookieList, in parse(), the parser has
'=' as a 
separator, hence the issue you see.

you can try to change
     c.setValue(it.toString(raw));

by

StringBuffer sb = new StringBuffer(it.toString(raw));
while (HttpParser.nextItem(raw, it) < 0 ) {
     sb.append('=');
     sb.append(it.toString(raw);
}
c.setValue(sb.toString());

and see if that fixes the issue.

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

         ~~Yves


************************************************************
************
This e-mail and any accompanying documents or files contain
information that is the 
property of HAVI Global Solutions, that is intended solely
for those to whom this e-mail is addressed 
(i.e., those identified in the "To" and
"Cc" boxes), and that is confidential,
proprietary, 
and/or privileged.  If you are not an intended recipient of
this e-mail, you are hereby 
notified that any viewing, use, disclosure, forwarding,
copying, or distribution of any of 
this information is strictly prohibited and may be subject
to legal sanctions.  If you have 
received this e-mail in error, please notify the sender
immediately of any unintended 
recipients, and delete the e-mail, all attachments, and all
copies of both from your system.

While we have taken reasonable precautions to ensure that
any attachments to this e-mail 
have been swept for viruses, we cannot accept liability for
any damage sustained as a 
result of software viruses.
************************************************************
************

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