W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1995

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

From: Balint Nagy Endre <bne@bne.ind.eunet.hu>
Date: Wed, 27 Sep 1995 11:28:03 +0100 (MET)
To: dmk@allegra.att.com
Cc: http WG <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
Message-Id: <92.bne@bne.ind.eunet.hu>
this version of state-info draft is fine, I suggest only a minor

In section talking on caches, you recommended the use
Cache-Control: no-cache and pre-expiration.

I think, the suggested usage should be:
... Generally a *response* that has associated State-Info header should not
be cached: either the entity body or the State-Info in the response usually
is specific to a particular user. The origin server MUST notify intermediate
caches not to cache them. To inhibit caching, the origin server SHOULD use
one of the standard mechanisms that inhibit caching such as
Cache-Control: private, Cache-Control: no-cache *and* Expires: <yesterday>.

NOTE: It is unsafe to permit caching of the 'entry and exit doors' of the
domain belonging to a stateful dialog, because a cached empty State-Info
can move clients to "no State-info" state unintentionally. HTTP/1.0 
proxies don't know the Cache-Control directive, and some of them may not
handle properly even the expires directive. Users are strongly recommended
not to enter stateful dialogs while their user-agents are configured to use
HTTP/1.0 caching proxies.

In the discussion before the last draft issued we agreed that on the server
side State-Info can be implemented in CGI. In the case of a CGI
implementation may be needed some kind of "entry and exit doors" to start
and finish a stateful dialog. URLs, implementing those doors may not depend
on state info and can be otherwise cachable, but the removal of the original
requirement of not to cache responses containing state-info opens up a hole
for mistery errors, consisting in lose of "have State-Info" state by user
agents. I think that requiring the use of Cache-Control: private
can avoid this problem.
[discussion of expires]
HTTP/1.1 parties must implement Cache-Control, pre-expiration of state-info
dependent responses needed only for HTTP/1.0 compatibility. Current HTTP/1.0
user agents aren't capable to participate in stateful dialogs. The only case
when 1.0 compatibility is needed, when 1.1 parties are talking through 1.0
caching proxy. (1.0 forwarding-only proxies can't make any harm.)
Current caching proxy implementations known to me (ichtus and cern ones)
handle Expires correctly, but I am not sure about other implementations.
Can we be sure, that all current caches handle Expires as needed?
Theoretically not, but an exhaustive investigation may lead to the opposite
conclusion. While this is not proven, better to warn users about possible
problems. Picky implementatios may add a such warning to the resposes to
1.0 requests. (Seeing an 1.0 request line or SERVER_PROTOCOL=HTTP/1.0 in

Andrew. (Endre Balint Nagy) <bne@bne.ind.eunet.hu>
Received on Wednesday, 27 September 1995 03:56:29 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:15 UTC