---
title: "#19.1 HTTP method 共同研究會 - Properties"
tags: Meetups
date: 2022-03-31
---

Safe Methods

> 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.

Client 在使用 safe method 的時候，不請求也不預期 server 的狀態會改變。

Server 在被呼叫 safe method 的時候，不會有非預期的傷害或損失。

> 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 crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.

safe method 定義無法避免實作的行為造成傷害，或是產生副作用。更重要的 client 沒有請求額外的行為並且無法為此負責。

e.g.1 大部分 server 都會在請求時候寫 access log，即使是 safe method 還是會發生空間滿了或爆了。
e.g.2 一個取得廣告的 safe method，還是會有對廣告主收費的副作用。

   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.

區分 safe 和 unsafe 是允許爬蟲取得資料或是優化 cache 效能，而不用擔心 server 會改變狀態。

此外，它可以用來限制 UA 存取不受信任的內容

   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.

當要呈現一個有可能有風險的動作時，UA 應該要區分安全與不安全的方法給使用者。

使用者在執行方法前可以知道它是不安全的。

   When a resource is constructed such that parameters within the
   effective request 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.

GET /page?do=delete ，因為 GET 是 safe method，所以資源擁有者必須 reject

POST /page?do=delete ，因為 POSt 不是 safe method，所以可以執行。

---

Idempotent Methods

   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.

執行多次 request 對 server 造成的效果，與執行一次是一樣的。

PUT 與 DELETE，和 safe method 都是 idempotent method

   Like the defiition 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 只能適用於使用者請求的內容。

server 可以記錄每次請求的 log 或是版本控制歷程，或是其他 non-idempotent 的副作用。

   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.

Idempotent methods 的好處在於，因為在斷線的時候，client 可以重覆執行。

如，發 PUT request 時，當底層連線斷線的時候，可以再重新建立一個新的 PUT request

Idempotent methods 是可以 retry 的

4.2.3. Cacheable Methods

   Request methods can be defined as "cacheable" to indicate that
   responses to them are allowed to be stored for future reuse; for
   specific requirements see [RFC7234].  In general, safe methods that
   do not depend on a current or authoritative response are defined as
   cacheable; this specification defines GET, HEAD, and POST as
   cacheable, although the overwhelming majority of cache
   implementations only support GET and HEAD.

不依賴當前回傳內容或是 authoritative response 的 safe method，就定義可以被快取。

規範定義 GET HEAD POST 為 Cacheable Methods，大部分實作都是 GET HEAD。