W3C home > Mailing lists > Public > http-caching-historical@w3.org > January 1996

RE: GET, POST, and side-effects

From: David W. Morris <dwm@shell.portal.com>
Date: Sat, 6 Jan 1996 15:34:39 -0800 (PST)
To: Paul Leach <paulle@microsoft.com>
Cc: sjk@amazon.com, http-caching@pa.dec.com
Message-Id: <Pine.SUN.3.90.960106150352.23359B-100000@jobe.shell.portal.com>

On Fri, 5 Jan 1996, Paul Leach wrote:

> I always asumed that the existence of a "?" in the request-URI 
> prevented proxies from caching the result-entity, so that this couldn't happen?
> Is this not a correct understanding of the practice?

You probably got that understanding by reading a comment of mine about
10 months ago and missing the responses.... ;-:). It was in the course
of this discussion that I came to understand the 'official' 
differences between GET and POST (my original assumption was
size related as well).

I too liked the "Cache-control: reload" because it is obvious to me
at least that there is altogether too many side-effect behaviors
and expectations associated with the WWW protcols. Where possible
I prefer to see things specified clearly and directly.

That said ... we have a bunch of compatibility issues and sometimes
awkward historical precedent to accomadate. I believe the
HTML RFC and the HTTP 1.0 draft are pretty clear about GET and
POST vis-a-vis cachability. 

We need to understand the current 'standards' to make sure our
result doesn't break anything. For sure we shouldn't re-define
anything to be deliverable from a cache when that wouldn't be
expected now.

This assertion is not intended to preclude:
a.  New header/methods which would enable caching
b.  Design of validator mechanism where by a client/proxy might
       For this URI I am holding validators: abc, fgh, hij
    and the server might say:
       Great, I have recorded this transaction and you can serve

    I'm not sure this differs from redirection in the most general
    sense. I'm listing this as an example of an extension which
    might be useful and wouldn't confict with my basic premis.

    I would also suggest that this is beyond what we should propose
    for the 1.1 iterateion.

One problem I have being a consultant is that my documentation is spred
in too many places so I don't have an easy way to cite chapter and
verse but I would encourage all to reference the HTML RFC and HTTP
1.0 draft as well as the archives to understand the side-effect
ruless for GET and POST.

Dave Morris
Received on Saturday, 6 January 1996 23:47:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:55:57 UTC