Rfc2616-http1.1-methods (Method Requirements section-translation)

part of Hypertext Transfer Protocol--http/1.1
RFC 2616 Fielding, et al.

9 method definition ( Method Definitions )

The following defines a common set of methods for the http/1.1 protocol. Although these methods can be extensible, it is not assumed that additional methods can share the semantics of the group method for a single extended client or server.

The Host Request header field (request-header field) (section 14.23) must have an associated request for the http/1.1 agreement definition.

9.1 Safety (safe) and Idempotent (idempotent) methods 9.1.1 Security Method (safe Methods)

Developers should be aware that users interact on the Internet through software, and we should be careful to allow users to understand any action they may take, as these actions may have unintended implications for themselves or others.

The relevant standards have been described in detail, and the get and head methods cannot be used for purposes other than retrieval. Then these methods should be considered "safe". This allows the user agent to represent in a special way other methods, such as post, put, and delate, to make the user aware of the fact that the request may have unsafe actions.

Of course, the server performs a GET request, and it is not possible to ensure that this does not cause side effects; in fact, some dynamic resources treat this side effect as a function. Here is an important thing to distinguish between the user does not request side effects, so should not be responsible for side effects.

9.1.2 Idempotent method (I dempotent Methods )

The "method" also has "idempotent" (except for errors or expirations), and the same request greater than once is the same as the side effect of a single request. This property is shared by methods such as Get,head,put,delete. In addition, the options and trace methods should not have side effects, so they are idempotent in nature.

However, the queue for multiple requests may be non-idempotent, although all the methods in the execution request are idempotent (if a single execution of a sequence always produces a result, and the result is not changed by partial or total re-execution of the sequence, then the sequence is idempotent). For example, a value in a sequence will be modified later, and the result of the sequence will depend on it, then the sequence is non-idempotent.

By definition, a sequence that does not produce a side effect is idempotent (if concurrent operations are not performed on the same resource).

9.2 Options ( OPTIONS )

The options method represents a request for information about the communication options that are available on the request/response chain identified by the request URI. This method allows the client to determine options and/or requirements related to resource or server functionality, without involving resource operations or initiating resource retrieval. The response to this method is not cacheable.

If an options request contains an entity (Entity-body), such as the presence of content-length or transfer-encoding, the media type must be represented by the Content-type field. Although the specification does not define any use of such a principal, future HTTP extensions may use options entities to make more detailed queries on the server. If the server does not support this type of extension, you can discard the request body.

If the requested URI is a "*" number, then the options request is often used for the server instead of a specified resource. Because the server's communication options are often dependent on resources, the "*" request can only be used for methods of the "ping" or "no-op" type; it does nothing but allow the client to test the server's capabilities. For example, it can be used to test http/1.1 compliant (or missing) proxies.

If the request URI is not an asterisk, the options request applies only to the option that is available when communicating with the resource.

A 200 response should include any header fields that indicate the optional characteristics that the server implements, and apply to that resource (for example, allow), or it may include extensions that are not defined by this specification. The response body, if any, should also contain information about the communication options. The format of this entity is not defined by this specification, but may be defined by future extended content about HTTP. Content negotiation can be used to select the appropriate format. If the response body is not included, the response must contain a Content-length field with a field value of "0".

The Max-forwards request header field can be used to request a specified proxy in a chain of requests. When an agent receives an options request on an absolute URI address that allows the request to be forwarded, the agent must check the Max-forwards field. If the Max-forwards field value is "0", the agent cannot forward the information; instead, the agent should respond with its own communication options. If the field value of Max-forwards is an integer greater than 0, then each forwarding of the agent must reduce the field value. If there is no max-forwards field in the request, the Max-forwards field cannot be present in the forwarded request.

9.3 GET*

The Get method means retrieving any information (in the form of an entity) that the request URI identifies. If the request URI specifies a process that produces data, the resulting data should be returned as an entity instead of returning the original text of the process, unless the text is exactly the output of the procedure.

If the request information includes fields such as If-modified-since, If-unmodified-since, If-match, If-none-match, or If-range, then the semantics of the Get method becomes " Conditional Get method (conditional Get) ". The conditional get (conditional get) method request transfers the entity content only in the case where the condition header field is described. The conditional get method is designed to reduce unnecessary network requests, which allow refreshing of cached entities without requiring multiple requests or transmitting data that already exists in the client.

If a range header field is included in the request information, the Get method changes to local get (partial get). A partial GET request obtains only a portion of the entity (as described in section 14.35). The partial get method is designed to accomplish partial retrieval of an entity without transmitting data that the client already exists to reduce unnecessary network requests.

When and only if it meets the requirements for HTTP caching as described in section 13th, the response to a GET request can be cached.

Refer to the 15.1.3 section for related security policies when applying a form.

9.4 HEAD

The head method does not differ from the Get method except that it does not return the body of the message in the response. The header source information that is contained in the response returned by the head request should be the same as the information in the response returned by the GET request. This method can be used to obtain source information about an entity that is implied by the request without transferring the entity itself. This method is often used to test the validity, accessibility, and recent modification of hypertext links.

The response returned by a head request should be cacheable, in that sense, the information contained in the response should be used to update the entity information cached in the previous resource. If the new field value indicates that the cached entity is not the same as the current entity (as indicated by a field such as Content-length,content-md5,etag or last-modified), then the caching mechanism must treat the cache entry as expired.

9.5 POST

The Post method is used to request that the source server accept the entity contained in the request as a new subordinate of the resource identified by the request URI in the request queue. The Post method is designed to cover the following functions in a uniform way:

-Annotations to existing resources;
-Send information to bulletin boards, news categories, mailing lists, or similar article classes;
-Providing data blocks, such as the results of submitting forms, to the data processing process;
-Extend the database with additional operations.

The actual function performed by the Post method is determined by the server and is usually dependent on the request URI. Post publishes entity content that belongs to the URI, just as a file belongs to a directory containing it, a news article belongs to a newsgroup that publishes it, or a record belongs to a database.

The operation performed by the Post method may not produce a resource that can be identified by a URI. In this case, either (OK) or 204 (No Content) is the appropriate response state, depending on whether the response contains an entity that describes the result.

If a resource is created on the source server, the response should be 201 (Created) and contain an entity and a Location header field that describes the status of the request and references the new resource. (see section 14.30 for details)

The response to this method is not cacheable unless the response contains the appropriate Cache-control or expires header field. However, you can use the 303 (see) response to instruct the user agent to retrieve cacheable resources.

The POST request must comply with the message transmission requirements specified in section 8.2.

For security-related issues, please refer to section 15.1.3

9.6 PUT

The put method requests a specified entity that is closed by the requested URI. If the request URI points to an existing resource, then the closed entity is considered to be a modified version that exists on the original server. If a request URI does not point to a resource that already exists, and the URI can be considered a new resource by the requesting client, the server can create a new resource with that URI. If a new resource is created, the source server must use 201 (Created) to notify the client. If an existing resource is modified, the server needs to return a (OK) or 204 (No Content) status code to inform the client that the modification was completed. If the resource under the request URI cannot be created or modified, it should return an appropriate error response to reflect the error. The recipient of an entity cannot ignore any content-* (for example, Content-range) header fields that it does not understand or implement, and must return a 501 (not implemented) response in this case.

If the request passes through a cache, and the request URI identifies one or more entities that are currently cached. Then, those cache entities are considered to be outdated. The response of the method cannot be cached.

The fundamental difference between a post and a put request is the different meanings reflected by the request URI. The URI in the POST request identifies the resource that will manipulate the enclosing entity. The resource may be a process that accepts data, a gateway to a different protocol, or a separate entity that accepts annotations. In contrast, the URI in the put request identifies the attached entity in the request-the user agent knows the intent of the URI, and the server should not attempt to apply the request to another resource. If the server wants to apply a request to a different URI, it must send a 301 (Moved permanently) response, and then the user agent can decide for itself whether to redirect the request.

A resource may be identified by a number of different URIs. For example, an article might have a URI that identifies the "current version," which is separate from the URI that identifies each specific version. In this case, a put request on a regular URI may cause a request to multiple other URIs defined by the source server.

http/1.1 does not define how the put method affects the state of the source server.

Put requests must comply with the message transmission requirements set out in section 8.2.

The Put method, unless specified by a specific entity header (Entity-header), should apply the entity header (Entity-headers) in the put request to the resource created or modified by the Put method.

9.7 DELETE

The Delete method requests the server to delete the resource identified by the requested URI. This approach may be overridden by human intervention (or other methods) on the source server. Even if the status code returned from the source server indicates that the operation has completed successfully, there is no guarantee that the operation has been performed by the client. However, the server should not indicate success unless it intends to delete the resource or move it to an inaccessible location when given a response.

If the response contains an entity that describes the state, the response should be (OK), and if the action is not completed, the response should be 202 (Accepted), if the operation is complete, but the response does not contain an entity, the response should be 204 (no Content).

If a cache is requested and the request URI identifies one or more currently cached entities, the entries should be considered expired. The response to this method cannot be cached.

9.8 TRACE

The trace method is used to invoke the remote, application-level loopback of the request message. The final recipient of the request should take the message returned to the client as a (OK) response entity. The final recipient is either the source server or the first proxy or gateway that receives the maximum forwarding value of 0 in the request (see section 14.31). TRACE requests cannot contain entities.

The TRACE method allows the client to see what is received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via Header field (section 14.45) is particularly noteworthy because it acts as a trace for the request chain. Using the Max-forwards header field allows the client to limit the length of the request chain, which is useful for testing the agent forward message chain in an infinite loop.

If the request is valid, the response should contain the entire request message in the entity body, which contains a content-type with a value of "message/http". The response of the trace method is not cacheable.

9.9 CONNECT

This specification retains the Connect method name for use with proxies that can be dynamically switched to tunnels (for example, SSL tunneling [44]).

Rfc2616-http1.1-methods (Method Requirements section-translation)