PROPFIND HTTP Method — Reference

What it does

PROPFIND retrieves properties — metadata like creation date, size, resource type, or custom application-defined properties — from a resource or, recursively, from an entire collection (WebDAV's term for what most people'd call a folder). It's WebDAV's equivalent of "list this directory and tell me everything about each item," which is exactly why it powers the folder browsing in tools like macOS Finder or Windows Explorer when you mount a WebDAV share.

Because a single PROPFIND can return data about many resources at once, its response isn't a simple 200 with one body — it uses HTTP's multi-status mechanism to report on each resource individually, some of which might succeed while others fail.

Semantics

Property	Value	Why it matters
Safe	Yes	Read-only
Idempotent	Yes	Repeating returns the same properties (assuming nothing changed)
Cacheable	No	Multi-status, per-resource responses don't fit standard HTTP caching
Request body	Yes	XML body specifying which properties to retrieve (or `allprop`/`propname`)
Response body	Yes	XML multi-status document, one entry per resource

Syntax & example request

PROPFIND /files/documents/ HTTP/1.1
Host: dav.example.com
Depth: 1
Content-Type: application/xml

<?xml version="1.0"?>
<D:propfind xmlns:D="DAV:">
  <D:prop>
    <D:getcontentlength/>
    <D:getlastmodified/>
  </D:prop>
</D:propfind>

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:getcontentlength>4582931</D:getcontentlength>
        <D:getlastmodified>Tue, 03 Jun 2026 10:15:00 GMT</D:getlastmodified>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

The Depth header controls the scope: 0 for just the target resource, 1 for the resource plus its immediate children, infinity for a full recursive listing (often disabled server-side for performance/DoS reasons).

curl example

curl -X PROPFIND https://dav.example.com/files/documents/ \
  -H "Depth: 1" \
  -H "Content-Type: application/xml" \
  --data '<?xml version="1.0"?><D:propfind xmlns:D="DAV:"><D:allprop/></D:propfind>'

Common status codes returned

207 Multi-Status — the standard response, one status per resource in the body → see 207
404 Not Found — target collection/resource doesn't exist → see 404

PROPFIND vs GET

	PROPFIND	GET
Returns	Metadata/properties	Actual resource content
Can target a whole collection	Yes, recursively via `Depth`	No — one resource at a time
Response format	XML multi-status	Whatever the resource's content type is

Think of PROPFIND as "ls -la" for a WebDAV collection, and GET as "cat" for a single file.

Real-world usage

WebDAV clients (Finder, Windows Explorer, cadaver, Cyberduck) listing directory contents when you browse a mounted WebDAV share
CalDAV/CardDAV clients (calendar and contacts sync) use PROPFIND heavily to discover calendar/address book collections and their properties
Sync clients (Nextcloud, ownCloud) using PROPFIND to detect what's changed since the last sync

Security considerations

Depth: infinity PROPFIND requests against a deep directory tree can be expensive to compute and expensive to transmit — a well-known DoS vector against WebDAV servers, which is why many implementations reject or heavily rate-limit infinite-depth PROPFIND requests by default.

FAQ

What's the Depth header for?

It controls how far PROPFIND recurses: 0 (just this resource), 1 (this resource plus immediate children), or infinity (the whole subtree). Many servers disable infinity by default for performance reasons.

Why does PROPFIND return XML instead of JSON?

WebDAV predates the JSON era — RFC 4918 was published in 2007, when XML was the dominant format for structured API responses. There's no JSON equivalent standardized within WebDAV itself.

Is PROPFIND cacheable?

No — its multi-status, per-resource response structure doesn't map cleanly to standard HTTP freshness/validation caching, and it isn't marked cacheable by the spec.

Fun fact

PROPFIND's multi-status response format (status code 207) was significant enough that it got promoted out of WebDAV and into the core HTTP status code registry — 207 is one of the few status codes whose entire reason for existing is a single method's need to report partial success across multiple resources in one response.

PROPFIND