# RFC9110 + RFC5789 key clauses (captured)
captured_at=2026-03-01T16:01:55Z

## RFC9110
source=https://www.rfc-editor.org/rfc/rfc9110
279:       15.5.1.  400 Bad Request
282:       15.5.4.  403 Forbidden
283:       15.5.5.  404 Not Found
288:       15.5.10. 409 Conflict
289:       15.5.11. 410 Gone
290:       15.5.12. 411 Length Required
291:       15.5.13. 412 Precondition Failed
292:       15.5.14. 413 Content Too Large
293:       15.5.15. 414 URI Too Long
294:       15.5.16. 415 Unsupported Media Type
295:       15.5.17. 416 Range Not Satisfiable
296:       15.5.18. 417 Expectation Failed
297:       15.5.19. 418 (Unused)
386:   interface, extensible semantics, and self-descriptive messages to
444:   All three major versions of HTTP rely on the semantics defined by
450:   This revision of HTTP separates the definition of semantics (this
453:   independently while referring to the same core semantics.
466:   semantics in relation to the identified target resource, and responds
469:   out, determining what to do next based on the status codes and
472:   HTTP semantics include the intentions defined by each request method
473:   (Section 9), extensions to those semantics that might be described in
474:   request header fields, status codes that describe the response
581:   the semantics of protocol elements sent.  For example, a client that
631:   the semantics defined for it by this specification, including
634:   implements what is implied by those semantics.  For example, an
642:   specific error handling mechanisms except when they have a direct
644:   require different error handling strategies.  For example, a Web
647:   systems control client might consider any form of error recovery to
662:   While HTTP's core semantics don't change between protocol versions,
678:   semantics or implying additional capabilities of the sender.
706:   request semantics, which is made possible by vesting the request
707:   semantics in the request method (Section 9) and a few request-
709:   manner inconsistent with the semantics of the method of the request.
710:   For example, though the URI of a resource might imply semantics that
769:   message's semantics can be understood in isolation, and that the
800:   "response" messages, each including a status code (Section 15).  The
803:   interpreted in accordance with the status code, and trailer fields to
830:   reporting of errors to the user, it is acceptable for such reporting
831:   to only be observable in an error console or log file.  Likewise,
943:   mistakenly violating HTTP semantics.
1217:   its presence as an error; it is likely being used to obscure the
1272:   the semantics that users will associate with a URI, and the
1273:   usefulness of those semantics is what ultimately transforms these
1426:   error.  Automated clients MUST log the error to an appropriate audit
1428:   certificate error).  Automated clients MAY provide a configuration
1462:   semantics defined by that name.  For example, the Date header field
1481:   their defined semantics allow them to be safely ignored by recipients
1519:   the semantics of the message, by appending each subsequent field line
1566:   specific field's semantics.
1570:   appropriate 4xx (Client Error) status code.  Ignoring such header
1575:   than the client wishes to process if the field semantics are such
1577:   message framing or response semantics.
1629:   detecting such errors improves interoperability.  Fields that expect
1762:   OWS and RWS have the same semantics as a single SP.  Any content
1771:   BWS has no semantics.  Any content known to be defined as BWS MAY be
1824:   might not be case-sensitive, depending on the semantics of the
1919:   semantics of day-name, day, month, year, and time-of-day are the same
1944:   common structure, and capacity for conveying semantics.  This
1975:   semantics, and trailer fields provide optional metadata that was
2016:   level error indicates that it is not complete.
2023:   Response message control data includes a status code (Section 15),
2051:   from the response status code or header fields (e.g., Server) that
2078:   semantics, describe the sender, define the content, or provide
2110:   semantics (Section 9).
2119:   method, response status code (Section 15), and response fields
2123:   date (Section 6.6.1), whereas the content of the same status code in
2132:   Response messages with an error status code usually contain content
2133:   that represents the error condition, such that the content describes
2134:   the error state and what steps are suggested for resolving it.
2178:   1.  If the request method is HEAD or the response status code is 204
2182:   2.  If the request method is GET and the response status code is 200
2186:   3.  If the request method is GET and the response status code is 203
2191:   4.  If the request method is GET and the response status code is 206
2218:   fields in the header section to avoid contradicting message semantics
2276:   name have the equivalent semantics as appending the multiple values
2296:   message was originated, having the same semantics as the Origination
2450:   semantics and, if so, where that request is to be directed.
2494:   client to a different resource, respond with an error, or drop the
2517:   The 421 (Misdirected Request) status code in a response indicates
2528:   All responses, regardless of the status code (including interim

## RFC5789
source=https://www.rfc-editor.org/rfc/rfc5789.txt
13:                         PATCH Method for HTTP
20:   This proposal adds a new HTTP method, PATCH, to modify an existing
60:RFC 5789                       HTTP PATCH                     March 2010
66:   2. The PATCH Method ................................................2
67:      2.1. A Simple PATCH Example .....................................4
82:   This specification defines the new HTTP/1.1 [RFC2616] method, PATCH,
83:   which is used to apply partial modifications to a resource.
86:   errors.  The PUT method is already defined to overwrite a resource
91:   discover patch format support).  PATCH was mentioned in earlier HTTP
94:   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
95:   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
101:2.  The PATCH Method
103:   The PATCH method requests that a set of changes described in the
116:RFC 5789                       HTTP PATCH                     March 2010
119:   The difference between the PUT and PATCH requests is reflected in the
124:   be replaced.  With PATCH, however, the enclosed entity contains a set
126:   origin server should be modified to produce a new version.  The PATCH
130:   PATCH.
132:   PATCH is neither safe nor idempotent as defined by [RFC2616], Section
135:   A PATCH request can be issued in such a way as to be idempotent,
137:   PATCH requests on the same resource in a similar time frame.
138:   Collisions from multiple PATCH requests may be more dangerous than
141:   using this kind of patch application SHOULD use a conditional request
144:   can use a strong ETag [RFC2616] in an If-Match header on the PATCH
152:   The server MUST apply the entire set of changes atomically and never
155:   cannot be successfully applied, then the server MUST NOT apply any of
157:   PATCH can vary depending on the patch document and the type of
160:   directory hierarchy.  The atomicity requirement holds for all
162:   details on status codes and possible error conditions.
165:   one or more currently cached entities, those entries SHOULD be
172:RFC 5789                       HTTP PATCH                     March 2010
177:   header matching the Request-URI, indicating that the PATCH response
178:   body is a resource representation.  A cached PATCH response can only
179:   be used to respond to subsequent GET and HEAD requests; it MUST NOT
180:   be used to respond to other methods (in particular, PATCH).
183:   contained patch document and MUST NOT be applied to the resource
186:   the patch document had a language.  Servers SHOULD NOT store such
187:   headers except as trace information, and SHOULD NOT use such header
193:   There is no guarantee that a resource can be modified with PATCH.
198:   are required to support.  Servers MUST ensure that a received patch
202:   Clients need to choose when to use PATCH rather than PUT.  For
205:   sense to use PUT instead of PATCH.  A comparison to POST is even more
207:   encompass PUT and PATCH-like operations if the server chooses.  If
209:   URI in a predictable way, POST should be considered instead of PATCH
212:2.1.  A Simple PATCH Example
214:   PATCH /file.txt HTTP/1.1
228:RFC 5789                       HTTP PATCH                     March 2010
234:   Successful PATCH response to existing text file:
245:   entity created by applying the PATCH, available at
251:   There are several known conditions under which a PATCH request can
256:      SHOULD return a 400 (Bad Request) response.  The definition of
262:      identified by the Request-URI.  Such a response SHOULD include an
274:      more specific errors like "Conflicting State" that could be
275:      signaled with this status code, but the more specific error would
284:RFC 5789                       HTTP PATCH                     March 2010
301:      precondition failed, then the 412 (Precondition Failed) error is
308:   Concurrent modification:  Some applications of PATCH might require
313:      indicate this error by using a 409 (Conflict) response.
325:   The entity body of error responses SHOULD contain enough information
326:   to communicate the nature of the error to the client.  The content-
340:RFC 5789                       HTTP PATCH                     March 2010
345:   A server can advertise its support for the PATCH method by adding it
347:   header defined in HTTP/1.1.  The PATCH method MAY appear in the
355:   Accept-Patch SHOULD appear in the OPTIONS response for any resource
356:   that supports the use of the PATCH method.  The presence of the
358:   indication that PATCH is allowed on the resource identified by the
383:   Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
386:   The examples show a server that supports PATCH generally using two
396:RFC 5789                       HTTP PATCH                     March 2010
416:   The security considerations for PATCH are nearly identical to the
420:   transport errors or through accidental overwrites.  Whatever
421:   mechanisms are used for PUT can be used for PATCH as well.  The
422:   following considerations apply especially to PATCH.
428:   Section 2.  If a PATCH request fails, the client can issue a GET
431:   if the PATCH request can be resent, but in other cases, the attempt
433:   of a failure of the underlying transport channel, where a PATCH
442:   response.  The PATCH method complicates such watch-keeping because
452:RFC 5789                       HTTP PATCH                     March 2010
463:   documents.  Servers MUST take adequate precautions to ensure that
465:   CPU, disk I/O) through the client's use of PATCH.
