8.1 get
The GET method is to obtain information specified by the request URI in an entity method. If the request URI is just a data generation process, then it is finally necessary to return to the resource pointed to by the result of the process, rather than returning the text of the processing, unless the text is exactly the output.
If the request message contains the IF-Modified-Since title domain, the syntax of the GET method becomes "Condition Get", ie "(CONDition Get". The condition GET method can determine the specified resource, if it occurs after the IF-Modified-Since Title Domain (see section 10.9), the transmission is activated, otherwise it will not be transmitted. This condition GET
Allows the cached entity to refresh without having to pass multiple requests or unnecessary data transmission, thereby helping to reduce the network load.
8.2 HEAD
The HEAD method is almost the same as get, the difference is that the HEAD method does not allow the server to return any entity in response. For the response part of the HEAD request, the meta information contained in its HTTP title is the same as the GET request. By using this method, it is not necessary to transfer the entire entity body, the meta information specified by the request URI can be obtained. This method is often used to test the legality, accessibility and recent update of hyperlinks.
Unlike conditions GET, there is no so-called "conditional head", ie "Conditional Head". It will also be ignored even if the IF-Modified-Since Title field is specified in the HEAD request.
8.3 POST
The POST method is used to request a request to the purpose, requiring it to accept the entity attached to the request and put it as an additional new child of the resource specified by the request queue (request-line). POST is designed to achieve the following functions with a unified approach:
o Annotation of existing resources for existing resources;
o Send a message to the electronic public bill, newsgroup, mailing list, or similar discussion group;
o Submit the data block, such as submitting the results of the form (Form [3]) to the data processing process;
o Extension the database by additional operation.
Berners-Lee, et al information [Page 31]
The actual function of the POST method is determined by the server, and is usually dependent on the request URI. In the POST process, the entity is the slave part of the URI, as if the file is subjected to the directory containing its directory, the newsgroup file is subjected to the newsgroup that is issued to the file, which is the same as the database belonging to it.
Successful POST does not need to create an entity in the original server and make it as a resource; it is not necessary to provide conditions for future access. That is, the POST method does not necessarily point to the resources specified by the URI. In this case, 200 (success) or 204 (no content) is appropriate response state, depending on the description of the results in the actual response entity.
If a resource is created on the original server, the response should be 201 (created) and contain an entity (the "Text / HTML" type is most suitable), which records the status description of the new resource request.
In all POST requests of all HTTP / 1.0, the legitimate length of content is required. If the HTTP / 1.0 server does not determine its length when receiving the request message content, the 400 (illegal request) code will be returned.
The application cannot cache the response to the POST request, because as an application, they have no way to know how the server will respond in the future request. 9. Status Code Definition (STATUS CODE DEFINitions)
Each status code will be described below, including which method they will correspond, and all meta information required in response.
9.1 Message 1xx (Information)
This type of state code is used to indicate a temporary response. The temporary response consists of state lines and optional titles, and is terminated by the blank line. No 1xx status code is defined in HTTP / 1.0, so they are not legal responses to HTTP / 1.0 requests. In fact, they are mainly used for experimental purposes, which has exceeded the scope of this document.
9.2 Success 2XX (Successful 2xx)
Indicates that the client request is successfully received, understood, and accepts.
Berners-Lee, et al information [Page 32]
200 OK
The request is successful. The information responded relies on the method used to request, as follows:
The resources you want to request have been placed in the entity responded.
HEAD has no entity main body, and only the title information is included in the response. Bamboo
POST entity (description or result of the result of the operation).
201 Created
The request is completed, and the result is a new resource. The URI of the newly created resource can be obtained in the entity responded. The original server should create this resource before issuing the status code. If the operation cannot be completed immediately, the server must give a prompt in the response body when the resource is available, otherwise, the server should receive 202 (acceptable).
The method defined herein, only POST can create resources.
202 ACCEPTED
The request is accepted, but the processing has not been completed. The request may not be finally completed, and it is possible to be handled at any time. In this case, there is no way to resend status code in asynchronous operation.
202 The response is not an obligation, the purpose of doing the server is to wait until the end of the user agent and the server, you can respond to the request of other processes (like running once a day, batch-based process).
In some of the entities returned in some response, the status indication of the current request, the status monitor pointer, or the user's evaluation information to the request can be implemented.
204 no content
The server has already implemented a request, but no new information is returned. If the customer is a user agent, do not update your own document view. This response is mainly to perform input and other operations of the Script statement without affecting the user agent activation document view. The response may also include new, meta information indicated in the form of entity, which can be used by the current user agent activating the document in the view.
Berners-Lee, et al information [Page 33]
9.3 Redirection (Redirection 3XX)
This type of state code indicates that the user agent wants to complete the request, and further operations need to be issued. These operations can only be implemented by the user agent only when the request is Get or HEAD, without interacting with the user. The user agent will never have more than 5 redirection of the request, which may result in an infinite loop.
300 Multiple Choices
This status code is not used directly by the application of HTTP / 1.0, just the default interpretation of the 3xx type response.
There are multiple available requested resources.
Unless it is a HEAD request, the resource must be included in the entity must include the character list and location information of these resources, which is most suitable by the user or user agent.
If the server is preferred, it should store the corresponding URL information at the location domain, and the user agent implements automatic redirection based on the value of this domain.
301 MOVED Permanently
The requested resource allocates a permanent URL so that this resource can be accessed through this URL in the future. The client with editing links automatically updates the request URI as much as possible to the new link returned by the server.
The new URL must be specified by the location domain in the response. Unless it is a HEAD request, the entity-body "must include a brief description of the new URL hyperlink.
If a request is issued with a POST method, the 301 response status code is received. In this case, unless the user confirms, the user agent does not have to automatically redirect requests because this will result in changing the environment that has been issued.
Berners-Lee, et al information [Page 34]
Note: When the POST request is automatically redirected after receiving the 301 status code, some existing user agents will be incorrectly changed to the GET request.
302 MOVED TEMPORARILY
The requested resource is temporarily saved at a different URL. Because the redirection is sometimes changed, the client should continue to use the request URI to issue later requests.
The new URL must be specified by the location domain in the response. Unless it is a HEAD request, the entity-body "must include a brief description of the new URL hyperlink.
If a request is issued with a POST method, the 302 response status code is received. In this case, unless the user confirms, the user agent does not have to automatically redirect requests because this will result in changing the environment that has been issued.
Note: When the POST request is automatically redirected after receiving a 302 status code, some existing user agents will incorrectly change it to the GET request.
304 Not Modified
If the client successfully executes the condition GET request, the server has not been updated since the date specified by the IF-Modified-SINCE field, and the server should respond to this status code, rather than sending the entity main body to the client. In response to the title domain, you should only include some related information, such as cache managers, modifications independent of the Entity's Last-Modified date. Examples of the relevant title are: date, server, expiration time. Whenever the domain value given in the 304 response changes, the cache should update the cache entity.
9.4 Client Error 4xx
The status code of the 4XX class indicates an error in the client. If the client requests yet not completed when receiving 4xx code, it should immediately terminate data to the server. In addition to responding to the HEAD request, whether the error is temporary or permanent, the server side must include an incorrect state interpretation in the entity responding. These status codes apply to any request method.
Berners-Lee, et al information [Page 35]
Note: If the client is sending data, the server-side TCP implementation should be careful to ensure that the client receives the response package before closing the input connection. If the client sends data to the server after shutting down, the server sends a reset package to the client, empties the input buffer that has not been processed, to terminate the read and interpretation of the HTTP application.
400 illegal requests (Bad Request)
If the requested syntax is wrong, the server will not understand. The client should not repeat the request again before making changes to the request.
401 unauthorized
Request user authorization. The WWW-Authenticate Title Domain (10.16) in response should be prompted to request resources in an authorized manner. The client should use the appropriate authorized title domain (10.2) to repeat the request. If the authorization trust information has been included in the request, the response 401 indicates that this authorization is rejected. If the user agent returns the 401 state code after multiple times, the user should check the entity of the response because some related dynamic information will be included in the entity. The HTTP Access Authorization will explain in Section 11. 403 prohibition (Forbidden)
Server understands the request, but refuses to implement the request. Authorization is not helpful, the client should stop repeatedly send this request. If not using a HEAD request method, and the server will be written in the response entity when the server is willing to publish the requested untime the reasons. This status code is typically used for the server-side not wants to announce the details of the request to be rejected or have no other response available.
404 did not find (Not found)
The server does not find resources that match the request URI. The 404 status code does not specify whether the situation is temporary or permanent. If the server does not want to provide this information for the client, the 403 (prohibition) status code is also responded.
Berners-Lee, et al information [Page 36]
9.5 Server Error 5xx
The response code is indicated by the status code starting at '5' indicates that the server is found to have an error and cannot continue the request. If the client receives the 5xx status code, the request has not been completed, it should immediately stop sending data to the server. In addition to responding to the HEAD request, the server should include an interpretation of the error in its response entity and indicate that it is a temporary.
This type of response code does not have a title domain, which can be applied to any request method.
500 server internal error (INTERNAL Server Error)
The server has encountered an unexpected situation to make it unable to continue to respond to request.
501 unrealized (Not Implement)
The server is unable to provide support required for the request. If the server cannot identify the request method, it will respond to this status code, which means that any resource required to request the request.
502 illegal gateway (Bad Gateway)
A server that acts as a gateway or agent receives illegal responses from the UPStream server to send the request.
503 Service Unavailable (Service Unavailable)
The server is currently unable to handle the request. This is generally caused by the temporary overload or maintenance of the server. This status code suggests that it is temporary, and some delays are generated.
Note: The 503 status code does not imply that the server must return this status when overload. Some servers may wish to use simple processing in overload, that is, disconnects.
10. Title Domain Definitions (Header Field Definitions)
This section defines syntax and semantics commonly used in HTTP / 1.0 header domain. Whether it is the sender or the receiver, it is possible to be a client or server side. The specific role depends on who is receiving at this time. Who is sending.
Berners-Lee, et al information [Page 37]
10.1 Allow (Allow)
Indicates that the resource specified by the request URI is supported in the Allow entity title domain, with the purpose of making the receiver more clearly know the legal way to request this resource. The Allow Title domain is not allowed to be used in the Post method. If it is not to do, it will be ignored.
Allow = "allow": "1 # methodExample of use:
Allow: get, head
This domain does not prevent the client from trying to other methods. However, it is actually useful to indicate the indication information represented by the value in the Allow Title domain, which should be observed. The actual Allow method set is defined when a request is issued on the original server.
Since the user agent may communicate with the original server for other purposes, as a proxy (Proxy), even if all the methods specified by the request, the requested Allow Title domain cannot be modified.
The Allow Tita domain does not indicate which methods have been implemented.
10.2 Authorization
Typically, the user agent may (or may not) expect the server to authorize it when receiving a 401 (unauthorized) response. If you want to authorize, the user agent will join the authorization request title in the request (Authorization Request-HEADER)
