📜 Reading HTTP Specs

RFC 7231 — HTTP/1.1: Semantics and Content
Section 4.2.2. 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.

   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.

RFC 7231 — HTTP/1.1: Semantics and Content
Section 4.2.1. 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.

   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.  The GET, HEAD, OPTIONS, and TRACE methods are defined as safe.

RFC 7232 — HTTP/1.1: Conditional Requests
Section 3.2. If-None-Match

   The "If-None-Match" header field makes the request method conditional
   on a recipient cache or origin server either not having any current
   representation of the target resource, when the field-value is "*",
   or having a selected representation with an entity-tag that does not
   match any of those listed in the field-value.

   If the field-value is "*", or if a listed entity-tag matches the
   entity-tag of the selected representation, then the origin server
   MUST NOT perform the requested method.  Instead, if the request
   method was GET or HEAD, the server SHOULD respond with a 304 (Not
   Modified) status code.

RFC 7234 — HTTP/1.1: Caching
Section 5.2.2.1. must-revalidate

   The "must-revalidate" response directive indicates that once it has
   become stale, a cache MUST NOT use the response to satisfy subsequent
   requests without successful validation on the origin server.

   The must-revalidate directive is necessary to support reliable
   operation for certain protocol features.  In all circumstances a
   cache MUST obey the must-revalidate directive; in particular, if a
   cache cannot reach the origin server for any reason, it MUST generate
   a 504 (Gateway Timeout) response.

RFC 7231 — HTTP/1.1: Semantics and Content
Section 6.3.3. 202 Accepted

   The 202 (Accepted) status code indicates that the request has been
   accepted for processing, but the processing has not been completed.
   The request might or might not eventually be acted upon, as it might
   be disallowed when processing actually takes place.  There is no
   facility in HTTP for re-sending a status code from an asynchronous
   operation.

   The 202 response is intentionally noncommittal.  Its purpose is to
   allow a server to accept a request for some other process (perhaps a
   batch-oriented process that is only run once per day) without
   requiring that the user agent's connection to the server persist
   until the process is completed.