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:
> > > > >>>
> > > > >>>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]>

-- 
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]>

Reply via email to