Re: I-D ACTION:draft-kristol-http-state-info-00.txt, .ps

Dave Kristol writes:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.                                                               
> 
>        Title     : Proposed HTTP State-Info Mechanism                      
>        Author(s) : D. Kristol
>        Filename  : draft-kristol-http-state-info-00.txt, .ps
>        Pages     : 7
>        Date      : 08/23/1995
> 
> HTTP, the protocol that underpins the World-Wide Web (WWW), is stateless.  
> That is, each request stands on its own; origin servers don't need to 
> remember what happened with previous requests to service a new one.  
> Statelessness is a mixed blessing, because there are potential WWW 
> applications, like ``shopping baskets'' and library browsing, for which the
> history of a user's actions is useful or essential.                    
Fine. The addressed goals are important, and we really need some kinda
'states' in http.
> This proposal outlines a way to introduce state into HTTP.  A new 
> request/response header, State-Info, carries the state back and forth, thus
> relieving the origin server from needing to keep an extensive per-user or 
> per-connection database.  The changes required to user agents, origin 
> servers, and proxy servers to support State-Info are very modest.          
My objections:
1. The proposal (and now the draft) doesn't solve the most serious trouble of
shopping-basket applications:
how can the client application be forced to refresh the 'shopping basket page'
every time? We have the no-cache pragma to prevent cacheing, but the semantics
of the pragma is not clear enough now, and I haven't seen the http 1.1 draft. 
(Roy Fielding published the semantics of the pragma on this list, but we don't
have a formal draft describing that semantics yet - perhaps we should wait a
bit for 1.1 draft?)
2. we have no mechanism to tell client applications, when state-info should
be present in a request. (I see a possible solution, namely the "METHODS"
attribute in anchor html tag - see workinprogess
URL: ftp://ds.internic.net/internet-drafts/ draft-ietf-html-spec-05.txt - by
extending METHODS to use GET/State-info and POST/State-Info, e.g. change
methods to method/extension in that draft, but this needs consensus from html
WG. GET/State-Info would mean 'shopping basket page', and POST/State-Info
would mean shopping, but shopping is only an example, other types of stateful
dialogs and other method/extension pairs are possible.)
3. The current discussion on 'possible optimisation to state-info proposal'
tends to make the situation worse: 
trying to solve one problem introduces new requirements to caches.
(And we have 3 other similar proposals mentioned in Dave Kristols draft + Secure
method in draft URL:
ftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-00.txt - this may
result in an overkill for cache implementors! Even worse, the S-HTTP proposal 
doesn't contain the word cache. It would be wise at least to state that
S-HTTP actions aren't cacheable at all, or even better, to require a private
pragma in every S-HTTP response).
Using 'Pragma: private' in responses to 'POST/State-Info' requests may be a
more graceful solution, and tagging 'shopping basket' URL-s with
'Pragma: no-cache' or 'Pragma: Dynamic' and METHODS attribute 'GET/State-Info'
can solve both 1. and 2.
(I don't know if distinguishing dynamic and no-cache pragmas are necessary or
not. The distinction may be useful in their impact on browsers history
mechanism.)
My objections are partially motivated by viewpoint of caching proxy
administrator/implementor, and address the more general question of http
extension's effect on caches. If we require explicit statement of
(non)cacheability in http extensions by requiring the presence of the
appropriate pragmas/headers, cache implementations may remain useful in the
long run, otherwise every new http extension may render current cache
implementations non-compliant. If not only I consider that possibility
unwanted, we shall add a paragaph to the draft on subject 'requirements to
http extensions'.

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>

Received on Sunday, 27 August 1995 15:44:02 UTC