http://www.pathfinder.com/@@VFNihgAAAAAAQDIL/pathfinder/Quick_Navigator.html
The '@@VFN...' part is (as one quickly discovers by connecting to the
root page multiple times) a session ID. The software that does this,
by the way, is a beta of a commercial server product which may very
well be turning up elsewhere in the not-so-distant future.
It is interesting to evaluate this mechanism (which hews to the strict
letter of the status-quo HTTP spec) by the standards which have been
used to evaluate other session-id proposals here:
Privacy ---
It's subject to all the abuses which anyone here has imagined. In
particular, whatever state the server is keeping, keyed by session
id, remains inherently invisible to the user --- as opposed to
something like the Netscape cookie proposal, where (at the very
least) the path of least resistance is to keep state at the client
side, where cooperative client software *could* (and more notably,
could be encouraged to) make that state available for inspection.
Caching and network-friendliness ---
One objection that has been made to session-id proposals is that
they keep documents from being cached, because the session-id has
to go to the root server.
Well, guess what folks --- this is even *worse*. Since the
session-id is made part of the URL, caching is effectively blocked
here --- but the caches don't know that! These documents are
served up with correct Last-modified: headers, and without any
Expires: data, which means that caching proxies will try to cache
them --- and get their databases filled with redundant copies of
the same documents, which will inhibit their ability to cache,
well, cache-able stuff.
Ease of implementation ---
Well, here's one case in which this hack *seems* to score high,
sorta kinda --- it does, after all, work now. However, if kludges
like this become more widespread, other software may be adapted to
deal with them semi-intelligently (caches in particular may want to
avoid the problems discussed above), with results which will not be
terribly pretty, and will probably be more of a headache for
everybody than a session-id mechanism which was thought through
from the start.
For what it's worth, I tend to like the Netscape cookie proposal ---
it allows clients to inspect the state (which makes it somewhat more
benign than the alternatives, from a privacy perspective --- although
it would be nice if the client had a menu entry someplace which showed
you the cookies), and the machinery to handle it at the client side
must be present in at least a rudimentary form to cache credentials
for HTTP authentication (even Basic auth).
Also, it has been widely deployed already, and used with success by
many groups (at least two groups that I'm *personally* acquainted
with, in addition to Netscape's own very busy site) --- something
which, in my view, ought to carry considerable weight among standards
groups when comparing it to alternatives which have been designed by
committee, and with which there is no practical experience.
However, regardless of the details, you have two basic alternatives
--- to do something, or to do nothing. If you do nothing, that won't
stop people who need session-ids from creating them --- it will just
push them into doing stuff like the Pathfinder hack, or requiring
authentication where it isn't strictly needed solely to be able to
track people (and creating better tracking databases in the process,
since almost all such systems ask the client to identify themselves
when registering for an ID).
In short, failing to endorse a session-id proposal won't save the Net
from the problems of having session ID's --- rather, it will force
people to create forms of session-id which you can't regulate, as
such, because at the protocol level it's pretending to be something
different.
To put it another way, the ostrich approach to, say, the privacy
issues with session-id won't work at all. If you're concerned, try
something else.
rst