That Cookie thing
It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. peter John Baker wrote: It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 12:59, peter lin wrote: if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. I know this ;-) But I'd forgotten to put the / there, and assumed the browser would assume this if no / was passed to it. However they don't, so I was suggesting that if a Cookie has no path set then one should be written by default as a totally useless header is currently written in the form: Set-Cookie: someName=someValue; expires and due to the lack of a path, every browser ignores it. peter John Baker wrote: It appears if you don't set a path on the cookie (setPath), it doesn't default to anything and therefore doesn't place anything in the response header. Browsers then ignore it ;-) Perhaps Cookie by default should have a path of /. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
that's the problem with assumptions :) Actually I believe the W3C spec says the path will default to directory the pages resides in. So that page /hello/greeting.jsp will have /hello as the path. Only files under /hello can read the cookie. Atleast that's my understanding of how cookie path is supposed to be set. Some one correct me if I am wrong. peter John Baker wrote: On Monday 01 July 2002 12:59, peter lin wrote: if you want the cookies to be readable by all pages, you should set it to /. That's standard practice. Also, if you have multiple webserver with names like www1, www2, www3., you should also set the cookie to use yourbiz.com. I know this ;-) But I'd forgotten to put the / there, and assumed the browser would assume this if no / was passed to it. However they don't, so I was suggesting that if a Cookie has no path set then one should be written by default as a totally useless header is currently written in the form: Set-Cookie: someName=someValue; expires and due to the lack of a path, every browser ignores it. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which this
cookie applies.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore this,
would it be more useful to provide a default in some way so it isn't ignored?
The chances of getting all those three to stick to the spec are low ;-) Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies,
and infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
John Baker wrote: Well a reliable source tells me that there is no w3c spec for Cookies, and infact the concept was conjured by Netscape. There is an RFC spec for Cookies, but it's largely ignored. So as the useful browsers out there ignore Cookie requests without a path, it might be handy to add it by default so other people don't spend an hour or two sitting there thinking Why doesn't this work?. The current context path would be handy, so the response code could look like this: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.ietf.org/rfc/rfc2109.txt Too many specs to keep track of. I disagree the default should be set to /, since that isn't how other web/app servers handle it. I know both websphere and weblogic follow netscapes suggestion. The spec might be bad and probably is, but since that's how most browsers handle it, changing might cause more problems than it solves. just my .2 peter -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:38, peter lin wrote: John Baker wrote: Well a reliable source tells me that there is no w3c spec for Cookies, and infact the concept was conjured by Netscape. There is an RFC spec for Cookies, but it's largely ignored. So as the useful browsers out there ignore Cookie requests without a path, it might be handy to add it by default so other people don't spend an hour or two sitting there thinking Why doesn't this work?. The current context path would be handy, so the response code could look like this: http://wp.netscape.com/newsref/std/cookie_spec.html http://www.ietf.org/rfc/rfc2109.txt Too many specs to keep track of. I disagree the default should be set to /, since that isn't how other web/app servers handle it. I know both websphere and weblogic follow netscapes suggestion. The spec might be bad and probably is, but since that's how most browsers handle it, changing might cause more problems than it solves. just my .2 Yes, / is bad, I think I'll forget that. The default context would be more handy, and a warning would be very handy. But most browsers don't handle it, infact, I can't find one that does (although I've only tried IE/Moz1.0/Konq). But if that collection don't handle it, any cookie sent without a path is almost totally useless. I vote a warning. Warnings are great, they save wasting time. John -- John Baker, BSc CS. Java Developer, TEAM/Slb. http://www.teamenergy.com Views expressed in this mail are my own. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: That Cookie thing
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
No, you don't find out quickly if you don't know what you're doing and you're
newish to web programming. You only find out if you've got a good knowledge
of web browsers and you realise that although path is optional, the majority
of browsers ignore it in some cases. For example, this problem only occurs if
a Cookie will be deleted (setting maxAge to 0) and it has no path. Even the
best web programmers will take some time to figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most browsers
will totally ignore it.
Therefore you've just made many developers very happy with you for providing
such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
Just add something to the docs.. At least we can see rtfm ;) (with
some nice pointers to the specs)
Mvgr,
Martin
On Mon, 2002-07-01 at 14:55, John Baker wrote:
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did and
can fix it.
No, you don't find out quickly if you don't know what you're doing and you're
newish to web programming. You only find out if you've got a good knowledge
of web browsers and you realise that although path is optional, the majority
of browsers ignore it in some cases. For example, this problem only occurs if
a Cookie will be deleted (setting maxAge to 0) and it has no path. Even the
best web programmers will take some time to figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most browsers
will totally ignore it.
Therefore you've just made many developers very happy with you for providing
such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a
path, it might be handy to add it by default so other people don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently written
in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: That Cookie thing
On Monday 01 July 2002 14:03, Martin van den Bemt wrote:
Just add something to the docs.. At least we can see rtfm ;) (with
some nice pointers to the specs)
Quite. Documentation is everything.
But the more I think about it, a newbie logger of some kind could be a great
sell point in terms of making people trust and use Tomcat over other products
(believe it or not, people like http://www.barclays.co.uk and
http://www.elephant.co.uk have picked silly Java servers over Tomcat).
Getting more business using Tomcat would be ace, and stuff like
localhost_moron_log.txt would be a great way to make development even
quicker and businesses happier (ie lower costs).
I'll do some work now ;-)
John
Mvgr,
Martin
On Mon, 2002-07-01 at 14:55, John Baker wrote:
On Monday 01 July 2002 13:53, John Trollinger wrote:
I have to disagree with the default as well.. as that can be dangerous
to someone who simply forgot to supply the path.. this could cause
security issues with where the cookie can be read.. the way is
currently works if you forgot to provide the path a you will find out
quickly that something is not working in the same manor that you did
and can fix it.
No, you don't find out quickly if you don't know what you're doing and
you're newish to web programming. You only find out if you've got a good
knowledge of web browsers and you realise that although path is optional,
the majority of browsers ignore it in some cases. For example, this
problem only occurs if a Cookie will be deleted (setting maxAge to 0) and
it has no path. Even the best web programmers will take some time to
figure out that's wrong.
Therefore although a default is a bad idea, a warning should be provided
clearly in the logs that you've not provided a path, and although the
wishy-washy (noone takes any notice of) spec says that's ok, most
browsers will totally ignore it.
Therefore you've just made many developers very happy with you for
providing such a sensible warning.
John
-Original Message-
From: John Baker [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 01, 2002 8:33 AM
To: Tomcat Developers List
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:29, Tim Funk wrote:
http://wp.netscape.com/newsref/std/cookie_spec.html
OR
http://www.ietf.org/rfc/rfc2109.txt
OR
http://www.ietf.org/rfc/rfc2965.txt
PATH=path
Optional. The Path attribute specifies the subset of URLs to which
this
cookie applies.
But as IE/Moz/Konqueror (anyone else fancy trying some others?) ignore
this,
would it be more useful to provide a default in some way so it isn't
ignored?
The chances of getting all those three to stick to the spec are low ;-)
Or
even a warning in the logs that your code is not likely to work?
Of course, normally I'd say follow the spec, but sadly if your target
audience doesn't, there isn't really much you can do.
John Baker wrote:
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to
directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the
cookie.
Atleast that's my understanding of how cookie path is supposed to
be set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for
Cookies,
and infact the concept was conjured by Netscape. There is an RFC
spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without
a path, it might be handy to add it by default so other people
don't
spend
an hour or two sitting there thinking Why doesn't this work?. The
current context path would be handy, so the response code could
look
like
this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
Just a thought :)
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should
set it
to /. That's standard practice. Also, if you have multiple
webserver
with names like www1, www2, www3., you should also set the
cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed
the
browser would assume this if no / was passed to it. However they
don't,
so I was suggesting that if a Cookie has no path set then one
should be
written by default as a totally useless header is currently
written
in
the form
Re: That Cookie thing
On Mon, 1 Jul 2002, John Baker wrote:
Date: Mon, 1 Jul 2002 13:20:31 +0100
From: John Baker [EMAIL PROTECTED]
Reply-To: Tomcat Developers List [EMAIL PROTECTED]
To: Tomcat Developers List [EMAIL PROTECTED]
Subject: Re: That Cookie thing
On Monday 01 July 2002 13:16, peter lin wrote:
that's the problem with assumptions :)
Actually I believe the W3C spec says the path will default to directory
the pages resides in. So that page /hello/greeting.jsp will have
/hello as the path. Only files under /hello can read the cookie.
Atleast that's my understanding of how cookie path is supposed to be
set. Some one correct me if I am wrong.
Well a reliable source tells me that there is no w3c spec for Cookies, and
infact the concept was conjured by Netscape. There is an RFC spec for
Cookies, but it's largely ignored.
So as the useful browsers out there ignore Cookie requests without a path, it
might be handy to add it by default so other people don't spend an hour or
two sitting there thinking Why doesn't this work?. The current context path
would be handy, so the response code could look like this:
public void addCookie(Cookie c)
{
// whatever
if (c.getPath() == null)
c.setPath(getContextPath());
// etc
}
IMHO, Tomcat should ensure that cookies *it* creates always have a path
(they do), but it's a breach of faith to go messing around with cookies
hand crafted by the application. Those should be assumed to have been set
up exactly the way that the app wanted them. How can the server blindly
assume that the client is a browser that is broken in this respect, and
that all future browser versions will suffer from the same problem?
Just a thought :)
Craig
peter
John Baker wrote:
On Monday 01 July 2002 12:59, peter lin wrote:
if you want the cookies to be readable by all pages, you should set it
to /. That's standard practice. Also, if you have multiple webserver
with names like www1, www2, www3., you should also set the cookie
to use yourbiz.com.
I know this ;-) But I'd forgotten to put the / there, and assumed the
browser would assume this if no / was passed to it. However they don't,
so I was suggesting that if a Cookie has no path set then one should be
written by default as a totally useless header is currently written in
the form:
Set-Cookie: someName=someValue; expires
and due to the lack of a path, every browser ignores it.
--
John Baker, BSc CS.
Java Developer, TEAM/Slb. http://www.teamenergy.com
Views expressed in this mail are my own.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
