I think that may be inappropriate use of the word "appropriate" (:))
for the following reason: in the real world right now, the practical
situation is that not all browsers support cookies or any similar
mechanism, and if you are on the practical side of this issue, you
need something that will work across the board right now. In theory,
theory and practice may be the same, but in practice, they're not.
This doesn't necessarily mean that only one-size-fits-all solutions
are possible, but it does mean that *for now*, we need solutions that
work with browsers that don't implement client-side state mechanisms.
As an aside to your aside, I'm happy to see things like the cookie
proposal showing up now, and expect to make use of them when possible.
But I can't ditch server-side state mechanisms until all the popular
retrograde browsers of the world (need I name names?) support a
client-side state mechanism.
> What should be done is define a market basket / shelf media type,
> allow this type to be embedded in an HTML document, and let the client
> implement its own methods of manipulating the items in the shelf
> such that they can be dropped in their own basket. The items could
> then include sufficient information regarding payment mechanism and
> cashier URL, such that the transaction of purchasing the items in
> your market basket is simply a POST of that basket + payment info
> to the cashier's URL, suitably encrypted and signed.
>
> In this way, all but the last action is cacheable and the available
> payment mechanisms are made clear prior to the user's purchase action.
>
ITGF. ("In The Glorious Future").
> >In any case, my prefered solution would be to use some response header
> >to indicate the URI of the resource being returned.
>
> That was already decided (for other reasons) at the HTTP-WG meeting
> and is reflected in the new HTTP/1.0 draft 01 at
>
> http://www.ics.uci.edu/pub/ietf/http/
> ftp://www.ics.uci.edu/pub/ietf/http/
> or
> http://www.w3.org/hypertext/WWW/Protocols/Overview.html
>
> See the Location header.
>
Great! I didn't see any mention of using this as the client's cache key in the
spec -- so I hereby redundantly harp on this.
I hope all the *servers* out there will support this. I just tested
Netscape Commerce Server and it works there. Since servers (all?)
generate a 302 response by default when a CGI program returns a
Location header, it can only be hoped that also returning a Status
header will override the default 302.
>
> ....Roy T. Fielding Department of ICS, University of California, Irvine USA
> Visiting Scholar, MIT/LCS + World-Wide Web Consortium
> (fielding@w3.org) (fielding@ics.uci.edu)
>
--Shel Kaphan
sjk@amazon.com