Re: Possible optimization to State-Info proposal

> Suppose that a POST returns the same resource that a later GET
> *could* return. The POST's returned resource gets cached, even though the POST

This certainly happens on quite a few servers (including ewse.jrc.it) where
you have forms which either reveal themselves; or act as a 'post' to 
themselves. Seen this quite a few times on other servers as well. Either
for code management/development reasons; or because of referals from other
scripts; it allows you to have central data entry pages.

> itself could not have been served from a cache.  The POST's response can
> legitimately contain state-info.   So, there is no correlation between
> responses that can contain state-info and those that can be cached.
> Leave cacheability to the already too numerous headers that control that.

Yes exactly. We had to deny access to quite a few chaches on the site 
because they just did that.
 
> There may not be a *need* for it that we can imagine right now, but
> there's also no need for restrictions against it.  An origin server
> may legitimately and aggressively try to start sessions whenever it can,
> including times when it is delivering cacheable, shared resources.

Yes; but it would be better, imho, to design things decently from
scratch and distinish between *what* is to be chached in its context. If
you look at our experimental ewse.jrc.it server you might see that the
pages seen also depend on the user who sees them. So I might see a different
layout to the shopping mall than you do; even though we use the same url.

This is something which, although ill defined, is happening at quite
a few places with configurable shopping bags and god knows what. And
I personnaly, as a server admin, would hate to block chaching completely.

Dw.

Received on Monday, 28 August 1995 12:05:04 UTC