HTTP defines methods (sometimes referred to as verbs) to indicate the desired action to be performed on the identified resource. What this resource represents, whether pre-existing data or data that is generated dynamically, depends on the implementation of the server. Often, the resource corresponds to a file or the output of an executable residing on the server.

Commonly used MethodsEdit

means retrieve whatever data is identified by the URI, so where the URI refers to a data-producing process, or a script which can be run by such a process, it is this data which will be returned, and not the source text of the script or process.
is the same as GET but returns only HTTP headers and no document body.
Similar to GET but locks the object against update by other people. The lock may be broken by a higher authority or on timeout: in this case a future CHECKIN will fail.
Returns a description (perhaps a form) for a given method when applied to the given object. The method name is specified in a For-Method: field. (TBS)
specifies that the data in the body section is to be stored under the supplied URL. The URL must already exist. The new contenst of the document are the data part of the request. POST and REPLY should be used for creating new documents.
Requests that the server delete the information corresponding to the given URL. After a successfull DELETE method, the URL becomes invalid for any future methods.
Creates a new object linked to the specified object. The message-id field of the new object may be set by the client or else will be given by the server. A URL will be allocated by the server and returned to the client. The new document is the data part of the request. It is considered to be subordinate to the specified object, in the way that a file is subordinate to a directory containing it, or a news article is subordinate to a newsgroup to which it is posted.
Links an existing object to the specified object.
Removes link (or other meta-) information from an object.
Similar to PUT, but releases the lock set on the object. Fails if no lock has been set by CHECKOUT. 
The object may be queried with a text string. The search form of the GET method is used to query the object.
The object will accept a query whose terms are the cooridnates of a point within the object. The method is implemented using GET with a derived URL .
Proposed only. The index (etc) identified by the URL is to be searched for something matching in some sense the enclosed message. How does the client know what message fromats are acceptable to the server? (Suggestion of Fred Williams)