flashman
← All guides

HTTP 207 Multi-Status and partial-result handling

Handle HTTP 207 Multi-Status responses by parsing WebDAV XML, mapping resource and property outcomes, defining retries, preserving identity, and testing clients.

2026-09-26 · 8 min read

  • http
  • webdav
  • reliability

HTTP 207 Multi-Status represents several resource or property outcomes in one response, principally for WebDAV methods. The body commonly contains a DAV multistatus XML document with response elements and embedded HTTP status lines.

The 2xx class of the outer response only indicates that a multi-status report is available. Applications must inspect every relevant member before declaring a batch successful.

Model the request-to-result relationship

Assign stable identities to requested resources and define how returned href values map to them. Record method semantics, request URI, Depth and conditional fields, expected members, and whether the server can include additional related resources.

  • Preserve percent-encoding until structural URL parsing.
  • Resolve relative href values against the correct base.
  • Detect duplicate or missing result identities.
  • Do not rely on response element ordering.

Parse XML and status lines correctly

Use a namespace-aware, hardened XML parser and match elements by namespace URI plus local name rather than a chosen prefix. Disable unsafe external entity resolution and enforce document, depth, text, and element limits.

Parse embedded status values as complete HTTP status lines. Preserve unknown extension elements where interoperability requires it, but never treat free-form response descriptions as trusted HTML.

Distinguish resource and property outcomes

A response can carry one status for a resource or several propstat groups that classify individual properties. Normalize these forms without flattening a successful resource retrieval into failure merely because one optional property was unavailable.

Create an application result model that retains href, status, property names, structured error details, and safe diagnostics. Keep authorization failures separate from absence and conflict.

Design partial retry and reconciliation

Classify failures by method safety, idempotency, preconditions, and server guidance. Retry only eligible failed operations, preserve successful outcomes, cap attempts, and reconcile server state after timeouts or malformed responses.

Do not automatically follow href or location-like values across origins with credentials. Apply the original authorization boundary, redirect policy, deadline, and cancellation to every follow-up.

Maintain a mixed-outcome suite

Use Flashman's XML formatter for synthetic multistatus bodies, URL tool for href resolution, diff for member sets, JSON formatter for normalized results, and hash tool for public fixture identity.

Cover all-success, all-failure, and mixed batches; propstat groups; arbitrary prefixes; relative and encoded hrefs; redirects; unknown statuses; duplicate resources; malformed XML; oversized bodies; retries; permissions; proxies; and legacy clients.

Try these tools