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

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.

Browsing back past the carrots to put more apples in your basket will
have the result of the carrots magically disappearing from the basket!
(I assume that the basket contents are not shown on each page, that
you have to follow some link to get a list of the basket contents.)

Thus, in a session-id-in-the-url scheme, shopping basket services had
better store the basket contents in a server side database, and never
change the session-id itself.


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. 

time t  : carrot lover A puts 10 carrots in basket 12345
time t+1: carrot lover B looks at his basket and sees 10 carrots
time t+2: carrot lover B puts 20 carrots in basket 12345
time t+3: carrot lover B looks at his basket and sees 30 carrots!
time t+4: carrot lover B thinks that shop.com is trying to rip him off
          and tells all his friends
time t+5: carrot lover A looks at his basket again and sees 30
          carrots, etc.

More to the point, what can shop.com do to prevent the above if A and
B are behind the same proxy/firewall?  Nothing!

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.

Koen.

Received on Thursday, 27 July 1995 19:08:01 UTC