HTTP request mode

1. GET

Gets the information (in entity format) specified by the requested URI (Request-uri)

Request URI design to a data generation process, the data generated by the process should be returned as an entity in the corresponding instead of the source text of the process, unless the source text is exactly the output of the process.

If the request message contains a If-modified-since,if-unmodified-siince,if-match,if-none-match or if-range header field, the semantics of get will become conditional conditionall get,

A conditional Get method requests an entity that satisfies the conditional header field.

The objective of the conditional get method is to reduce unnecessary network usage by allowing entities that are still fresh in the cache to be used without having to request or transmit the entities already owned by the client.

If the request method contains a range header field, then the Get method becomes a partial get (partial get) method.

A partial get requests a portion of the entity, and the purpose of the partial get method is to reduce unnecessary network usage, allowing the client to get the entity part of the data from the server without having to get the entity parts that the client has already owned locally.

The response of the GET request is cacheable (cacheable) If this response should meet the requirements of the HTTP cache, security concerns about the GET request used for the form.

2. HEAD

Consistent with the Get method, except that the server cannot return the message subject in the corresponding header, the meta-information (meta-information is the header domain information) in the corresponding HTTP headers should be consistent with the meta-information in the GET request response.

This method is used to obtain meta information for the requested entity without the need to transfer entity principals (Entity-body) This method is often used to test the validity, accessibility, and recent changes of hypertext connections.

The head request can be cached accordingly, and the information in the response can be cached to update the previously cached entity for that resource. If a new domain value appears indicating the difference between the cached entity and the German entity on the current source server (possibly because of a change in the content-length,content-md5,etag,last-modified value), Then cache caches must consider the cache entry to be obsolete stale.

3. POST

Used to request that the source server accept the entity in the request as a new dependency of the requested resource

Function:

Annotations to existing resources;

Post messages to a bulletin board, newsgroups, mailing lists, similar article groups;

Provide a data block, such as submitting a form to a data processing process;

To extend the database by appending operations;

The implementation of the Post method is determined by the server and is often dependent on the request URI (Request-uri), which is the slave of the request URI, as if a file belonged to a directory, an article belonged to a newsgroup, or a record belonged to a database.

The action performed by the Post method may not work on the resource that the request URI refers to.

In this case, 200 success or 204 no content will be appropriate for the corresponding state, depending on whether the corresponding entity contains a description of the result.

If the resource was created by the source server, the response should be 201created and contain an entity that describes the status of the request, referencing the new resource and a location header domain.

The corresponding non-cacheable, unless there is a suitable Cache-control or expires header domain in the response, however, the 303 (other) response can be used by the user agent to obtain a cached response.

Message delivery requirements must be followed.

4. PUT

The request server stores the entity in the request under the request URI (Request-uri) identity.

PUT

The Put method requests the server to store the entity in the request under the request URI (Request-uri) identity. If the request
The resource specified by the URI (Request-uri) already exists on the source server, the entity in this request should be treated as
Is the latest modified version of the source server for the resource entity specified by this URI. If the request URI (Request-uri) specifies
Resource is not present, and the URI is defined as a new resource by the user agent, the source server should be based on the
Entity creates a resource under the identity of this URI. If a new resource is created, the source server must be able to
(user agent) to send a 201 (created) response. If an existing resource is changed, the source server should
Send a (Ok) or 204 (no content) response. If the resource cannot be created or changed according to the request URI, a
The appropriate error response should be given in response to the nature of the problem. The recipient of an entity cannot ignore anything that it does not understand and cannot achieve.
Content-* (such as: Content-range) header domain, and must return 501 (not implemented) response.
If the request passes through a cache, and this request URI (Request-uri) indicates one or more of the current
Cached entities, then these entities should be considered old. The response of the Put method is not cacheable.
The most fundamental difference between the post method and the put method request is that the request URI (Request-uri) has a different meaning. Post please
The URI in the request indicates a resource that can process the requested entity (this resource may be a program, such as
servlet). This resource may be a data reception process, a gateway (gateway, the difference between the broker and the
is: The gateway can be a protocol conversion, and agent can not, just acting, such as the cache server is actually a
Agent), or an entity that receives comments individually. In contrast, the URI in the Put method request identifies the package in the request.
Entity one by one user agent knows what the URI means and the server cannot apply this request to other resources
(Resource). If the server expects the request to be applied to a different URI, then it must send 301 (permanently
User agents can decide for themselves whether to redirect the request.
A separate resource may be specified by many different URIs. such as: An article may have a URI specifying the current version,
This URI differs from the URI of the other special version of this article. In this case, a put request to a common URI can be
Other URI requests that can cause their resources are redefined by the source server.
http/1.1 does not define the state impact of the put method on the source server.
The put request must follow the message delivery requirements in section 8.2.
Unless specifically noted, the Entity header fields in the Put method request should be used for resource creation or modification.

Delete (remove)

The Delete method requests the source server to delete the resource specified by the request URI. This method may be artificially dry on the source server.
(or by other means). The client cannot guarantee that this operation can be performed, even if the source server returns a success status code. However
The server should not indicate success unless it intends to delete the resource or move the resource to an inaccessible location.
If the response contains an entity that describes success, the response should be (OK), or if the delete action is not executed,
Should respond with 202 (accepted), if the delete request method has been executed but the response does not contain an entity, it should be
204 (no content) response.
If the request passes through the cache, and the request URI (Request-uri) specifies one or more cached current entities, then this
Some of the cache entries should be considered old. The response of the Delete method cannot be cached.

TRACE

The trace method is used to excite a remote, application-level request message loop (The trace method allows the client to test
Try to go to the server's network path, the loop meaning such as send a please return a response, this is a request response loop,).

The last recipient may be the source server, perhaps a proxy that contains a max-forwards header domain value of 0 requests
or gateway. A trace request cannot contain an entity.
The trace method allows the client to understand what is being received at the other end of the request chain, and uses that data to
Testing or diagnostics. The Via header field value (see 14.45) has a special purpose because it can be used as a tracking information for the request chain. Use
The Max-forwards header domain allows the client to limit the length of the request chain, which is useful because it can be used to test the generation
Chain to forward messages in an infinite loop.
If the request is valid, the response should contain the entire request message in the entity body, and the response should contain a
Content-type header field with a header field value of "Message/http". The response of this method cannot be cached.

Connect (Connection)

The HTTP1.1 protocol specification retains the Connect method, which is designed to be used for proxies that can dynamically switch to the tunnel

HTTP request mode