GET and side-effects

       In Roy's draft, section 14.2 says that GET and HEAD should not
       have side effects.  It also says that the protocol cannot enforce
       this, but (implicitly) that implementations of the protocol may
       assume that GET and HEAD are in fact side-effect-free.  I believe
       that this is a valuable concept, and I don't think we should give
       up our ability to make this assumption.
    
    My point was that we can generalize this, while allowing the existing
    behavior as a default.  It's safe to serve responses to GET and HEAD
    out of a cache only because we assume they are side-effect-free.  We
    don't make that assumption with other methods -- we assume they
    actually have to do something at the origin server.

I think one question is whether the issue for GET/HEAD is actually
a caching issue, or is it a user-expectations issue.  Section 14.2
starts:
   The writers of client software should be aware that the software 
   represents the user in their interactions over the Internet, and 
   should be careful to allow the user to be aware of any actions they 
   may take which may have an unexpected significance to themselves or 
   others.

It is possible to take this position with respect to GET/HEAD even
without any consideration of caching.  That is, even in a system
with no caches, we should be able to give an answer to the question
"should GET/HEAD have side effects?"

Suppose each time I did a GET, the HTTP server applied a small
electric shock to the system administrator (without my knowledge,
of course).  I would pretty annoyed to find out that this was
happening.  This kind of side-effect (used for illustrative
purposes only!) obviously violates the user's expectations.

On the other hand, supposing that the server simply debits the
user's bank account each time it performs a GET for, say, the
latest DEC stock quote.  Is this kind of side effect a bad one?
Is it banned by the language currently in section 14.2?  Should
it be?  I think these questions need to be answered before we
can fully resolve the issue of caching.

Back to caching:

One could argue that "fee for service" side-effects are a kind
of performance cost, which is exactly what caches are supposed
to reduce, and so if 14.2 was amended to allow only this kind
of side effect for GET/HEAD, we could still happily cache the
results.

    I'm claiming that assumption is unnecessary if we adopt mandatory
    use of controls already in the protocol to make this explicit,
    namely Cache-control:no-cache, which on requests means "you can't
    give me the answer to this out of a cache -- I want it from the
    origin server".  (we could call it something different - the
    meaning is what matters).

Since I've gotten a bit confused myself over what Cache-control: no-cache
means (it depends on which direction it's going in), how about if
we use the term "Cache-control: reload" for this function (at least
for the purposes of discussion)?

I agree that this is a useful feature, and I also agree that the
server should be able to mark the results of a GET/HEAD as not
cachable (using "Cache-control: no-cache" or something else).

But I don't think this means that GET/HEAD can have arbitrary
side effects, because we still have to deal with user expectations
about the semantics of repeatedly visiting a page.  That is, if
we are aiming for the ideal that caching is entirely transparent
to the user, except for "performance" (which might include fees),
then we still have to think about whether GET/HEAD should have
side effects.

My vote is for "no GET/HEAD side effects except for retrieval charges."

-Jeff

Received on Thursday, 4 January 1996 18:54:14 UTC