Re: GET, POST, and side-effects

Jeffrey Mogul writes:

 > and Dave Morris writes:
 >     Well, it doesn't seem like a major extension to the GET method to
 >     allow for an entity body from the HTTP documents perspective.
 > 
	...
 > For the time being, let's try to keep the discussion on HTTP-caching
 > focussed on finding solutions that do not involve changing the
 > syntax of existing methods or adding new ones.  Adding headers
 > seems to be the only safely interoperable change we can make.
 > 

Of course, you're right, this is the only thing we can do.  It's hard
to keep that constraint in mind, that's all.

Something close to my original proposal for how to do this is downward
compatible, I think.  Here goes:

Allow an additional annotation to the <form ...> element, say
<form method=POST ... side-effects=none>  or something.  This is only for
the POST method, since we have to assume that 1.0 caches that receive
GETs will ignore any request entity body, and so would cache all
requests under the same key, which would be broken.

This addition to <form> then would cause a 1.1-capable browser to insert a
header into into the request, for illustration say
Cache-control:No-Side-Effects.  1.0 proxies will ignore this and pass
the entire request on to the origin server.  This is safe.  1.1
proxies will interpret this to mean that they can cache the request
and any responses (subject to other freshness rules, of course).

	...

 > Or if someone can propose a carefully worked-out scheme that
 > allows a client to reliably determine that the request chain
 > does not go through a pre-1.1 proxy, then we could think about
 > using that approach.  If you do this, please think it through
 > before submitting it to the group.
 > 

Since proxies forward headers they don't know about, I can't think of
a way to do this.

--Shel

Received on Friday, 5 January 1996 22:39:11 UTC