Re: HTTP working group status & issues (please reply)

>> As I believe Jeffry Mogul has already presented, it would break the
>> assumptions of some very important caches if they can't assume idempotence
>> of GET.
> 
> This is true. On the other hand, the functionality is sufficiently
> important that I routinely build applications that do non-idempotent
> GETs when I'm building for a captive audience.

Let me make this very clear.  You routinely build applications
which violate the definition of the HTTP protocol with regard to
the semantics of the GET method, and you are willing to take personal
responsibility for any loss of property resulting from subsequent
misuse of that application due to user misunderstanding or normal
automated processes.  In other words, you are betting on the unlikelihood
that such a misunderstanding will not take place within your controlled
environment.

Section 9.1.1 (Safe Methods) which discusses this issue is there
for a reason, and has been present in the spec in one form or another
since TimBL wrote the original HTTP/1.0 discussion document. It sounds
like legalese precisely because it is legalese, and is intended to be
treated as such.  As far as HTTP is concerned, there is no such thing
as an unsafe-to-be-repeated GET, because the safe semantics exist to protect
*users* of the protocol regardless of the intentions of the developer.

And yes, this does include FORM-processing scripts which accept POST
information in the form of a GET+parameters.  Any significant action
other than retrieval requires a method other than GET, and the fact that
most HTML user agents do not allow you to specify the method in a
normal link does not modify the intentions of the protocol.

Whether or not a method is intended to be "safe" in that sense must
be determined by the client prior to the first usage of that method.
Notification in a response field is irrelevant -- that would be too late.
It must be determined prior to the request, as part of the mechanism
which establishes the parameters of the request (e.g., a FORM or A or IMG
in HTML, and whatever else is provided by other HTTP-aware data formats).
The mechanism that HTML and HTTP use to declare those semantics is
the method name.

Whether or not the method name is the "best" place to declare those
semantics is a separate issue and, IMHO, not worth discussing given
the preponderance of existing applications that treat it as such and
the lack of any appreciable gain from changing it to something else.

None of this, BTW, has anything to do with whether or not a previous
response may be reused (with or without contacting the origin), which
is completely covered by the Cache-Control header field.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 25 September 1996 19:01:10 UTC