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.