The Method field in HTTP indicates the
method to be performed on the object identified by the URL. The method GET
below is always supported, The list of other methods acceptable by the object
are returned in response to either of these two requests.
This list may be extended from time to time by a process of registration
with the design authority. Method names
are case sensitive. Currently
specified methods are as follows:
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. Also used for
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. ( Phase out? )
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
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
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. Suggestion : phase out this
(rcs-like) model in favor of the PUT (cvs-like, non-locking) model of code
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
(Some of these methods require more detailed specification)