---
# System prepended metadata

title: '#19.3 HTTP method 共同研究會 - POST'
tags: [Meetups]

---

---
title: "#19.3 HTTP method 共同研究會 - POST"
tags: Meetups
date: 2022-04-14
---

[4.3.3](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.3). POST

# 4.3.3 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
*   Appending data to a resource's existing representation(s)

 POST 方法是根據資源需求格式做資源請求。
 
  An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).

[304_Etag, If-None-Match](https://easonwang.gitbook.io/web_advance/liu-lan-qi-kuai-qu-yu-huan-cun)
[Nginx_Etag](http://nginx.org/en/docs/http/ngx_http_core_module.html#etag)

  If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and a representation that describes the status of the request while referring to the new resource(s).

  Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented.  For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).

  If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field.  This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.
