- From: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
- Date: Wed, 25 Sep 1996 18:43:28 -0700
- To: Mike Meyer <mwm@contessa.phone.net>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>> 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