You are viewing a plain text version of this content. The canonical link for it is here.
Posted to httpclient-users@hc.apache.org by Roland Weber <RO...@de.ibm.com> on 2005/02/17 10:17:47 UTC
Re: cookie paths (was: Can someone please explain what these errors mean?)
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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
never mind. You came pretty close to convincing me :-)
cheers,
Roland
Oleg Kalnichevski <ol...@apache.org>
17.02.2005 14:27
Please respond to
"HttpClient User Discussion"
To
HttpClient User Discussion <ht...@jakarta.apache.org>
cc
Subject
Re: cookie paths (was: Can someone please explain what these errors mean?)
> the client to the server. Here, I fully agree with you. A cookie
> for /app1 is sent only to /app1/*. But I still say that the cookie
> can have been set by /app1/screens/login.jsp in the first place.
>
All right. You are right. I was wrong. I confused the algorithm of
rejecting cookies with that of matching cookies. Sorry. Ayatollahs err too
Oleg
> > I have no problem with being proven wrong. I can err as any mortal
> human.
>
> Since we cannot agree on a common interpretation of the RFC,
> I doubt either of us can prove the other wrong :-) Referring
> to the implementation, the last check in method validate(...)
> of CookieSpecBase does not match your interpretation, does it?
>
>
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java?view=markup
>
> cheers,
> Roland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
> the client to the server. Here, I fully agree with you. A cookie
> for /app1 is sent only to /app1/*. But I still say that the cookie
> can have been set by /app1/screens/login.jsp in the first place.
>
All right. You are right. I was wrong. I confused the algorithm of
rejecting cookies with that of matching cookies. Sorry. Ayatollahs err too
Oleg
> > I have no problem with being proven wrong. I can err as any mortal
> human.
>
> Since we cannot agree on a common interpretation of the RFC,
> I doubt either of us can prove the other wrong :-) Referring
> to the implementation, the last check in method validate(...)
> of CookieSpecBase does not match your interpretation, does it?
>
> http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java?view=markup
>
> cheers,
> Roland
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
> Think of session cookies. Most of browsers do not include the path
> attribute when sending cookies to the server. If the scheme you
> are suggesting were correct a servlet engine would not be able to
> distinguish session ids of individual web applications
That is correct. All web applications use the same session ID.
They keep different session objects in memory, so their data
remains separate. What ID is used does not really matter.
> Please do take a look at the Netscape draft:
>
> path=PATH
> The path attribute is used to specify the subset of URLs in a
> domain for which the cookie is valid. If a cookie has already
> passed domain matching, then the pathname component of the URL is
> compared with the path attribute, and if there is a match, the
> cookie is considered valid and is sent along with the URL request.
> The path "/foo" would match "/foobar" and "/foo/bar.html". The path
> "/" is the most general path.
>
> RFC 2109 meant to say pretty much the same
Yes, that's for selecting those cookies that get sent back from
the client to the server. Here, I fully agree with you. A cookie
for /app1 is sent only to /app1/*. But I still say that the cookie
can have been set by /app1/screens/login.jsp in the first place.
> I have no problem with being proven wrong. I can err as any mortal
human.
Since we cannot agree on a common interpretation of the RFC,
I doubt either of us can prove the other wrong :-) Referring
to the implementation, the last check in method validate(...)
of CookieSpecBase does not match your interpretation, does it?
http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/httpclient/trunk/src/java/org/apache/commons/httpclient/cookie/CookieSpecBase.java?view=markup
cheers,
Roland
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Thu, Feb 17, 2005 at 01:12:47PM +0100, Roland Weber wrote:
> Hi Oleg,
>
> Amazon controls all their applications :-) Seriously, when
> you deploy web modules on a single host, you have to
> take care that these modules interact well. For co-hosting,
> you better use different host names.
Think of session cookies. Most of browsers do not include the path
attribute when sending cookies to the server. If the scheme you
are suggesting were correct a servlet engine would not be able to
distinguish session ids of individual web applications
> If you want to prevent the kind of cross-path-cooking
> attack you describe, that has to happen on the server.
> The browser/client will never be able to tell whether two
> paths belong to different applications or to different parts
> of the same application.
They can't and they are not supposed to. They just have to follow the
cookie spec. This is precisely the reason for disallowing cookie with a
more genetric path attribute, eg "/app1/stuff", originating from a URL
like "/app/stuff/morestuff/myapp.asp".
>
> Ok, one last example. You write a servlet and deploy it
> with servlet mapping /app1/*. That means all requests
> below /app1/ end up being served by that same servlet.
> Surely, you would expect the servlet to be able to set
> a cookie for /app1, even if the request URI is
> /app1/with/extra/information/and/some ?
No, I would not. I have been acting Evil Cookie Ayatollah for quite a
while already ;-)
Please do take a look at the Netscape draft:
path=PATH
The path attribute is used to specify the subset of URLs in a
domain for which the cookie is valid. If a cookie has already
passed domain matching, then the pathname component of the URL is
compared with the path attribute, and if there is a match, the
cookie is considered valid and is sent along with the URL request.
The path "/foo" would match "/foobar" and "/foo/bar.html". The path
"/" is the most general path.
RFC 2109 meant to say pretty much the same
>
> If that doesn't convince you, you've won this argument.
> (Which doesn't mean you're right ;-)
I have no problem with being proven wrong. I can err as any mortal human.
Cheers,
Oleg
>
> cheers,
> Roland
>
>
>
>
>
> Oleg Kalnichevski <ol...@apache.org>
> 17.02.2005 12:04
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@jakarta.apache.org>
> cc
>
> Subject
> Re: cookie paths (was: Can someone please explain what these errors mean?)
>
>
>
>
>
>
> 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 <ol...@apache.org>
> > 17.02.2005 11:28
> > Please respond to
> > "HttpClient User Discussion"
> >
> >
> > To
> > HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > > 17.02.2005 11:10
> > > Please respond to
> > > "HttpClient User Discussion"
> > >
> > >
> > > To
> > > HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > > > 17.02.2005 10:31
> > > > Please respond to
> > > > "HttpClient User Discussion"
> > > >
> > > >
> > > > To
> > > > HttpClient User Discussion <ht...@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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-user-help@jakarta.apache.org
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
Hi Oleg,
Amazon controls all their applications :-) Seriously, when
you deploy web modules on a single host, you have to
take care that these modules interact well. For co-hosting,
you better use different host names.
If you want to prevent the kind of cross-path-cooking
attack you describe, that has to happen on the server.
The browser/client will never be able to tell whether two
paths belong to different applications or to different parts
of the same application.
Ok, one last example. You write a servlet and deploy it
with servlet mapping /app1/*. That means all requests
below /app1/ end up being served by that same servlet.
Surely, you would expect the servlet to be able to set
a cookie for /app1, even if the request URI is
/app1/with/extra/information/and/some ?
If that doesn't convince you, you've won this argument.
(Which doesn't mean you're right ;-)
cheers,
Roland
Oleg Kalnichevski <ol...@apache.org>
17.02.2005 12:04
Please respond to
"HttpClient User Discussion"
To
HttpClient User Discussion <ht...@jakarta.apache.org>
cc
Subject
Re: cookie paths (was: Can someone please explain what these errors mean?)
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 <ol...@apache.org>
> 17.02.2005 11:28
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > 17.02.2005 11:10
> > Please respond to
> > "HttpClient User Discussion"
> >
> >
> > To
> > HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > > 17.02.2005 10:31
> > > Please respond to
> > > "HttpClient User Discussion"
> > >
> > >
> > > To
> > > HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@apache.org>
> 17.02.2005 11:28
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > 17.02.2005 11:10
> > Please respond to
> > "HttpClient User Discussion"
> >
> >
> > To
> > HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > > 17.02.2005 10:31
> > > Please respond to
> > > "HttpClient User Discussion"
> > >
> > >
> > > To
> > > HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
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. 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? 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 <ol...@apache.org>
17.02.2005 11:28
Please respond to
"HttpClient User Discussion"
To
HttpClient User Discussion <ht...@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 <ol...@apache.org>
> 17.02.2005 11:10
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > 17.02.2005 10:31
> > Please respond to
> > "HttpClient User Discussion"
> >
> >
> > To
> > HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@apache.org>
> 17.02.2005 11:10
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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 <ol...@apache.org>
> > 17.02.2005 10:31
> > Please respond to
> > "HttpClient User Discussion"
> >
> >
> > To
> > HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
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 <ol...@apache.org>
17.02.2005 11:10
Please respond to
"HttpClient User Discussion"
To
HttpClient User Discussion <ht...@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 <ol...@apache.org>
> 17.02.2005 10:31
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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 <ol...@apache.org>
> 17.02.2005 10:31
> Please respond to
> "HttpClient User Discussion"
>
>
> To
> HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Roland Weber <RO...@de.ibm.com>.
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 <ol...@apache.org>
17.02.2005 10:31
Please respond to
"HttpClient User Discussion"
To
HttpClient User Discussion <ht...@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
Re: cookie paths (was: Can someone please explain what these errors mean?)
Posted by Oleg Kalnichevski <ol...@apache.org>.
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