Yeah it works on all the clients, but it's a pain in the ass to do relative 
URLs when manipulating PATH_INFO.  So it's not necessarily trivial to 
program and maintain unless you pass everything through a monolithic CGI.

Of course, on Apache it may be easier by using mod_rewrite to manipulate 
the URL itself in cool ways.

Another problem with non-cookies based is if the user leaves the website 
for a brief period and wants to come back. Of course, in this case, it may 
not be a requirement.

One thing I would add to support Manfred's stance on cookies is that not 
all clients support cookies ... eg PDAs, mobile phones... But, again, if 
you control your clientele maybe it doesn't matter.

However, as for users that hate cookies -- well, I think it's all over but 
the crying. I think cookies have kind of been forced in vogue by IIS/ASPs 
and Servlets doing session cookies by default... So a lot of developers 
(and there are a lot on ASPs that don't know what they are doing) program 
websites with ASPs and rely on cookies for session ids.

Later,
     Gunther

At 09:44 AM 4/20/00 +0200, Manfred Dehnkamp wrote:
> Hy,
> why do you use cookie's ??? A lot of people hate them.
> I think a much better Idea is to put your sessionID in the PathInfo
> of every requested URI.
> So after the login your CGI generates a SessionID. Lets say your
> CGI has the URI http://domain/mycgi.
> After the login the cgi's output is just a refresh HTML page :
> than if you have a "secure" html tree which the loggedin client will be
> able to use,  its very simple :
> alle hyperlinks within that tree must be referenced RELATIVE !!!
> So the browser will always put "mycgi/sessioniD" on "top" of every hyperlink
> !!!!!
> To make it secure : Your script needs to have its own "Documentroot"
> which is only readable by your cgi......
> (=> so your cgi has to read the pathinfo to get the sessionid and the 
> requested
> action/File. The file you have to read with your cgi. ...)
> Everytime the client ist "using" that sessionID you can "touch" it after
> checking it.
> Than you just need a garbagecollector which will destroy every sessionID after
> 5 (10,20...) Minutes wihout touch.
> I think that solution is much better than cookies : it works on EVERY 
> client !!!
> 
> (its of course possible to let the user sign out .. logout.. that should 
> destroy
> the session as well !!)
> 
> with kind regard
> 
> Manfred Dehnkamp
> 
> 

__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/