[prev in list] [next in list] [prev in thread] [next in thread] 

List:       httpclient-users
Subject:    Re: Cookie rejection woes..
From:       Roland Weber <http-async () dubioso ! net>
Date:       2006-10-18 17:23:15
Message-ID: 45366303.8000700 () dubioso ! net
[Download RAW message or body]

Hello Karl,

> The response contains the following Set-Cookie headers 
> 
> Set-Cookie: TZS=abc;path=/app;
> Set-Cookie: TZS=abc;path=/service;
> Set-Cookie: TZS=abc;path=/linkto;
> Set-Cookie: TZS=abc;path=/code;
> 
> I have also confirmed these headers by network trace. 
> 
> But I always get 
> 
> WARN  org.apache.commons.httpclient.HttpMethodBase - Cookie rejected: "$Version=0; \
> TZS=abc; $Path=/service". Illegal path attribute "/service". Path of origin: \
> "/app/hdat/" WARN  org.apache.commons.httpclient.HttpMethodBase - Cookie rejected: \
> "$Version=0; TZS=abc; $Path=/linkto". Illegal path attribute "/linkto". Path of \
> origin: "/app/hdat/" WARN  org.apache.commons.httpclient.HttpMethodBase - Cookie \
> rejected: "$Version=0; TZS=abc; $Path=/code". Illegal path attribute "/code". Path \
> of origin: "/app/hdat/" 
> Which confuses me, the cookies are simply being shared between seperate \
> applications, there is no attempt to set for another domain. 

Read the warning again:
  Illegal path attribute "/service". Path of origin: "/app/hdat/"

This has nothing to do with domains, it's about paths. A resource
at /app/hdat/ can set cookies only for path prefixes of /app/hdat/.
If you want to or need to share cookies between resources at /app,
/service, /linkto and /code, then you have to use the common path
prefix, which is /. No resource is allowed to set a cookie it will
not be able to receive, and a cookie set for /service will never
be sent to /app/hdat/.

> But most browsers (in fact all I have tried) work with these cookies. 

That's because many browsers don't care much about specifications.
We do. HttpClient is not a browser:
http://wiki.apache.org/jakarta-httpclient/ForAbsoluteBeginners#head-a110969063be34fcd964aeba55ae23bea12ac232


RFC 2109 is very specific about rejecting cookies in Set-Cookie:

   4.3.2  Rejecting Cookies

   To prevent possible security or privacy violations, a user agent
   rejects a cookie (shall not store its information) if any of the
   following is true:

   * The value for the Path attribute is not a prefix of the request-
     URI.
   ...

RFC 2965 is just as explicit, except that the section is 3.3.2.
Browsers are not supposed to accept those cookies either. Frankly,
in this case I assume that you have missed something when testing
the browsers. Are you sure they don't get a cookie with path /
from somewhere?

> So can I convince HttpMethodBase to work on these.

You can implement a new CookiePolicy. But accepting such illegal
cookies will not be very useful, since they will never be sent back
to the resource that set them. Something is seriously wrong with
the design of the web application.

cheers,
  Roland


---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]