---
title: "#19.6 HTTP method 共同研究會 - PUT 下集"
tags: Meetups
date: 2022-05-05
---

See [RFC-7231 PUT](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.4)

-------------

HTTP does not define exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and the semantics of the origin server response. It does not define what a resource might be, in any sense of that word, beyond the interface provided via HTTP. It does not define how resource state is "stored", nor how such storage might change as a result of a change in resource state, nor how the origin server translates resource state into representations. Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server.

PUT 沒有規範如何更新，這個行為被隱藏在 HTTP 介面之後。

An origin server MUST NOT send a validator header field (Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and the validator field value reflects the new representation. This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).

PUT 請求禁止回傳 validator header，除非是新增的內容跟 PUT request 的內容一致時。

[If-None-Match for PUT 看說明, 更新丟失問題](https://runebook.dev/zh-CN/docs/http/headers/if-none-match)

### Prove of concept

HEAD 要先回傳該 resource etag
後續的 PUT 再做以下驗證

3.1 Saving a Document Not Known to Exist
3.1.1 The document does not already exist
3.1.2 The document already exists
3.1.2.1 If-None-Match 強更
3.1.2.2 If-Match 如果版本不一致就不更新
3.2 Saving a Document Known to Exist
3.2.1 The document has not been changed
3.2.2 The document has been changed
3.2.2.1 If-None-Match
3.2.2.2 If-Match

### PUT v.s. 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.

POST 跟 PUT 基礎的差別是在於對於資料操作的意圖

Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. **A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT.** If the origin server will not make the requested PUT state change to the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved to a different URI, then the origin server MUST send an appropriate 3xx (Redirection) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.

A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.

An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (Section 4.2 of [RFC7233]), since the payload is likely to be partial content that has been mistakenly PUT as a full representation. Partial content updates are possible by targeting a separately identified resource with state that overlaps a portion of the larger resource, or by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789]).

### Not Cacheable
Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).