Summary

  • A 207 SEARCH response proves which records a server returned for a particular grammar, arbiter, scope, principal and execution. It does not by itself prove that the server examined every resource or that missing records failed the predicate.
  • Result truncation may contain any qualifying subset. Ordering constrains the rows that were returned, while access controls, three-valued logic, index state and principal-dependent schema still govern what could appear.

One hundred orderly rows can still be incomplete

The dangerous search result is not necessarily malformed. It may use the right status code, contain valid DAV:response elements and place every visible row in the requested order. An inventory system then counts one hundred files and declares the collection complete. RFC 5323 gives the server a legitimate way to make that conclusion false.

A server may truncate a result set to limit the work required to process or transmit it. It still returns 207 Multi-Status, marks the search arbiter with 507 Insufficient Storage, and should include partial results. The warning is not cosmetic. The specification says many more matching resources may not have been examined and that the returned partial results may be any subset of the set that would satisfy the query.

If the client requested ordering, that subset must be ordered as requested. But sorted does not mean globally highest. The server can return an arbitrary qualifying subset and sort only those records. A client that discards the 507 row while retaining the beautiful order converts a bounded computation into an imaginary census.

RFC 5323 also defines a DAV:limit request. The client can ask for a maximum number of response elements or a bound on effort, but the server may disregard it. When a limited result is ordered, the server should choose the highest-order records. “Should” is not a proof that it did so, and a client-side limit does not explain server-side truncation. The request, response and truncation signal belong in the same record.

The arbiter is not the scope

SEARCH is the transport for a query and its result set. The method does not define the query's semantics; the selected grammar does. The resource named by the Request-URI is the search arbiter—the server-side resource that accepts and executes the query. RFC 5323 expressly declines to equate that arbiter with the scope.

In DAV:basicsearch, DAV:from defines one or more scopes. Each scope has an href and depth. Depth zero includes only the collection, depth one includes the collection and immediate children, and infinity includes all progeny. If the href is relative, it is resolved against the Request-URI; if it is absolute, it can name another URI subject to server support and policy.

This matters when evidence is replayed. Saving the XML predicates without the arbiter and resolved scope cannot reproduce the search. Saving the Request-URI as though it were the scope can place the same query over a different population. Multiple-scope support is optional, and a server that does not support it must fail the request rather than silently pretending the scopes were combined.

Redirect references add another boundary. A reference in scope is not automatically followed unless the relevant behavior is requested and supported. A recursive-looking query can therefore stop at a redirect even when an operator imagines a continuous hierarchy.

UNKNOWN is exclusion without falsity

The DAV:where clause evaluates predicates with three values: TRUE, FALSE and UNKNOWN. A resource joins the result only when the condition is TRUE. That makes nonappearance ambiguous. It may have evaluated FALSE, but it may also have evaluated UNKNOWN.

RFC 5323 treats a property as NULL if PROPFIND would return a non-2xx status for it. NULL is distinct from an empty string. An empty string is a defined value; NULL reflects the lack of an available value in this context. Queries against unreadable properties are evaluated as though the property did not exist, and content predicates against unreadable content are evaluated as though GET would fail.

The security rule is deliberate: SEARCH must not become a way to learn information that GET or PROPFIND would withhold. The consequence is that results are relative to the authenticated principal. Two principals can issue syntactically identical queries to the same arbiter and scope and receive different rows without either response being defective.

An absence therefore cannot carry a single reason. It may mean FALSE, UNKNOWN, out of scope, not examined before truncation, hidden by access control, unsupported redirect traversal, stale index state or a changed collection. A compliant interface should preserve those alternatives instead of reducing them to “does not exist.”

Capability discovery is not execution evidence

The DASL response header and DAV:supported-query-grammar-set advertise grammars supported by a resource. That is enough to discover vocabulary, not enough to construct every valid query. Query Schema Discovery can describe which properties are searchable, selectable and sortable and which optional operators are available.

QSD is optional, and the schema can depend on both arbiter and scope. The specification also notes that principal identity can affect available schema even though all such factors are not exposed by the protocol. A property marked searchable means the server is willing to check it; it does not guarantee the property is defined on every resource.

This is a classic capability boundary. A grammar URI advertises a language the server can understand. It does not prove that a particular query ran, that an index was complete, or that a returned property was current. Nor should software fetch the grammar URI simply because it resembles a retrievable HTTP URL. The URI is an identifier unless the protocol says otherwise.

Result scoring carries the same warning. Scores from different query results are generally not comparable unless the same underlying search system executed both over the same collection. A numeric rank is not a portable quality measure. It is an output of a particular engine, corpus and execution.

A returned URI is a representation choice

For each matching resource, the response contains an href. Yet several URIs within scope may map to the same resource, in which case the server should report only one. The live DAV:resource-id property can help clients identify possible duplicates. It still does not make the chosen href the only name or freeze the mapping forever.

This breaks another common inventory assumption: one row is not necessarily one object, and two missing aliases are not two absent objects. To build durable evidence, keep the returned href, resource identifier when available, property statuses and the server's observation time. Deduplication is a later inference with its own rules.

Successful results also should not be cached. That recommendation matches the nature of the data. Collections, properties, access rights and indexes can change between searches. A response is a time-bound observation, not a perpetual inventory view.

What a defensible search ledger records

Retain the exact request body, grammar identifier, Request-URI, resolved scope URIs, depth values, redirect and version flags, authenticated principal, authorization context, requested properties, predicate tree, ordering and limits. On the response side, retain HTTP status, every Multi-Status row, property-level statuses, hrefs, resource identifiers, scores, the arbiter's 507 truncation row and server timestamp or index epoch where available.

Do not transform the rows into “all resources” unless a separate mechanism proves complete enumeration. Do not label an absent item FALSE unless the server exposed the predicate evaluation and no truncation, access or scope ambiguity remains. Do not compare scores across engines or collections. Do not treat grammar discovery as a successful query receipt.

Operational alerts should catch 207 responses whose 507 child was dropped, changing schema for the same principal and scope, a growing gap between SEARCH and a separately authorized PROPFIND enumeration, new redirect boundaries, result counts that hit a stable ceiling, and duplicate resource identifiers behind different hrefs. Expensive queries and XML external entities need resource and parser controls because search is also an execution surface.

RFC 5323 does not make server-side search weak. It makes the boundaries explicit enough to use it responsibly. A returned row is meaningful. A sorted row is useful. A missing row is simply less authoritative than most dashboards admit.

Sources