shopping baskets w/o dynamic documents (proposal)
In message <199606132326.QAA08881@server.livingston.com> 13 Jun 1996 16:26:36, email@example.com wrote:
> Once upon a time Daniel Glazman shaped the electrons to say...
> >Sorry to disturb but is it the right place to submit a proposal
> >of HTML and HTTP extension about WWW shopping baskets management ?
> Pretty much here or www-talk
Ok, so let's go. Please apologize 1) the cheek 2) the poor quality
of my english 3) the general state of the document, it's only the
first (and maybe the last) sketch of the first draft of an idea ;-)))
The proposal is about a **very** cheap way of implementing shopping baskets
__without__ cgi-bins bulding dynamic documents. I guess everyone can
immediately see the impact on the server's load. The proposal does not
deal with "identification" but only "ID attribution".
A W3C draft has been issued quite on the same subject in february (see
document's references) but does not seem to generate a lot of discussions.
The contents of my proposal is a bit different because it leaves to HTML
the full control of ID attribution and is based on a new HTTP method.
If implemented, we'll (EDF) surely be the first to use it !!! We're a bit tired
of dynamic shopping basket management.
Hardly waiting for your comments....
Best regards from a sunny Paris, France.
</D.Glazman>, webmaster @ Electricité de France, R&D Division
A simple mechanism of HTML and HTTP extension
for WWW commercial applications using
Electricité de France, R&D Division
13 June 1996
Many applications on the World Wide Web absolutely need
that an ID is attributed to each visitor. The most frequent
case is the "shopping basket" which actually implies strong
use of cgi-bin and dynamic documents.
This document proposes a new technical solution to this problem
based on a new HTML element, one new HTTP method and two new
Since the explosion of the World Wide Web at the end of 1994 and
the emergence of commercial activities on the Internet, no
mechanism has been designed to fill the gap of ID attribution
even if the HTTP protocol contains authorization schemes.
ID attribution means that a server is able to give an unique
ID to each visitor, the client's browser is able to retrieve
this unique ID from the server and use it while navigating in
This document contains a simple proposal for HTTP ID attribution
based on a HTML extension and a HTTP extension. This proposal
differs from [Session-ID] W3C working Draft because the mechanism
described in W3C draft mixes authentication and ID attribution.
The present document keeps these two concepts unlinked.
Furthermore, it gives the control of ID attribution to HTML and
client's human manipulator.
2. HTML extension
It is proposed to add the new element REQID to the contents
of HEAD element in current HTML 3.2 draft.
This element holds the following attribute :
<!ELEMENT REQID - O EMPTY>
NAME CDATA #IMPLIED
SHOWN (SHOWN) #IMPLIED
This element, when parsed by a browser after a real net
connection, means that the browser should issue a HTTP
request asking an ID to the remote server.
NAME attribute contains a name associated to the to-be-
SHOWN attribute when present indicates that the ID attributed
by server should be shown to the human being manipulating the
client, using for instance a popup window. The message could
then use the value of NAME to make it more readable.
This ID will be used for all following HTTP requests provided
the new header field SolicitorID.
3. HTTP extension
When a browser parses a HTML document containing a REQID element
in its HEAD, it should issue a HTTP request to the document's
URL using the RQID method.
Example: the client has requested the document
http://www.foo.com/new/doc.htm and this document contains a REQID
element. The browser should then issue a HTTP/1.1 request :
RQID http://www.foo.com/new/doc.htm HTTP/1.1
User-Agent: my best browser v12
No Entity-body should be provided in these RQID requests.
The server's HTTP response to these requests introduces new
answer codes :
* 207 ID attributed
The server has attributed a new unique ID to visitor in response
to client's request. The value of the new HTTP field SolicitedID
contains this ID.
* 506 no ID available
The server is unable to answer to client's demand and attribute
Server's response to RQID request may contain a informational
When obtaining an ID from the server, a client should integrate
a new field SolicitorID in all its HTTP requests to this server
whatever is the HTTP method.
For instance :
RQID http://www.shoppingmall.xx/ HTTP/1.1
HTTP/1.1 207 ID attributed
following client's requests
<method> <URL> HTTP/1.1
A new error status code is then needed :
* 416 improper ID
The SolicitorID value contained in the request is not
recignized by the server. Client should issue a new RQID
request and obtain a new ID.
ID values could be formed using the syntax described in
[Session-ID] or remain strictly site-dependant.
4. Common Gateway Interface
It is suggested that a new variable HTTP_SOLICITOR_ID be
provided to CGI/1.1 compliant applications, containing
the value of the HTTP request's field SolicitorID, if provided.
This value would be mainly used when filling the shopping
basket with a new item and when issuing the order.
The mechanism described above, if implemented in HTTP servers
and browsers, makes the implementation of commercial activities
using shopping baskets possible at a very low cost. Because
no cgi-bin building dynamic documents is needed in such a technical
solution, the server's and traffic's load should also descrease
in a significant way.
Research Engineer, Webmaster
Electricité de France, Research & Developement Division
1 avenue du Général de Gaulle
F-92141 CLAMART CEDEX
Phone: +33 1 47 65 35 70
Fax: +33 1 47 65 35 23
Phillip M. Hallam-Baker, Dan Connolly
"Session Identification URI"
W3C Working Draft WD-session-id-960221
R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, T. Berners-Lee
"Hypertext Transfer Protocol -- HTTP/1.1"