Re: Possible optimization to State-Info proposal

Dave Kristol:
>Further complicating the question is, what do existing caching proxies
>do, and how would that behavior interact with State-Info?

As far as I know, you can depend on existing caches knowing about
Expires: <yesterday>.  The pragma: no-cache *response* header is very
new, so existing caches probably won't know about it.

So it could be said that existing caches are already able to support
(the latest version of) State-info.

The biggest problem is existing *user agent* caches.  User agents with
internal caches that completely ignore Expires and Pragma are still
very common.

>[Shel Kaphan <sjk@amazon.com> wrote: ]
>  > 
>  >     [ much discussion of idempotence, caching, etc. ]
>  > 
>  > I don't think we have to make a big deal about defining idempotence.
> 
>My only reason for fussing with the definition is to be sure we're talking
>about the same things and using the same terms to do so.  I feared we were
>using the same words to mean different things.

In a previous message your definition was:

>I think the prevailing definition of an idempotent {method, URI} pair
>is that you get back exactly the same content each time you make a
>request with that pair.

I would call that a `static' pair.

Your meaning of idempotent is not the (prevailing?) one used in the draft
http spec. From draft-ietf-http-v10-spec-02.html:

#10.2 Idempotent Methods

[...]

#In particular, the convention has been established that the GET and
#HEAD methods should never have the significance of taking an action
#other than retrieval. These methods should be considered "safe" and
#should not have side effects. This allows the client software to
#represent other methods, such as POST, in a special way so that the
#user is made aware of the fact that an non-idempotent action is being
#requested.
#
#Naturally, it is not possible to ensure that the server does not
#generate side-effects as a result of performing a GET request; in
#fact, some dynamic resources consider that a feature. The important
#distinction here is that the user did not request the side-effects, so
#therefore cannot be held accountable for them.

>From this, I read that:
 - GET and HEAD are defined to be the idempotent methods
 - idempotent means `safe'.

IMO, the spec should be rewritten to avoid the use of the word
`idempotent' altogether.  Failing that, there should be a proper
definition of it in the terminology section.

[..using existing cache prevention methods for stateful services..]

>  > I don't see why it needs to be any more complex than that.
> 
>That much sounds fine, and I agree.  The messiness arises when State-Info
>passes through a caching proxy in one direction or the other.  (I know
>that isn't news to you.)  The goal is to cache as much stuff as possible
>and still perform correctly.

The goal (at least my goal) is to add State-Info to http 1.1.  I would
like to discuss the caching implications of State-Info in terms of the
currently drafted http 1.1 caching mechanisms. 

State-Info already allows very adequate caching using the existing
http caching definitions.

The discussion on how to cache as much stuff as possible (by redefining
`idempotent' in http 1.1 or whatever) should be done in another thread.

>  >     [ tuned caches ... ]
>  > 
>  > As for the idea that caches might decide to cache things they
>  > shouldn't (overruling headers in responses), and then give error
>  > responses to requests with state-info requests, I think that's really
>  > a travesty.
> 
>I agree, but apparently it's something that must be dealt with, just
>like error conditions in general.

The reason for putting something about tuned caches in the state-info
spec is that proxy operators need to be reminded of their
responsibility to operate a non-broken cache, or, failing that, to
operate a cache that tells you when it is broken.

As long as tuning is common (and it seems to be, though I don't have
any hard figures), proxy operators need to be reminded of this.  Shel,
I don't like this any more than you do.

Note that the above text about tuned caches does not introduce any
obligation for the operators of _working_ caches to treat State-Info
as a special case.

>Dave Kristol

Koen.

Received on Monday, 28 August 1995 14:40:56 UTC