Re: idempotence of POST

    There are three suggested ways of accomplishing this:
    
    a) allow GET to take a body
    b) add a new method, GET-with-body (spelled how you like)
    c) allow the return value of POST to indicate that the request
       can be repeated safely.
    
    (a) is an incompatible protocol change, at least for most
    implementations.
    (b) requires HTML forms that wish to request this action to
    say so directly, and so is also an incompatible change for HTML, if
    not for HTTP
    (c) is backward compatible.

Although I think it might be useful to have an implementation
of (c), when we had this discussion several months ago (it might
only have been on the caching subgroup's mailing list), we realized
that this is not a complete solution when cooperating proxies
(such as Squid/Harvest) are being used.

When such a proxy receives a replayable request, such as a GET,
for which it has no cache entry, it might be much more efficient
for it to check with its peer proxies before forwarding the request
to the origin server.  (For example, if the proxy and its peers
are all in New Zealand, and the origin server is on the other side
of a trans-Pacific link.)  This is what makes cooperating proxies
potentially useful.

On the other hand, if the request is non-replayable, such as is
PUT in the default case, there is no reason for the proxy to check
with its peers, and the request can and should be immediately
forwarded to the origin server.

Note that the proxy is making this decision (check-with-peers vs.
forward) *without* a local cache entry for the resource.  Thus,
anything that marks the *response* to a PUT as replayable will not
help.

Why is this important?  If the availability of replayable PUTs
causes a significant shift away from GETs, and the replayable
nature of the PUT is not visible in the client's *initial* request,
then cooperating proxies will not be able to optimize the use of
their caches, and we could see additional unnecessary traffic over
certain critical bottleneck links.  On the other hand, if a
"GET-with-body" method were available for this use, then even the
initial request would be clearly marked as replayable, and hence
a cooperating proxy without a cache entry for the resource could
still check with its peers.

Having said all this, I must hasten to add that:
	(1) I'm not really convinced of the utility of the
	cooperating cache model, and so it may not be worth
	worrying about.
	(2) It certainly would be much harder to deploy in a
	compatible manner than a new response header.
	(3) If we don't do it in HTTP/1.1, it's probably too
	late to have much of an effect, and it's probably too
	late to reopen HTTP/1.1 to include a new method.

However, note that it might be possible to introduce a
"replayable PUT" feature with first-request visibility,
without adding any new methods.  It would, however, take
some support from HTML.

First, we could add a new request header to HTTP (similar
to Dan DuBois's "Idempotent: yes" header, but his proposal
was for a response header).  This might even be done just
as a new "Cache-Control" directive, e.g.,
	Cache-Control: request-is-idempotent
(but with a shorter name, for sure).

Second, we would need some way to indicate in an HTML form
not only that the method should be PUT, but that the request
should contain a specified header.  I'm not really an HTML
forms hacker, but I would imagine that something like this
would have the right general shape:

	<FORM METHOD=PUT REQHDR="Cache-Control: request-is-idempotent"
		ACTION="/cgi-bin/query" .....>

The meaning of the REQHDR tag would be "add this header to the
set of request headers.  Older browsers would simply ignore
the tag (right?), and one could use this technique to introduce
some forms of new client behavior without changing the client's
HTTP implementation at all.  This seems more extensible than
adding a new single-purpose tag.

I suppose one might have to be careful about the client-side
implementation of REQHDR, or else it might be used to subvert
certain kinds of security mechanisms.

-Jeff

Received on Thursday, 19 September 1996 10:33:06 UTC