The definition of HTTP methods in RFC2616

9 Method Definitions

The set of common methods for http/1.1 is defined below. Although this set can is expanded, additional methods cannot be assumed to share the same semantics for separately Extende D clients and servers.

The Host request-header field (section 14.23) must accompany all http/1.1 requests.

9.1 Safe and idempotent Methods9.1.1 safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be Careful to allow the user to being aware of any actions they might take which could have a unexpected significance to Themselv Es or others.

In particular, the Convention had been established that the GET and HEAD methods should don't have the significance of Takin G an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special it, so, the user is MA De aware of the fact, a possibly unsafe action is being requested.

Naturally, it isn't possible to ensure that the server does not generate side-effects as a result of performing a GET req uest; In fact, the some dynamic resources consider that a feature. The important distinction here's the user did not request the side-effects, so therefore cannot be held accountable For them.

9.1.2 idempotent Methods

Methods can also has the property of ' Idempotence ' in that (aside from error or expiration issues) the side-effects of N > 0 Identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property. Also, the methods OPTIONS and TRACE should not has side effects, and so is inherently idempotent.

However, it's possible that a sequence of several requests was non-idempotent, even if all of the methods executed in tha T sequence is idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields A result that's not changed by A Ree Xecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if it result depends on a value of is later modified in the same sequence.

A sequence that never have side effects is idempotent, by definition (provided that no concurrent operations was being exec Uted on the same set of resources).

9.2 OPTIONS

The options method represents a request for information about the communication OPTIONS available on the Request/response Chain identified by the Request-uri. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.

Responses to this method is not cacheable.

If the OPTIONS request includes an entity-body (as indicated by the presence of Content-length or transfer-encoding) and then The media type must is indicated by a content-type field. Although this specification does no define any use for such a body, future extensions to HTTP might use the OPTIONS body Detailed queries on the server. A server that does not support such an extension may discard the request body.

If The Request-uri is a asterisk ("*"), the OPTIONS Request is intended to apply to the server in general rather than to A specific resource. Since a server ' s communication options typically depend on the resource, the "*" request was only useful as a "ping" or "no -op "type of method; It does nothing beyond allowing the client to test the capabilities of the server. For example, this can is used to test a proxy for http/1.1 compliance (or lack thereof).

If The Request-uri is not a asterisk, the options Request applies only to the options that's available when Communicati Ng with that resource.

A response should include any header fields, indicate optional features implemented by the server and applicable T o that resource (e.g., allow), possibly including extensions is defined by this specification. The response body, if any, should also include information about the communication options. The format for such a

Body is not a defined by this specification, but might was defined by the future extensions to HTTP. Content negotiation used to select the appropriate response format. If no response body is included, the response must include a content-length field with a field-value of "0".

The Max-forwards request-header field May is used to target a specific proxy in the request chain. When a proxy receives a OPTIONS request on an absoluteuri for which request forwarding is permitted, the proxy must check For a max-forwards field. If the Max-forwards Field-value is zero ("0") and the proxy must not forward the message; Instead, the proxy should respond with its own communication options. If the Max-forwards field-value is a integer greater than zero, the proxy must decrement the field-value when it forwards The request. If No max-forwards field is present on the request, then the forwarded request must not include a max-forwards field.

9.3 GET

The GET method means retrieve whatever information (in the form of a entity) is identified by the Request-uri. If The Request-uri refers to a data-producing process, it is the produced data which shall are returned as the entity in th E response and not the source text of the process, unless that text happens to be the output of the process.

The semantics of the Get method change to a "conditional GET" If the request message includes an if-modified-since, IF-UNM Odified-since, If-match, If-none-match, or if-range header field. A conditional GET method requests that the entity is transferred only under the circumstances described by the conditional Header field (s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed wit Hout requiring multiple requests or transferring data already held by the client.

The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that is only part of the entity being transferred, as described in section 14.35. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be comp Leted without transferring data already held by the client.

The response to a GET request are cacheable if and only if it meets the requirements for HTTP caching described in section 13.

See sections 15.1.3 for security considerations if used for forms.

9.4 HEAD

The HEAD method is identical to GET except, the server must not return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should being identical to the information Sen T in response to a GET request. This method can is used for obtaining metainformation on the entity implied by the request without transferring the ENT Ity-body itself. This method was often used for testing hypertext links for validity, accessibility, and recent modification.

The response to a HEAD request is cacheable in the sense of the information contained in the response is used to Update a previously cached entity from that resource. If The new field values indicate the cached entity differs from the current entity (as would being indicated by a In Content-length, CONTENT-MD5, ETag, or last-modified), then the cache must treat the cache entry as stale.

9.5 POST

The POST method is used to request the origin server accept the entity enclosed in the request as a new subordinate O f The resource identified by the Request-uri in the Request-line. POST is designed to allow a uniform method to cover the following functions:

      -Annotation of existing resources;

      -Posting a message to a bulletin board, newsgroup, mailing list,        or similar group of articles;

      -Providing a block of data, such as the result of submitting a        form, to a data-handling process;

      -Extending a database through an append operation.

The actual function performed by the POST method was determined by the server and was usually dependent on the Request-uri. The posted entity is subordinate to that URI in the same-to-a file is subordinate to a directory containing it, a NE WS article is subordinate to a newsgroup to which it's posted, or a record is subordinate to a database.

The action performed by the POST method is might not the result of a resource that can is identified by a URI. In this case, either (OK) or 204 (No Content) are the appropriate response status, depending on whether or not the RESP Onse includes an entity that describes the result.

If A resource have been created on the origin server, the response should is 201 (created) and contain an entity which DESC Ribes the status of the request and refers to the new resource, and a location header (see section 14.30).

Responses to this method is not cacheable, unless the response includes appropriate Cache-control or Expires header field S. However, the 303 (see) response can is used to direct the user agent to retrieve a cacheable resource.

POST requests must obey the message transmission requirements set out on section 8.2.

See sections 15.1.3 for security considerations.

9.6 PUT

The PUT method requests that the enclosed entity is stored under the supplied Request-uri. If The Request-uri refers to an already existing resource, the enclosed entity should be considered as a modified version Of the one residing on the origin server. If The Request-uri does not a existing resource, and that URI is capable of being defined as a new resource by T He requesting the user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server must inform the user agent via the 201 (created) response. If an existing resource is modified, either the (OK) or 204 (No Content) response codes should being sent to indicate SUC Cessful completion of the request. If the resource could not being created or modified with the Request-uri, an appropriate error response should is given that Reflects the nature of the problem. The recipient of the entity must not ignore any content-* (e.g. content-range) headers This it does not understand orImplement and must return a 501 (not implemented) response in such cases.

If the request passes through a cache and the Request-uri identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method is not cacheable.

The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-uri. The URI in a POST request identifies the resource, that would handle the enclosed entity. That resource might is a data-accepting process, a gateway to some other protocol, or a separate entity that accepts Annot Ations. In contrast, the URI of a PUT request identifies the entity enclosed with the request – the user agent knows what URI is Intended and the server must not attempt to apply the request to some other resource. If the server desires that the request is applied to a different URI,

It must send a 301 (Moved permanently) response; The user agent May and make it own decision regarding whether or not to redirect the request.

A single resource is identified by many different URIs. For example, an article might has a URI for identifying ' the current version ' which is separate from the URI identifying Each particular version. In this case, a PUT request to a general URI might result in several other URIs being defined by the origin server.

http/1.1 does not define how a PUT method affects the state of the origin server.

PUT requests must obey the message transmission requirements set out on section 8.2.

Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request should being applied to the Resource created or modified by the PUT.

9.7 DELETE

The Delete method requests the origin server DELETE the resource identified by the Request-uri. This method is overridden by human intervention, or other means, on the origin server. The client cannot is guaranteed that the operation have been carried out, even if the status code returned from the origin Server indicates, the action has been completed successfully. However, the server should not indicate success unless, at the time the response was given, it intends to delete the Resour Ce or move it to a inaccessible location.

A successful response should be + (OK) If the response includes an entity describing the status, 202 (Accepted) if the A Ction have not yet been enacted, or 204 (No Content) If the action have been enacted but the response does does include an EN Tity.

If the request passes through a cache and the Request-uri identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method is not cacheable.

9.8 TRACE

The TRACE method is used to invoke a remote, Application-layer loop-back of the request message. The final recipient of the request should reflect the message received back to the client as the entity-body of a (OK) Response. The final recipient is either the

Origin server or the first proxy or gateway to receive a max-forwards value of zero (0) in the request (see section 14.31) . A TRACE request must not include an entity.

TRACE allows the client to see what's being received at the same end of the request chain and use this data for testing or diagnostic information. The value of the Via header field (section 14.45) is of particular interest, since it acts as a trace of the request chain . Use of the Max-forwards header field allows the client to limit the length of the request chain, which are useful for testi Ng a chain of proxies forwarding messages in an infinite loop.

If the request is valid, the response should contain the entire request message in the Entity-body, with a content-type of "Message/http". Responses to this method must not being cached.

9.9 CONNECT

This specification reserves the method name, CONNECT for use with a proxy, can dynamically switch to being a tunnel (e. G. SSL tunneling [44]).

The definition of HTTP methods in RFC2616