You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Alvarez, Gil" <Gi...@pogo.com> on 2004/03/25 07:37:27 UTC

question re: cookies

Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.

 

We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.

 

I obfuscated the url's and data, but the gist of it is that we hit the
url:

 

2004/03/24 19:06:25:295 PST [DEBUG] wire - ->> "GET /a/b/c/aol
HTTP/1.1[\r][\n]"

 

We get back a Set-Cookie:

 

2004/03/24 19:06:25:535 PST [DEBUG] wire - -<< "Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]

 

I then see this:

 

2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
"$Version=0

; badsc=cookie-value; $Path=/X/b/c". Illegal path attribute "/X/b/c".
Path of origin: "/a/b/c/aol"

 

and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:

 

if (!path.startsWith(cookie.getPath())) {

            throw new MalformedCookieException(

                "Illegal path attribute \"" + cookie.getPath()

                + "\". Path of origin: \"" + path + "\"");

}

 

So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.

 

Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??

 

Thanks.


Re: question re: cookies

Posted by Roland Weber <RO...@de.ibm.com>.
Hello Gil,

two options. If you only need to get the cookie for
your application, then access the header directly
instead of looking into the http state. That's probably
what your old code did, right?

Otherwise, implement and configure your own cookie
policy. Copy the default implementation that best fits
your needs, then modify the validity check for the
cookie path.
And don't forget to complain with the site admin
about the cookie standard violation.

You may first want to check whether there is an
alternative URL with path /X/b/c by which you can
query the cookie. There's got to be some reason
why the cookie is set with that path.

cheers,
  Roland





"Alvarez, Gil" <Gi...@pogo.com>
25.03.2004 07:37
Please respond to "Commons HttpClient Project"
 
        To:     <co...@jakarta.apache.org>
        cc: 
        Subject:        question re: cookies


Hi, we're porting some old code to use httpclient, and I was having
trouble with the manual cookie stuff that we do.

 

We hit a 3rd party web-site (AOL) for some info, and it sets a cookie
that we want to grab.

 

I obfuscated the url's and data, but the gist of it is that we hit the
url:

 

2004/03/24 19:06:25:295 PST [DEBUG] wire - ->> "GET /a/b/c/aol
HTTP/1.1[\r][\n]"

 

We get back a Set-Cookie:

 

2004/03/24 19:06:25:535 PST [DEBUG] wire - -<< "Set-Cookie:
badsc=cookie-value;path=/X/b/c[\r][\n]

 

I then see this:

 

2004/03/24 19:06:25:944 PST [WARN] HttpMethodBase - -Cookie rejected:
"$Version=0

; badsc=cookie-value; $Path=/X/b/c". Illegal path attribute "/X/b/c".
Path of origin: "/a/b/c/aol"

 

and when I try to look for this cookie in HttpState it isn't there. The
above msg is due to this code in CookieSpecBase:

 

if (!path.startsWith(cookie.getPath())) {

            throw new MalformedCookieException(

                "Illegal path attribute \"" + cookie.getPath()

                + "\". Path of origin: \"" + path + "\"");

}

 

So the problem is that the path of the cookie starts with /X, when the
path of the request started with /a.

 

Our old code worked fine (using std java.net classes) and was able to
pull out this cookie. I assume this validity check is due to some RFC
requirement. I did try the different policies and got the same error
each time. But given that this is 3rd party behavior that we need to
support, what is the recommended way to deal with this situation (short
of commenting out the code above)??

 

Thanks.