Re: State Information as HTML attribute (was: session is as part of URL)

At 3:05 PM 7/27/95, Koen Holtman wrote:
>Terje Norderhaug:
>> [...] An example of an URL for this service is
>><URL:http://rohan.sdsu.edu/cgi-bin/terjen/bb/browse?forum=infosandiego&ids=1
>>6018252%5F617> Note how the search part of the URL thus contains both a
>>session id and dynamic state information, and that there is no need for any
>>information about the user to be stored on the service between requests.
>>Also, by using the links for such state information rather than an object
>>on the server, individuals can use the "back" button of the browser without
>>awkward results.
>
>If I embed an encoding of the the shopping basket contents in the URL,
>using the "back" button will have maximally awkward results.

I am of course aware of that, so I am sorry that I was too exclusive in the
last statement. Persistent preferences and shopping baskets are not suited
to implement as part of the URL of a specific page, as their scope includes
documents browsed before the state change (as mentioned below in the
commented message). What I had in mind were that after backtrack the status
information on the server possible would be out of sync with what the
reader view on the browser, which might yield awkward results in those
cases where you want the user to have consistent results from following
links on earlier pages. Sometimes you want people to be able to back up to
a previous state.

I have at no time meant to indicate that attaching states to links are a
comprehensive solution to state management. The proposal of attaching
parameters for state changes to anchors is intended to be combined with
session-wide state maintenance on http-level.

>Also, what happens if someone puts
><a href=http://shop.com/vegetables/carrots.html?id=12345>
> A place where you can buy carrots</a>
>
>on the `carrot lovers home page'?  If two carrot lovers follow this
>link at about the same time, they both end up with shopping basket
>#12345. [...]
>More to the point, what can shop.com do to prevent the above if A and
>B are behind the same proxy/firewall?  Nothing!

There are ways to get around this problem. The id can be created as a
random number and expire after a certain time, to avoid multiple users with
the same id. Not to mention that we already have  "session ID" in use for
such shopping cases: The name and the password of the user after loging in
to a server.

The implementation I used as example (the forum service) currently use ids
in URLs because of the lack of better alternatives (in fact, I only use it
for analyzing patterns in how people are browsing such a service, so I can
improve the interface accordingly).

>This is yet another reason why we need real session-id support in
>http.  If the session-id were outside the URL, the above could not
>happen.

I rather talk about state information for now, as this is what I proposed
to be attached to links. I have already mentioned that state information
attached to links should be combined with a state mechanism that takes care
of keeping a state for a larger scope than one document. This makes state
information on anchors to work as STATE CHANGES relative to the current
document.

Hyperlinks in themselves can also be viewed as suggested state changes
relative to the current document. However, URLs are more appropriate to
locate a service than to describe state changes, and are relatively static
despite their ability to add information to the search path. Moving
information about state changes out from the URLs search path and into a
new attribute will provide a better way to make services based on dynamic
state changes that are relative to the current document.

How should session-wide scoped state information be implemented so it best
can co-operate with such a scheme for attaching state changes to HTML
anchors?


-- Terje <Norderhaug.CHI@Xerox.com>
   <URL:http://www.ifi.uio.no/~terjen/>

Received on Friday, 28 July 1995 13:50:02 UTC