Method Definition in HTTP protocol (RFC2616)

The OPTIONSOPTIONS method indicates a Request for valid communication options on the Request response chain identified by Request-URI. This method allows the client to determine the options and requirements related to a resource or the capabilities of the server, without the need to use resource behavior or initiate resource acquisition. The response of this method cannot be cached. If the OPTIONS request contains entities (such as stored OPTIONS by Content-Length or Transfer-Encoding)
The OPTIONS method indicates a Request for valid communication OPTIONS on the Request/response chain identified by Request-URI. This method allows the client to determine the options and/or requirements related to a resource or the capabilities of the server, without the need to use resource behavior or initiate resource acquisition.

The response of this method cannot be cached.

If the OPTIONS request includes an object (such as expressed by the presence of Content-Length or Transfer-Encoding), the media Type must be represented by the Content-Type field. Although this specification does not define the usage of this entity, future HTTP extensions may use the OPTIONS message body to query server information in more detail. The server does not support this extension to discard the request message body.

If the Request-URI is an asterisk ("*"), the OPTIONS Request usually attempts to apply the Request to a server rather than a specific resource. Because the server's communication options are generally determined by resources, the "*" request is only useful as a method of the "ping" or "no-op" type; it has no effect, in addition to allowing the client to test the server capabilities. For example, it can be used to test the HTTP/1.1 Proxy consistency (or lack of factors ).

If the Request-URI is not an asterisk (*), the OPTIONS Request applies only to valid OPTIONS when the Request is connected to the resource.

200 The response should include any header domain to indicate the server implementation and optional features that can be applied to the resource (such as Allow), which may include extensions not defined by this specification. If there is a response message body, it should also include the information of the communication option. This specification does not define the format of the message body, but may be defined when HTTP is extended in the future. Content negotiation can be used to select an appropriate response format. If the response body is not included, the response must contain the Content-Length field with the domain value "0.

The Max-Forwards request header domain may be used to locate a specific proxy in the request chain. When receiving an OPTIONS request about absoluteURI that allows request forwarding, the proxy must check the Max-Forwards domain. If the Max-Forwards domain value is 0 ("0"), the proxy cannot forward the message. Instead, the proxy should respond with its own communication options.

If the Max-Forwards domain value is an integer greater than 0, the proxy must reduce the domain value by one when forwarding this request. If the request does not contain the Max-Forwards domain, the forwarded request cannot contain the Max-Forwards domain.

GET
The GET method obtains any information identified by Request-URI (in the form of an object ). If Request-URI references a data processing process, it should take the data it generates as the entity in the response, rather than the source code text of the process, unless the process happens to output the text.

If the request message includes the If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header fields, the meaning of the GET method is changed to "conditional GET ". The condition GET method request only transmits the object in the condition where the condition header field is described. The conditional GET method tries to reduce unnecessary network usage by allowing the entity to refresh the cache without multiple requests or transmitting the data that the client already has.

If the request message includes the Range header field, the GET method syntax is "local GET ". Partial GET requests only need to transmit a part of the object.

HEAD
Except that the server cannot return the message body in the response, the HEAD method is the same as the GET method. The metadata contained in the HTTP header in the response of the HEAD request should be the same as that in the response sent by the GET request. This method can be used to obtain the meta information of the requested entity without transmitting the object itself. This method is often used to test the validity, availability, and recent modifications of hypertext links.

When the response contains information that can be used to update objects previously cached from this resource, the response of the HEAD request may be buffered. If the new field value indicates that the buffer entity is different from the current entity (for example, expressed by the difference between Content-Length, Content-md5, ETag, or Last-Modified ), in this case, the buffer server must use the cached object as the expired object.

POST
The POST method is used to Request the original server to accept the entity encapsulated in the Request as the sub-genus from the Request-URI identifier in the Request line. The POST design allows a unified approach to accomplish the following functions:
Http://www.devdao.com/
Annotation has resources;
Upload messages to forums, newsgroups, or similar discussion groups;
Provide data blocks to the data processing process, such as the results of submitting forms;
You can use the append operation to expand the database.
The actual function of the POST method is determined by the server, and usually depends on the Request-URI. The uploaded object belongs to this URI, and the file belongs to the directory containing it, the new paper belongs to the newsgroup uploaded by it, or the record belongs to the database.

The POST method execution may not result in a resource that can be identified by a URI. In this case, 200 (OK) or 204 (No Content) are suitable response statuses. This depends on whether the response to the description result contains an entity.

If the original server creates a resource, the response should be 201 (Created) and contain the entity describing the request status, the reference of the new resource, and the Location header.

The response of this method cannot be cached unless the response includes the appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to guide the user agent to obtain cacheable resources.

PUT
PUT method requests store encapsulated entities with the provided Request-URI. If Request-URI references an existing resource, the encapsulated object should be regarded as a modified version of the original server storage. If the Request-URI does not point to an existing resource and can be defined as a new resource by the requested user proxy, the original server can use this URI to create resources. If a new resource is Created, the original server must send a 201 (Created) response to the user agent.

If you have modified an existing resource, you should send the 200 (OK) or 204 (No Content) response code to indicate that the request has been successfully completed. If the resource cannot be created or modified according to Request-URI, an appropriate error response should be provided to reflect the nature of the problem. The recipient of an object cannot have a slightly incomprehensible or unimplemented Content-* (such as Content-Range) header. in this case, the 501 (Not Implemented) response must be returned.

If the Request identifies one or more buffered entities through the buffer server and the Request-URI, these entities should be deemed to have expired. The response of this method cannot be cached.

The basic differences between POST and PUT requests are reflected in the different meanings of Request-URI. The resource identified by the URI in the POST request will process the encapsulated entity. This resource may be a data receiving process, a gateway for other protocols, or an independent entity that accepts annotations. Correspondingly, the URI in the PUT request identifies the object encapsulated by the request-the user agent knows that the URI is the target and the server cannot try to apply the request to other resources. If the server wants the request to be applied to different URIs, it must send a 301 (Moved Permanently) request. in this case, the customer agent can decide whether to redirect the request.

You can use many different URIs to identify the same resource. For example, an article may have a URI identified as the current version, which is independent of the URI that identifies each special version. In this case, a PUT request using a universal URI may result in different URIs defined by the original server.

HTTP/1.1 does not define how the PUT method affects the status of the original server.

Except for other special object headers, the object headers in a PUT request should be applied to the resources created or modified by PUT.

DELETE
The DELETE method requests the original server to DELETE the resource identified by the Request-URI. This method can be disabled by the original server with human interference (or other meanings. The client cannot ensure that the operation has been submitted, even if the status code table action sent by the original server has been successfully completed. However, when giving a response, the server should not indicate successful unless it tries to delete the resource or move it to an inaccessible location.

If the response contains an entity in the description state, the response should be 200 (OK ). If the action is not implemented, it is 202 (Accepted ). If the action has been implemented but the response does not contain an entity, the response is 204 (No Content ).

If the Request passes through the buffer server and the Request-URI identifies one or more currently cached entities, these entities should be deemed to have expired. The response of this method cannot be cached.

TRACE
The TRACE method is used to cause remote application layer bounce of the request message. The final receiver of the request should reflect the 200 (OK) response and use the message as the entity for the client to recycle the message. The final receiver is the original server or the first proxy or gateway that receives the Max-Forwards value of 0 (0) in the request. A trace request cannot contain entities.

TRACE allows the client to see what the other end of the request chain receives and then use the data as the test or diagnosis information. The value of the Via header field plays a special role in using it as the request chain path. Use the Max-Forwards header field to allow the client to limit the length of the request chain, which is useful for testing the proxy chain for infinite loop message forwarding.

If the request is valid, the response should include the entire request message in the object and set Content-Type to "message/http ". The response of this method cannot be cached.

CONNECT
The name of the CONNECT method is retained. This method is used by the proxy to enable dynamic tunnel switching (for example, SSL tunnel ).