On Mon, 2001-11-12 at 13:56, Chuck Esterbrook wrote:
> On Monday 12 November 2001 07:57 am, Mike Orr wrote:
> > The PHPLib way seems to be that it always sends the session ID with the
> > URL at the first request, while also sending a cookie. Then at
> > subsequent requests, it checks whether the cookie was received. If yes,
> > it doesn't need the URL session ID so it stops sending it. If no, it
> > continues sending the session ID in the URL.
> That's the standard trick and the only one I'm actually aware of.
There might be something with web bugs. I figure such a bug is one of
enabled. Maybe it can do double duty with cookies too? Maybe if
someone doesn't have a session set, send them their new session ID, and
The first page will still have to have SIDs in all the links, and every
page will have to have support for setting this up, so I don't know if
this provides any benefit, or is even substantially different.
> > Somehow it also manages to recover when cookies are turned off in the
> > middle of the session. I'm not sure how.
> I don't believe you. :-)
> Except for form submission. It could embed the id in each form which could mitigate the problem, but not solve it.
Well, maybe the way it works is:
If you get a request that includes no SID, immediately redirect the user
to the page + SID. Also set the SID cookie (but there's a bug in IE
regarding cookies and redirects, isn't there? Or is it just an
Apache/IE conflict that might be resolvable?)
That won't exactly recover the session, though. Anyway, if you are
willing to pay a two-redirect penalty for the first page view, you could
get a concrete answer. I.e., user requests /startpage, redirect
/detect/startpage?SID=xxxx, if you don't get a cookie redirect to
/SID=xxxx/startpage, else redirect right back to /startpage. This
wouldn't require any HREF munging, but would leave clean URLs when
possible. If you only use relative URLs, which I find difficult.