Cookie parsing issue...

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Cookie parsing issue...

Laird, Brian-2

Hey Yves,

 

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.  

 

The problem we are seeing is that the browser is sending in the right value but jigsaw is dropping the last two equal signs.  One note is that the cookie is in the middle of other cookies when you look at the header but there is semicolon at end of the value as would be expected.

 

A little bit of background on environment:

- We are running 2.2.5a code

- Jigsaw is using JDK 1.5_06

- Solaris 8

 

Do you have any thoughts on why this might be happening or at least which class the actual parsing of the cookies from the request header is happening in?  I am perfectly willing to try to make a fix, but I wasn’t able to easily find where the low level parsing actually took place.

 

Thanks in advance for any help on this one,

Brian




************************************************************************
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.
************************************************************************
Reply | Threaded
Open this post in threaded view
|

Re: Cookie parsing issue...

Yves Lafon

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.

Hi Brian, good to see you again!
I'll look into that soon, the parsing of Cookies was a bit weird to allow
Cookies to be sent in multiple headers.
I recently did some modification in Jigsaw for the compilation in jdk1.5
and 1.6, and there may be a new CVS branch with some jdk1.4+ optimizations
in it.

> The problem we are seeing is that the browser is sending in the right
> value but jigsaw is dropping the last two equal signs.  One note is that
> the cookie is in the middle of other cookies when you look at the header
> but there is semicolon at end of the value as would be expected.
>
>
>
> A little bit of background on environment:
>
> - We are running 2.2.5a code
>
> - Jigsaw is using JDK 1.5_06
>
> - Solaris 8
>
>
>
> Do you have any thoughts on why this might be happening or at least
> which class the actual parsing of the cookies from the request header is
> happening in?  I am perfectly willing to try to make a fix, but I wasn't
> able to easily find where the low level parsing actually took place.
>
>
>
> Thanks in advance for any help on this one,
>
> Brian
>
> ************************************************************************
> 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.
> ************************************************************************
>

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

         ~~Yves


Reply | Threaded
Open this post in threaded view
|

Re: Cookie parsing issue...

Yves Lafon

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


Reply | Threaded
Open this post in threaded view
|

RE: Cookie parsing issue...

Laird, Brian-2
In reply to this post by Laird, Brian-2

Thanks, Yves!  I will try that today to see if that fixes the problem.

Brian

-----Original Message-----
From: "Yves Lafon" <[hidden email]>
To: "Laird, Brian" <[hidden email]>
Cc: "[hidden email]" <[hidden email]>
Sent: 3/16/2007 7:51 AM
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.
************************************************************************


Reply | Threaded
Open this post in threaded view
|

RE: Cookie parsing issue...

Laird, Brian-2
In reply to this post by Yves Lafon

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:[hidden email]]
Sent: Friday, March 16, 2007 7:50 AM
To: Laird, Brian
Cc: [hidden email]
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.
************************************************************************


Reply | Threaded
Open this post in threaded view
|

RE: Cookie parsing issue...

Yves Lafon

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


Reply | Threaded
Open this post in threaded view
|

RE: Cookie parsing issue...

Laird, Brian-2

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)?  

Thanks again for the help,
Brian

-----Original Message-----
From: Yves Lafon [mailto:[hidden email]]
Sent: Tuesday, March 20, 2007 9:03 AM
To: Laird, Brian
Cc: [hidden email]; 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


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


Reply | Threaded
Open this post in threaded view
|

RE: Cookie parsing issue...

Yves Lafon

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:[hidden email]]
> Sent: Tuesday, March 20, 2007 9:03 AM
> To: Laird, Brian
> Cc: [hidden email]; 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