Summary

  • WebDAV bindings let multiple URIs reach one resource. When the resource is a collection, a second binding can expose the same descendants through another path and can even create a cycle.
  • In a bind-aware Depth: infinity PROPFIND, one binding to the collection is reported with 200. Later bindings remain visible with 208 Already Reported, but their descendants are not enumerated again.
  • DAV:resource-id supplies stable resource identity beneath changing paths. A correct client preserves every binding edge while expanding each shared collection once; an unaware client receives loop failure through 508 instead of a compressed structure it cannot interpret.

Two doors were allowed to open into one room

Imagine an archive with two labelled doors. Each door is real, each belongs to a different corridor, and both open into the same records room. Removing either door changes the archive's navigation. It does not destroy the room while the other door remains.

Now ask an inventory system to walk every corridor and list every cabinet beneath every door. If it treats paths as entities, it inventories the same room twice. If one of the room's corridors leads back to an ancestor, the inventory may never end. If it simply deletes the second path when it recognises the room, it produces a finite list by falsifying the building.

HTTP 208 represented the missing fourth choice. Record the second door. Prove that it reaches a room already expanded. Do not walk the room's descendants again.

The result was neither tree enumeration nor aggressive deduplication. It was a graph reported with two kinds of identity.

WebDAV had already made collection results plural

RFC 4918, the 2007 WebDAV specification, describes a collection as mappings between path segments and resources together with properties on the collection. A member name is therefore not the resource itself. It is part of the route by which a request reaches one.

PROPFIND lets a client inspect properties at depth zero, one or infinity. A depth-infinity request asks for the collection and all descendants. The result is not a nested HTTP response for every member. The server returns an overall 207 Multi-Status document containing a flat set of DAV:response entries, each with an href and property statuses.

That structure already required clients to separate the outer transport result from the inner account. An overall 207 could carry a mixture of statuses. The client had to inspect each response and each propstat rather than treating the envelope as one verdict.

RFC 4918 also acknowledged that one resource could be identified by more than one URI. What it did not yet supply was a client method devoted to creating another access path to an existing resource.

BIND created another name, not another resource

The Experimental RFC 5842, published in April 2010, added BIND, UNBIND and REBIND to WebDAV. BIND associates a new path segment in a collection with an existing resource. The resulting URI can be used to send methods to that resource just like another mapped URI.

Nothing is copied. The additional binding is new; the resource is not. Two different collections can each contain a binding that points to the same resource, and those are two distinct pieces of collection state.

This distinction has operational consequences. Removing one binding must not turn another into a dangling path. The server must not reclaim the resource while another binding remains. Binding integrity means that a path continues to exist and continues to identify the same resource until an operation explicitly removes or changes that binding.

An alias is therefore not disposable decoration. It is an independently governed edge to a shared entity.

A bound collection multiplied paths beneath it

When a new binding points to an ordinary leaf resource, it creates another URI mapping to that resource. When it points to a collection, every descendant becomes reachable through a corresponding new URI path even though no new descendant bindings were added.

The distinction is subtle. The child relations remain state of the one collection. But because the collection itself now has two routes, those relations can be traversed beneath two prefixes.

The effect becomes unbounded if a collection is bound to itself or to one of its ancestors. The namespace can generate /myself, /myself/myself, /myself/myself/myself and so on without creating an infinite number of resources. What becomes infinite is the set of URI mappings produced by repeated traversal.

Servers must detect collection-binding loops while processing Depth: infinity. They may refuse to create loops at all, because support for loops is optional. If loops are admitted, however, traversal cannot pretend that a hierarchy is still a simple tree.

Stable resource identity sat beneath changing routes

Path equality cannot solve the problem: the whole point is that different paths may reach one resource. Content equality cannot solve it either: two independent resources may happen to contain identical bytes and properties.

RFC 5842 therefore requires DAV:resource-id. It is assigned when a resource is created, must be unique across all resources for all time, must not change when the existing resource is updated or rebound, and must not be reassigned even after the resource is no longer reachable through a URI.

If two PROPFIND results obtained through different bindings return character-for-character identical resource IDs, the client can know that the bindings reach the same resource. The identity is not a preferred address. It remains stable while addresses multiply or move.

This is the evidence 208 needs. The client can distinguish “another route to what I have already expanded” from “another object that merely looks similar.”

Depth infinity turned a hierarchy into a graph walk

A traditional directory walker often keys its work by pathname: visit the path, enumerate the children, recurse. Bindings make that rule unsafe because path identity and resource identity diverge.

Keying only by path preserves every route but can repeatedly expand one collection and follow a cycle forever. Keying only by resource ID avoids repeated work, but if applied before the binding is recorded, it erases real namespace edges. The client then knows the entity but not every place from which it can be reached.

A faithful traversal needs two ledgers. One records binding paths. The other records which collection identities have already had their descendants enumerated in this response.

HTTP 208 is the protocol mark connecting those ledgers. It says: keep this path in the first ledger; the second ledger explains why no new subtree follows it.

208 kept the alias and removed only the repetition

The exact rule is narrow. A server can use 208 inside a DAV:propstat response element for a Depth: infinity request. Among bindings to the same collection within scope, one is reported with 200. Later DAV:response entries for the other bindings carry 208, and their descendants are not included again.

The later response entry does not vanish. Its href still identifies the alternative path, and the client can request and compare DAV:resource-id to reconstruct the binding structure accurately. What disappears is only a second enumeration of descendants already reported through the 200 occurrence.

In the RFC's loop example, /Coll/ and /Coll/Bar expose the same collection identity. The first receives 200 and its members are listed. The second receives 208. There is no /Coll/Bar/Bar/Bar procession because the collection behind that path has already been walked.

“Already reported” modifies the expansion history of this Multi-Status response. It does not pronounce the alias unimportant.

The first 200 did not crown a canonical URI

It is tempting to treat the path expanded with 200 as the original and every 208 path as a lesser duplicate. RFC 5842 does not create that hierarchy of rights.

The bindings are distinct relations in collection state. One occurrence must be chosen for descendant enumeration so that the response is finite, but the choice does not make that URI permanent, canonical or entitled to destroy the others.

This matters when a client presents namespace structure, evaluates audit history or later removes a binding. Collapsing the graph into one favoured pathname can hide which collection owns each edge and can turn a legitimate UNBIND into apparent deletion of the resource itself.

The 200/208 difference is local to reporting work. It is not an ownership rule.

207 remained the envelope

An HTTP client normally sees the request-level response first: 207 Multi-Status. The 208 appears within a property status for one of the response entries.

This nesting prevents two mistakes. A top-level 2xx result cannot tell a client that every descendant was independently expanded. Conversely, an inner 208 does not mean the entire request was a repeated request or that every resource was previously returned.

The outer layer says that the detailed account is in the body. The inner 200 and 208 values say how individual binding occurrences participated in that account. href preserves path identity; DAV:resource-id joins paths that reach the same entity; the presence or absence of descendants shows which occurrence paid the traversal cost.

Flattening these layers into “request succeeded” discards the structure that made finite graph reporting possible.

Compression required prior understanding

Omitting a repeated subtree is safe only if the recipient understands why it is absent. RFC 5842 therefore tied 208 to capability signalling.

A server that supports bindings announces the bind compliance class in the DAV response header to OPTIONS. A client should send DAV: bind to signal support and, in particular, must understand 208.

For backward compatibility, the server should not use 208 in a Multi-Status body unless the client has made that signal. An older client might treat the unknown property status as failure, or might retain the path but conclude incorrectly that its children do not exist.

The saved repetition is not a private server optimisation. It is a shared interpretation contract between endpoints.

508 was failure, not a harsher spelling of 208

When a non-bind-aware depth-infinity client encounters a binding loop, the specification directs the server toward 508 Loop Detected instead of relying on a 208 the client cannot interpret. If the loop is found before response streaming begins, 508 can be the top-level result. If discovery comes during a streamed Multi-Status, the failure can be represented there.

The control outcome is different. With 208, the bind-aware traversal can continue: the alias is recorded and repeated descendants are suppressed. With 508, the server terminates because infinite traversal was encountered, and the operation fails.

Returning 508 can sacrifice a useful partial view, but it does not invite an unaware client to accept a structure whose omissions it cannot explain. Returning 208 without agreement might look more available while silently producing a false tree.

Compatibility sometimes prefers an explicit stop to an incompletely understood success.

The same graph created security costs

Bindings increase expressive power and the number of identities a server must keep straight. RFC 5842 notes that clients can create loops accidentally or maliciously and requires loop detection during depth-infinity processing.

The specification also identifies denial-of-service and privacy risks. Cross-server bindings can direct use toward a target not designed for that load. The optional DAV:parent-set property can reveal directory locations and can itself become a resource-exhaustion surface if a server maintains lists influenced by other administrative domains.

208 controls repeated enumeration in one response. It does not supply a complete resource budget, authorization policy or defence against hostile binding creation. A finite graph walk can still be too large, and an accurately recorded alternative path can still reveal sensitive structure.

The status contains one amplification mechanism. It does not abolish the need to govern who may create edges and how much traversal may consume.

Live properties kept the path in the picture

Identical resource ID does not mean every answer obtained through two bindings must be byte-for-byte identical. Dead-property values are independent of binding count and submitted path, but live properties follow their own definitions and can have path-related behaviour.

A client that merges every property solely by resource ID may therefore erase context. A client that treats every property occurrence as proof of a distinct resource commits the opposite error.

The useful data model retains resource facts, binding facts and path-dependent observations separately. That is the same thin discipline expressed by 208 itself: share the minimum identity needed for correct coordination, and do not promote one layer's evidence into authority over every other layer.

Plural paths can remain plural without multiplying the underlying entity.

IANA registered a success that meant “do not recurse again”

The current IANA HTTP Status Code Registry lists 208 Already Reported with RFC 5842 as its reference. The same Experimental document defined 508, while 207 continues to point to the Standards Track WebDAV specification.

The registration does not turn the binding extension into an Internet Standard, prove current deployment or generalise 208 to every API that sees duplicate data. Its defined home remains a WebDAV binding-aware, depth-infinity, Multi-Status traversal.

It is not a database deduplication result, an idempotency receipt, a cache validator or a signal that a client repeated its HTTP request. It reports a relationship inside one namespace account.

The code's endurance comes from the precision of that relationship, not the breadth of its use.

One entity, every path, one expansion

HTTP 208 solved a graph problem without pretending that the graph was a tree. It did not choose between infinite repetition and destructive deduplication.

The server reports each binding path because paths are real namespace state. It assigns stable identity because a resource is not reducible to one of those paths. It expands the collection once because repeated descendants add no new resource structure. It signals 208 because omission without explanation would be indistinguishable from missing data.

The arrangement is deliberately modest. No central path becomes sovereign. No alias is promoted into a copy. No repeated walk is allowed to manufacture an infinite inventory.

The second door stays on the plan. The room behind it does not need to be counted twice.