Visual RFC.
ALL RFCs / RFC 5789
Read the RFC ↗
RFC 5789 / MECHANISM GUIDE

Conditional PATCH

03

A strong ETag precondition prevents applying a base-dependent patch to the wrong version.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 2 ↗
RFC 5789 · § 2EXAMPLE
3 / 3
Conditional PATCHA strong ETag precondition prevents applying a base-dependent patch to the wrong version.Conditional PATCHClient base: v7Current: v8If-Match: "v7"v7 ≠ v8412 · stale patch not applied
03
Reject stale patch

The client retrieves current state instead of silently corrupting it.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Clients should use a conditional request when the patch depends on a known base.

  • Clients should use a conditional request when the patch depends on a known base.
  • If-Match can protect against collisions between concurrent edits.
  • Some patch formats are designed for idempotence; the method alone does not guarantee it.
DETAILS

Examples are illustrative. Consult the linked RFC and its errata for implementation details.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Patch versus replacement
  2. Atomic modification
  3. Conditional PATCH
  4. Discover patch formats
  5. Failure and verification
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗