Re: session-id redux

Dave Hollander (dmh@hpsgml.fc.hp.com)
Wed, 26 Jul 1995 11:19:22 -0600

Daniel DuBois replied:

> Get the clients who access your site to use the From: header.
> All the personal touch you want can be had with that information: User
> profiles, user-specific pages, everything. You can even get consenting
> users to fill out registration forms with their zodiac sign and favorite
> color if you want.
>
> Users concerned about privacy won't send their From: or Referer: headers,
> and don't want you knowing their click-stream anyway. Bonus: There headers
> items are already spec'd, and everyone agrees on what they do, and should do.

The from field would help a lot, if it was widely implemented. The spec
calls for a valid Internet address, to the uniqueness requirement would
be satisfied.

This approach would put more load on the server to determine session
specific behavior, but this would be better than now.

ref: http://www.w3.org/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html

>
> >is interested, I could try to list what benefits I would hope to get from a
> >extensible sessioning standard. They go far beyond the current "clickstream"
> >discussion.
>
> You're probably right, there are benefits for 'knowing your customer'. So
> run an Xterm app on your users' displays, or run a telnet-able bbs site, or
> hack HTTP into a stated machine with CGI scripts (or a specialized server)
> and the From: header.
> -----

The first two are not acceptable. xterm apps and bbs increase the user
complexity and reduce the robustness of the user interface. They do not
address the bigger issue of helping us publish a variety of information
and then help the user find the info right for them.

I could hack HTTP and will probably have to. I suspect that I will end
up with session-munged-URLs even though I believe this to be a fools path.
Perhaps I need to follow up on Paul B's idea of session state documents
instead of munged URLs. I expect that technique is stronger but harder to
develop without browser and server developer support.

My point, and the original poster's, was that this group may wish to see
that ad-hoc solutions to session issues are not in the best interest of
the web and should be addressed.

Regards,
Dave Hollander

_________________________________________________________________________
Dave Hollander Hewlett-Packard
Internet Technology Program Manager 3404 East Harmony Road, MS. 6U10
dmh@corp.hp.com Fort Collins, Colorado 80525
Access HP - http://www.hp.com 970-229-3192
_________________________________________________________________________