Network Working Group R. Fielding Request for Comments: 2616 ...

If at any point an error status is received, the client- SHOULD NOT continue and- SHOULD close the connection if it has not completed sending therequest message.9 Method DefinitionsThe set of common methods for HTTP/1.1 is defined below. Althoughthis set can be expanded, additional methods cannot be assumed toshare the same semantics for separately extended clients and servers.The Host request-header field (section 14.23) MUST accompany allHTTP/1.1 requests.9.1 Safe and Idempotent Methods9.1.1 Safe MethodsImplementors should be aware that the software represents the user intheir interactions over the Internet, and should be careful to allowthe user to be aware of any actions they might take which may have anunexpected significance to themselves or others.In particular, the convention has been established that the GET andHEAD methods SHOULD NOT have the significance of taking an actionother than retrieval. These methods ought to be considered "safe".This allows user agents to represent other methods, such as POST, PUTand DELETE, in a special way, so that the user is made aware of thefact that a possibly unsafe action is being requested.Naturally, it is not possible to ensure that the server does notgenerate side-effects as a result of performing a GET request; infact, some dynamic resources consider that a feature. The importantdistinction here is that the user did not request the side-effects,so therefore cannot be held accountable for them.9.1.2 Idempotent MethodsMethods can also have the property of "idempotence" in that (asidefrom error or expiration issues) the side-effects of N > 0 identicalrequests is the same as for a single request. The methods GET, HEAD,PUT and DELETE share this property. Also, the methods OPTIONS andTRACE SHOULD NOT have side effects, and so are inherently idempotent.