RFC 9110

标准化方法一览

   This specification defines a number of standardized methods that are
   commonly used in HTTP, as outlined by the following table.

   +=========+============================================+=========+
   | Method  | Description                                | Section |
   | Name    |                                            |         |
   +=========+============================================+=========+
   | GET     | Transfer a current representation of the   | 9.3.1   |
   |         | target resource.                           |         |
   +---------+--------------------------------------------+---------+
   | HEAD    | Same as GET, but do not transfer the       | 9.3.2   |
   |         | response content.                          |         |
   +---------+--------------------------------------------+---------+
   | POST    | Perform resource-specific processing on    | 9.3.3   |
   |         | the request content.                       |         |
   +---------+--------------------------------------------+---------+
   | PUT     | Replace all current representations of the | 9.3.4   |
   |         | target resource with the request content.  |         |
   +---------+--------------------------------------------+---------+
   | DELETE  | Remove all current representations of the  | 9.3.5   |
   |         | target resource.                           |         |
   +---------+--------------------------------------------+---------+
   | CONNECT | Establish a tunnel to the server           | 9.3.6   |
   |         | identified by the target resource.         |         |
   +---------+--------------------------------------------+---------+
   | OPTIONS | Describe the communication options for the | 9.3.7   |
   |         | target resource.                           |         |
   +---------+--------------------------------------------+---------+
   | TRACE   | Perform a message loop-back test along the | 9.3.8   |
   |         | path to the target resource.               |         |
   +---------+--------------------------------------------+---------+

                                Table 4

[……All general-purpose servers MUST support GET and HEAD]

   All general-purpose servers MUST support the methods GET and HEAD.
   All other methods are OPTIONAL.

   The set of methods allowed by a target resource can be listed in an
   Allow header field (Section 10.2.1).  However, the set of allowed
   methods can change dynamically.  An origin server that receives a
   request method that is unrecognized or not implemented SHOULD respond
   with the 501 (Not Implemented) status code.  An origin server that
   receives a request method that is recognized and implemented, but not
   allowed for the target resource, SHOULD respond with the 405 (Method
   Not Allowed) status code.

安全方法：客户端没请求改状态

   Request methods are considered "safe" if their defined semantics are
   essentially read-only; i.e., the client does not request, and does
   not expect, any state change on the origin server as a result of
   applying a safe method to a target resource.  Likewise, reasonable
   use of a safe method is not expected to cause any harm, loss of
   property, or unusual burden on the origin server.

   This definition of safe methods does not prevent an implementation
   from including behavior that is potentially harmful, that is not
   entirely read-only, or that causes side effects while invoking a safe
   method.  What is important, however, is that the client did not
   request that additional behavior and cannot be held accountable for
   it.  For example, most servers append request information to access
   log files at the completion of every response, regardless of the
   method, and that is considered safe even though the log storage might
   become full and cause the server to fail.  Likewise, a safe request
   initiated by selecting an advertisement on the Web will often have
   the side effect of charging an advertising account.

   Of the request methods defined by this specification, the GET, HEAD,
   OPTIONS, and TRACE methods are defined to be safe.

   The purpose of distinguishing between safe and unsafe methods is to
   allow automated retrieval processes (spiders) and cache performance
   optimization (pre-fetching) to work without fear of causing harm.  In
   addition, it allows a user agent to apply appropriate constraints on
   the automated use of unsafe methods when processing potentially
   untrusted content.

   A user agent SHOULD distinguish between safe and unsafe methods when
   presenting potential actions to a user, such that the user can be
   made aware of an unsafe action before it is requested.

   When a resource is constructed such that parameters within the target
   URI have the effect of selecting an action, it is the resource
   owner's responsibility to ensure that the action is consistent with
   the request method semantics.  For example, it is common for Web-
   based content editing software to use actions within query
   parameters, such as "page?do=delete".  If the purpose of such a
   resource is to perform an unsafe action, then the resource owner MUST
   disable or disallow that action when it is accessed using a safe
   request method.  Failure to do so will result in unfortunate side
   effects when automated processes perform a GET on every URI reference
   for the sake of link maintenance, pre-fetching, building a search
   index, etc.

幂等：多发一次和只发一次，意图效果相同

   A request method is considered "idempotent" if the intended effect on
   the server of multiple identical requests with that method is the
   same as the effect for a single such request.  Of the request methods
   defined by this specification, PUT, DELETE, and safe request methods
   are idempotent.

   Like the definition of safe, the idempotent property only applies to
   what has been requested by the user; a server is free to log each
   request separately, retain a revision control history, or implement
   other non-idempotent side effects for each idempotent request.

   Idempotent methods are distinguished because the request can be
   repeated automatically if a communication failure occurs before the
   client is able to read the server's response.  For example, if a
   client sends a PUT request and the underlying connection is closed
   before any response is received, then the client can establish a new
   connection and retry the idempotent request.  It knows that repeating
   the request will have the same intended effect, even if the original
   request succeeded, though the response might differ.

   A client SHOULD NOT automatically retry a request with a non-
   idempotent method unless it has some means to know that the request
   semantics are actually idempotent, regardless of the method, or some
   means to detect that the original request was never applied.

   For example, a user agent can repeat a POST request automatically if
   it knows (through design or configuration) that the request is safe
   for that resource.  Likewise, a user agent designed specifically to
   operate on a version control repository might be able to recover from
   partial failure conditions by checking the target resource
   revision(s) after a failed connection, reverting or fixing any
   changes that were partially applied, and then automatically retrying
   the requests that failed.

   Some clients take a riskier approach and attempt to guess when an
   automatic retry is possible.  For example, a client might
   automatically retry a POST request if the underlying transport
   connection closed before any part of a response is received,
   particularly if an idle persistent connection was used.

   A proxy MUST NOT automatically retry non-idempotent requests.  A
   client SHOULD NOT automatically retry a failed automatic retry.

IANA 方法登记：Safe / Idempotent

                 | Method  | Safe | Idempotent | Section |
                 +=========+======+============+=========+
                 | CONNECT | no   | no         | 9.3.6   |
                 +---------+------+------------+---------+
                 | DELETE  | no   | yes        | 9.3.5   |
                 +---------+------+------------+---------+
                 | GET     | yes  | yes        | 9.3.1   |
                 +---------+------+------------+---------+
                 | HEAD    | yes  | yes        | 9.3.2   |
                 +---------+------+------------+---------+
                 | OPTIONS | yes  | yes        | 9.3.7   |
                 +---------+------+------------+---------+
                 | POST    | no   | no         | 9.3.3   |
                 +---------+------+------------+---------+
                 | PUT     | no   | yes        | 9.3.4   |
                 +---------+------+------------+---------+
                 | TRACE   | yes  | yes        | 9.3.8   |
                 +---------+------+------------+---------+
                 | *       | no   | no         | 18.2    |
                 +---------+------+------------+---------+

                                  Table 7

谁带主机名

   The "Host" header field in a request provides the host and port
   information from the target URI, enabling the origin server to
   distinguish among resources while servicing requests for multiple
   host names.

   In HTTP/2 [HTTP/2] and HTTP/3 [HTTP/3], the Host header field is, in
   some cases, supplanted by the ":authority" pseudo-header field of a
   request's control data.

     Host = uri-host [ ":" port ] ; Section 4

   The target URI's authority information is critical for handling a
   request.  A user agent MUST generate a Host header field in a request
   unless it sends that information as an ":authority" pseudo-header
   field.  A user agent that sends Host SHOULD send it as the first
   field in the header section of a request.

   For example, a GET request to the origin server for
   <http://www.example.org/pub/WWW/> would begin with:

   GET /pub/WWW/ HTTP/1.1
   Host: www.example.org

GET、POST、PUT 的意图差在哪

   The GET method requests transfer of a current selected representation
   for the target resource.  A successful response reflects the quality
   of "sameness" identified by the target URI (Section 1.2.2 of [URI]).
   Hence, retrieving identifiable information via HTTP is usually
   performed by making a GET request on an identifier associated with
   the potential for providing that information in a 200 (OK) response.

[……节选 GET 其余段落，下接 POST]

   The POST method requests that the target resource process the
   representation enclosed in the request according to the resource's
   own specific semantics.  For example, POST is used for the following
   functions (among others):

   *  Providing a block of data, such as the fields entered into an HTML
      form, to a data-handling process;

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

   *  Creating a new resource that has yet to be identified by the
      origin server; and

   *  Appending data to a resource's existing representation(s).

[……节选 POST 响应语义，下接 PUT]

   The PUT method requests that the state of the target resource be
   created or replaced with the state defined by the representation
   enclosed in the request message content.  A successful PUT of a given
   representation would suggest that a subsequent GET on that same
   target resource will result in an equivalent representation being
   sent in a 200 (OK) response.  However, there is no guarantee that
   such a state change will be observable, since the target resource
   might be acted upon by other user agents in parallel, or might be
   subject to dynamic processing by the origin server, before any
   subsequent GET is received.  A successful response only implies that
   the user agent's intent was achieved at the time of its processing by
   the origin server.

[……节选 PUT 约束与校验器，下接与 POST 的对照]

   The fundamental difference between the POST and PUT methods is
   highlighted by the different intent for the enclosed representation.
   The target resource in a POST request is intended to handle the
   enclosed representation according to the resource's own semantics,
   whereas the enclosed representation in a PUT request is defined as
   replacing the state of the target resource.  Hence, the intent of PUT
   is idempotent and visible to intermediaries, even though the exact
   effect is only known by the origin server.

三位数字与五类

   The status code of a response is a three-digit integer code that
   describes the result of the request and the semantics of the
   response, including whether the request was successful and what
   content is enclosed (if any).  All valid status codes are within the
   range of 100 to 599, inclusive.

   The first digit of the status code defines the class of response.
   The last two digits do not have any categorization role.  There are
   five values for the first digit:

   *  1xx (Informational): The request was received, continuing process

   *  2xx (Successful): The request was successfully received,
      understood, and accepted

   *  3xx (Redirection): Further action needs to be taken in order to
      complete the request

   *  4xx (Client Error): The request contains bad syntax or cannot be
      fulfilled

   *  5xx (Server Error): The server failed to fulfill an apparently
      valid request

[……下接可扩展性与非法值]

   HTTP status codes are extensible.  A client is not required to
   understand the meaning of all registered status codes, though such
   understanding is obviously desirable.  However, a client MUST
   understand the class of any status code, as indicated by the first
   digit, and treat an unrecognized status code as being equivalent to
   the x00 status code of that class.

   For example, if a client receives an unrecognized status code of 471,
   it can see from the first digit that there was something wrong with
   its request and treat the response as if it had received a 400 (Bad
   Request) status code.  The response message will usually contain a
   representation that explains the status.

   Values outside the range 100..599 are invalid.  Implementations often
   use three-digit integer values outside of that range (i.e., 600..999)
   for internal communication of non-HTTP status (e.g., library errors).
   A client that receives a response with an invalid status code SHOULD
   process the response as if it had a 5xx (Server Error) status code.

[……下接 IANA 登记表 Table 8]

            | Value | Description                   | Section |
            +=======+===============================+=========+
            | 100   | Continue                      | 15.2.1  |
            +-------+-------------------------------+---------+
            | 101   | Switching Protocols           | 15.2.2  |
            +-------+-------------------------------+---------+
            | 200   | OK                            | 15.3.1  |
            +-------+-------------------------------+---------+
            | 201   | Created                       | 15.3.2  |
            +-------+-------------------------------+---------+
            | 202   | Accepted                      | 15.3.3  |
            +-------+-------------------------------+---------+
            | 203   | Non-Authoritative Information | 15.3.4  |
            +-------+-------------------------------+---------+
            | 204   | No Content                    | 15.3.5  |
            +-------+-------------------------------+---------+
            | 205   | Reset Content                 | 15.3.6  |
            +-------+-------------------------------+---------+
            | 206   | Partial Content               | 15.3.7  |
            +-------+-------------------------------+---------+
            | 300   | Multiple Choices              | 15.4.1  |
            +-------+-------------------------------+---------+
            | 301   | Moved Permanently             | 15.4.2  |
            +-------+-------------------------------+---------+
            | 302   | Found                         | 15.4.3  |
            +-------+-------------------------------+---------+
            | 303   | See Other                     | 15.4.4  |
            +-------+-------------------------------+---------+
            | 304   | Not Modified                  | 15.4.5  |
            +-------+-------------------------------+---------+
            | 305   | Use Proxy                     | 15.4.6  |
            +-------+-------------------------------+---------+
            | 306   | (Unused)                      | 15.4.7  |
            +-------+-------------------------------+---------+
            | 307   | Temporary Redirect            | 15.4.8  |
            +-------+-------------------------------+---------+
            | 308   | Permanent Redirect            | 15.4.9  |
            +-------+-------------------------------+---------+
            | 400   | Bad Request                   | 15.5.1  |
            +-------+-------------------------------+---------+
            | 401   | Unauthorized                  | 15.5.2  |
            +-------+-------------------------------+---------+
            | 402   | Payment Required              | 15.5.3  |
            +-------+-------------------------------+---------+
            | 403   | Forbidden                     | 15.5.4  |
            +-------+-------------------------------+---------+
            | 404   | Not Found                     | 15.5.5  |
            +-------+-------------------------------+---------+
            | 405   | Method Not Allowed            | 15.5.6  |
            +-------+-------------------------------+---------+
            | 406   | Not Acceptable                | 15.5.7  |
            +-------+-------------------------------+---------+
            | 407   | Proxy Authentication Required | 15.5.8  |
            +-------+-------------------------------+---------+
            | 408   | Request Timeout               | 15.5.9  |
            +-------+-------------------------------+---------+
            | 409   | Conflict                      | 15.5.10 |
            +-------+-------------------------------+---------+
            | 410   | Gone                          | 15.5.11 |
            +-------+-------------------------------+---------+
            | 411   | Length Required               | 15.5.12 |
            +-------+-------------------------------+---------+
            | 412   | Precondition Failed           | 15.5.13 |
            +-------+-------------------------------+---------+
            | 413   | Content Too Large             | 15.5.14 |
            +-------+-------------------------------+---------+
            | 414   | URI Too Long                  | 15.5.15 |
            +-------+-------------------------------+---------+
            | 415   | Unsupported Media Type        | 15.5.16 |
            +-------+-------------------------------+---------+
            | 416   | Range Not Satisfiable         | 15.5.17 |
            +-------+-------------------------------+---------+
            | 417   | Expectation Failed            | 15.5.18 |
            +-------+-------------------------------+---------+
            | 418   | (Unused)                      | 15.5.19 |
            +-------+-------------------------------+---------+
            | 421   | Misdirected Request           | 15.5.20 |
            +-------+-------------------------------+---------+
            | 422   | Unprocessable Content         | 15.5.21 |
            +-------+-------------------------------+---------+
            | 426   | Upgrade Required              | 15.5.22 |
            +-------+-------------------------------+---------+
            | 500   | Internal Server Error         | 15.6.1  |
            +-------+-------------------------------+---------+
            | 501   | Not Implemented               | 15.6.2  |
            +-------+-------------------------------+---------+
            | 502   | Bad Gateway                   | 15.6.3  |
            +-------+-------------------------------+---------+
            | 503   | Service Unavailable           | 15.6.4  |
            +-------+-------------------------------+---------+
            | 504   | Gateway Timeout               | 15.6.5  |
            +-------+-------------------------------+---------+
            | 505   | HTTP Version Not Supported    | 15.6.6  |
            +-------+-------------------------------+---------+

                                  Table 8