hc-httpclient-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: cookie paths (was: Can someone please explain what these errors mean?)
Date Thu, 17 Feb 2005 11:04:43 GMT
Cmon, Roland

You SERIOUSLY would not mind /evil-russian-mafia application sending
session cookies to /goodie-goodie-american-co application co-hosted on
the same server WITHOUT Goodie Goodie American Co consent? ;-)

Think twice next time you place an order on Amazon.


On Thu, Feb 17, 2005 at 11:50:07AM +0100, Roland Weber wrote:
> Hi Oleg,
> 
> you are allowed to disagree ;-)
> 
> If /app1 and /app2 want to share a session, the session cookie
> must be set with path "/" by either of them. 

What if one of them does not?

If they don't want
> to share a cookie, they set it with their own prefix /app1 or /app2.
> 
> If cookies collide by name, RFC 2965 says (page 12, top) that
> the one with the more specific path must come first in the
> header. So the cookie "MYOMY" with path /app1 will be found
> before the cookie "MYOMY" with path /. That helps to resolve
> collissions between cookies with different paths.
> 
> To pick up your interpretation, if /app1 was allowed to set a
> cookie for /app1/whatever/, how is it supposed to receive that
> cookie ever again?

By specifying /app1 as a cookie path attribute. Please take a look at
the original Netscape cookie draft. It is slightly more human readable
than those RFC that take a PhD Stanford to interpret. See examples given
in the draft

http://wp.netscape.com/newsref/std/cookie_spec.html

Oleg the Evil Cookie Ayatollah 

The prefix condition in my interpretation
> makes sure that the one who sets a cookie will always be
> allowed to get it back.
> 
> cheers,
>   Roland
> 
> 
> 
> 
> 
> Oleg Kalnichevski <olegk@apache.org> 
> 17.02.2005 11:28
> Please respond to
> "HttpClient User Discussion"
> 
> 
> To
> HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> cc
> 
> Subject
> Re: cookie paths (was: Can someone please explain what these errors mean?)
> 
> 
> 
> 
> 
> 
> Roland,
> With all due respect allow me to disagree. I see it absolutely the other
> way around.
> 
> Since we talk examples, consider the following: you have two web apps 
> hosted by the same web server with different URL prefixes
> 
> /app1
> /app2
> 
> I seriously doubt you'd want a cookie set by /app1 to be sent tp /app2
> 
> Cheers,
> 
> Oleg
> 
> 
> On Thu, Feb 17, 2005 at 11:19:46AM +0100, Roland Weber wrote:
> > Hi Oleg,
> > 
> > then I was misinterpreting you. Let's put in some examples:
> > 
> > > RFC 2109
> > > 
> > > <quote>
> > > 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.
> > > 
> > > </quote>
> > 
> > request-URI:    /Canada/whatever.asp
> > Path attribute: /
> > 
> > The Path attribute "/" of the received cookie is a prefix of the 
> > request-URI
> > "/Canada/whatever.asp" from where it is set, so the cookie will not be 
> > rejected.
> > 
> > In other words, a servlet can set cookies with a path shorter than
> > it's own, but not longer than or different from it's own.
> > 
> > cheers,
> >   Roland
> > 
> > 
> > 
> > 
> > 
> > Oleg Kalnichevski <olegk@apache.org> 
> > 17.02.2005 11:10
> > Please respond to
> > "HttpClient User Discussion"
> > 
> > 
> > To
> > HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> > cc
> > 
> > Subject
> > Re: cookie paths (was: Can someone please explain what these errors 
> mean?)
> > 
> > 
> > 
> > 
> > 
> > 
> > Roland,
> > 
> > I still think the wording of the RFCs implies that "/Canada/" 
> > matches "/" but not the other way around. A cookie with a path attribute
> > "/Canada" can be set at the URL "/", but not visa versa.
> > 
> > Oleg
> > 
> > 
> > On Thu, Feb 17, 2005 at 10:43:51AM +0100, Roland Weber wrote:
> > > Hi Oleg,
> > > 
> > > speaking from a string perspective, "/" is a prefix of both,
> > > "/Canada" and "/Canada/whatever.asp". RFC 2965 mentions
> > > string-matching for paths on top of page 2.
> > > 
> > > cheers,
> > >   Roland
> > > 
> > > 
> > > 
> > > 
> > > 
> > > Oleg Kalnichevski <olegk@apache.org> 
> > > 17.02.2005 10:31
> > > Please respond to
> > > "HttpClient User Discussion"
> > > 
> > > 
> > > To
> > > HttpClient User Discussion <httpclient-user@jakarta.apache.org>
> > > cc
> > > 
> > > Subject
> > > Re: cookie paths (was: Can someone please explain what these errors 
> > mean?)
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > RFC 2109
> > > 
> > > <quote>
> > > 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.
> > > 
> > > </quote>
> > > 
> > > Please correct me if I am wrong but the first point implies that a CGI
> > > at the url "/Canada/whatever.asp" may only set cookies with path
> > > starting with "/Canada/". Am I misreading the RFC?
> > > 
> > > Evil Comrade Oleg (a.k.a cookie ayatollah)
> > > 
> > > 
> > > On Thu, Feb 17, 2005 at 10:17:47AM +0100, Roland Weber wrote:
> > > > Hi Oleg,
> > > > 
> > > > > A cookie with "/" path attribute may not be
> > > > > set from a URL other than "/". 
> > > > 
> > > > my understanding is that a cookie with path "/" may be set from any 
> > URL 
> > > > with
> > > > path prefix "/". RFC 2109 mentions the prefix requirement in section 
> 
> > > 4.3.2
> > > > on page 6. So does RFC 2965 in section 3.3.2 on page 8. Unlike with 
> > > domain
> > > > names, there is no "reach" restriction that would prevent a servlet 
> at
> > > > /where/ever/it/may/reside to set a cookie for / on that host, which 
> > > would
> > > > be the same as setting a cookie without any path at all.
> > > > 
> > > > cheers,
> > > >   Roland
> > > 
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: 
> httpclient-user-help@jakarta.apache.org
> > > 
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> > 
> > 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
> 
> 

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


Mime
View raw message