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

"Balint Nagy Endre" <bne@bne.ind.eunet.hu> wrote (on 8/27):
[in response to my I-D]:
        
  > 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?)

There is no intention to force the client to refresh the "shopping basket
page".  The current state is carried in the State-Info header, and the
user can select a link that, when passed the State-Info header, will
show the current shopping basket page.

  > 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"

No mechanism is required.  The algorithm is that the user agent ALWAYS
sends State-Info to a server that it has previously received a State-Info
response from.

  > 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.

I don't think the optimization itself adds major complications to
caches.  Koen Holtman proposed using the existing "don't cache"
mechanisms, instead of giving special meaning to State-Info, and that
alternative should satisfy your objection.

  > (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

Yes, the effect of extensions on caches is poorly defined.  That's why
the I-D was explicit about what a cache is supposed to do with State-Info.

  > (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'.

Dave Kristol

Received on Monday, 28 August 1995 11:02:28 UTC