PROPPATCH HTTP Method — Reference

What it does

PROPPATCH is PROPFIND's write counterpart — it sets or removes properties on a resource, all in a single atomic transaction. "Atomic" is the key word: if a PROPPATCH requests five property changes and one of them fails (invalid value, insufficient permissions), the server must roll back all five, not apply four and fail one. You never end up with a resource in a half-updated state.

Semantics

Property	Value	Why it matters
Safe	No	Modifies resource properties
Idempotent	Yes	Setting the same properties to the same values twice leaves the same end state
Cacheable	No	Not a read
Request body	Yes	XML describing which properties to set or remove
Response body	Yes	XML multi-status reporting success/failure per property

Syntax & example request

PROPPATCH /files/documents/report.pdf HTTP/1.1
Host: dav.example.com
Content-Type: application/xml

<?xml version="1.0"?>
<D:propertyupdate xmlns:D="DAV:">
  <D:set>
    <D:prop>
      <D:displayname>Q3 Financial Report</D:displayname>
    </D:prop>
  </D:set>
</D:propertyupdate>

HTTP/1.1 207 Multi-Status
Content-Type: application/xml

<D:multistatus xmlns:D="DAV:">
  <D:response>
    <D:href>/files/documents/report.pdf</D:href>
    <D:propstat>
      <D:prop><D:displayname/></D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

curl example

curl -X PROPPATCH https://dav.example.com/files/documents/report.pdf \
  -H "Content-Type: application/xml" \
  --data '<?xml version="1.0"?><D:propertyupdate xmlns:D="DAV:"><D:set><D:prop><D:displayname>Q3 Financial Report</D:displayname></D:prop></D:set></D:propertyupdate>'

Common status codes returned

207 Multi-Status — the standard response format, reporting per-property success/failure → see 207

PROPPATCH vs PATCH

	PROPPATCH	PATCH
Scope	WebDAV metadata/properties specifically	Any resource, any partial update format
Response format	XML multi-status	Whatever the API defines
Atomicity guarantee	Required by spec — all-or-nothing	Not specified — depends on the API

Both apply partial changes rather than a full replace, but PROPPATCH is WebDAV-specific and comes with a stricter atomicity contract baked into the spec itself.

Real-world usage

WebDAV/CalDAV/CardDAV clients updating metadata like display names, custom properties, or calendar-specific attributes
Sync clients tagging resources with application-specific properties (sync tokens, custom flags) without touching the underlying content

Security considerations

Because PROPPATCH can set arbitrary custom (dead) properties, servers need to validate and sanitize property values just as carefully as any other user-supplied input — especially since some WebDAV clients store structured or scripted content in custom properties, and a server that renders those properties elsewhere (e.g., in an admin UI) without escaping is exposed to the same injection risks as any other unsanitized user input.

FAQ

What happens if one property update in a PROPPATCH fails?

The entire request rolls back — PROPPATCH's atomicity guarantee means either all requested property changes succeed, or none do. The multi-status response tells you which property caused the failure.

Can PROPPATCH remove a property, not just set one?

Yes — the request body distinguishes <D:set> blocks (add/update) from <D:remove> blocks (delete), and both can appear in the same atomic request.

Is PROPPATCH commonly used outside WebDAV file storage?

Its biggest indirect audience is CalDAV and CardDAV — calendar and contacts sync protocols built on top of WebDAV — where PROPPATCH is used to manage calendar/address-book-level properties (display names, colors, sharing settings).

Fun fact

PROPPATCH's mandatory all-or-nothing atomicity is stricter than most REST PATCH implementations bother to guarantee — WebDAV, a protocol most developers think of as "the old file-sharing thing," actually specified transactional partial updates over HTTP years before "atomic PATCH" became a talking point in modern API design.

PROPPATCH