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]