Zusammenfassung

  • Eine 207-Antwort belegt die vom Server unter Grammatik, Arbiter, Bereich und Principal zurückgegebenen Zeilen. Sie belegt nicht, dass jede Ressource geprüft wurde.
  • Bei Kürzung darf die Teilmenge beliebig sein. Sortierung ordnet diese Teilmenge, macht sie aber nicht automatisch zur globalen Spitze des vollständigen Ergebnisses.

Die Ordnung verleiht falsche Sicherheit

Hundert sauber sortierte Treffer sehen nach einem abgeschlossenen Vorgang aus. RFC 5323 definiert einen Fall, in dem genau diese Ansicht täuscht. Ein Server darf die Zahl der ausgewerteten oder übertragenen Ressourcen begrenzen, um Rechenaufwand zu kontrollieren.

Die Antwort bleibt 207 Multi-Status. Für den Such-Arbiter erscheint 507, und nach Möglichkeit kommen Teilergebnisse mit. Viele passende Ressourcen können ungeprüft geblieben sein. Die sichtbaren Zeilen dürfen jede Teilmenge der theoretisch passenden Menge darstellen.

War DAV:orderby verlangt, muss die Teilmenge entsprechend sortiert sein. Sortiert heißt nicht global erstplatziert. Entfernt ein Gateway den 507-Eintrag und bewahrt nur Ressourcenzeilen, wird eine begrenzte Rechnung zum erfundenen Inventar.

Mit DAV:limit bittet der Client um eine maximale Zahl oder einen Arbeitsrahmen. Der Server darf die Bitte ignorieren. Bei Ordnung plus Grenze sollte er hoch geordnete Elemente wählen. Bitte, tatsächliche Grenze und Kürzung sind dennoch getrennte Tatsachen.

Arbiter und Suchraum sind verschiedene Ressourcen

SEARCH transportiert Anfrage und Ergebnis; die Grammatik bestimmt die Semantik. Die Request-URI benennt den Arbiter, der die Suche annimmt. RFC 5323 setzt ihn nicht mit dem Suchbereich gleich.

DAV:from nennt Bereiche mit href und depth. Null umfasst die Sammlung, eins ihre direkten Kinder, infinity alle Nachkommen. Relative Verweise werden gegen die Request-URI aufgelöst, absolute können andere Orte bezeichnen, soweit der Server sie zulässt.

Mehrere Bereiche sind optional. Fehlt Unterstützung, muss die Anfrage scheitern. Auch Redirect-Referenzen werden nicht von selbst verfolgt. Eine unendliche Tiefe ist kein Beleg, dass jeder logische Zweig besucht wurde.

Ein Audit mit Predicate, aber ohne aufgelösten Bereich und Arbiter kann die Frage nicht wiederholen. Wer Request-URI als Scope speichert, fragt später möglicherweise eine andere Population ab.

UNKNOWN entfernt, ohne zu widerlegen

DAV:where verwendet TRUE, FALSE und UNKNOWN. Nur TRUE nimmt die Ressource auf. Eine fehlende Zeile kann deshalb UNKNOWN statt FALSE bedeuten.

Eine Eigenschaft ist NULL, wenn PROPFIND dafür non-2xx liefern würde. NULL unterscheidet sich von einer leeren Zeichenkette, die ein definierter Wert ist. Unlesbare Eigenschaften werden behandelt, als existierten sie nicht; unlesbarer Inhalt so, als scheitere GET.

SEARCH darf keine Information offenlegen, die GET oder PROPFIND verweigern. Daher können zwei Principals mit gleichem XML unterschiedliche Ergebnisse erhalten. Die Antwort ist sichtbarkeitsrelativ.

Fehlen kann aus Prädikat, UNKNOWN, Rechten, Scope, Kürzung, Redirect, Indexverzug oder Änderung entstehen. „Ressource existiert nicht“ ist keine unmittelbare Protokollaussage.

Fähigkeiten sind noch keine Ausführung

DASL und DAV:supported-query-grammar-set zeigen verstandene Grammatiken. Sie reichen nicht, jede gültige Anfrage zu erzeugen, und beweisen keine Ausführung. Query Schema Discovery kann suchbare, auswählbare und sortierbare Eigenschaften sowie optionale Operatoren beschreiben.

QSD ist optional. Sein Schema hängt von Arbiter und Bereich ab und kann sich mit dem Principal ändern, ohne alle Ursachen offenzulegen. Searchable heißt Bereitschaft zur Prüfung, nicht Eigenschaft auf jeder Ressource.

Eine Grammatik-URI ist ein Bezeichner und sollte nicht allein wegen HTTP-Form abgerufen werden. Scores sind ebenso kontextgebunden. Zahlen verschiedener Abfragen sind meist nur vergleichbar, wenn dasselbe System dieselbe Sammlung verarbeitet hat.

Unterstützung, Lauf und Ergebnis benötigen eigene Belege. OPTIONS ist kein Indexprüfbericht, Schema keine Aktualitätsgarantie und Score keine objektive Bedeutung.

Eine href-Zeile ist nicht zwingend ein Objekt

Mehrere URI im Bereich können dieselbe Ressource abbilden. Der Server sollte nur eine melden. DAV:resource-id hilft bei möglichen Dubletten, macht die gewählte href aber nicht dauerhaft exklusiv.

Zeilen zählen daher nicht immer Objekte. Behalten werden href, Ressourcen-ID, Propstats, Arbiter und Zeitpunkt. Deduplizierung bleibt eine begründete Folgeentscheidung.

Erfolgreiche Ergebnisse sollten nicht gecacht werden. Sammlung, Rechte, Eigenschaften und Index ändern sich. SEARCH ist eine datierte Beobachtung und kein eingefrorener Snapshot.

Nachweis einer belastbaren Suche

Bewahren Sie XML, Grammatik, Request-URI, aufgelöste Bereiche, Tiefen, Redirect- und Versionsoptionen, Principal, Rechte, Auswahl, Bedingungsbaum, Ordnung und Limit. Zur Antwort gehören 207, alle Response- und Propstat-Elemente, href, resource-id, Scores, 507 und wenn möglich Index-Epoche.

Bezeichnen Sie ohne separate Enumeration nichts als vollständig. Machen Sie aus Fehlen kein FALSE, solange UNKNOWN, Rechte, Scope oder Kürzung offen sind. Vergleichen Sie Scores nicht über Systeme. Zählen Sie Grammar Discovery nicht als Suche.

Überwachen Sie feste Obergrenzen, verlorene 507, Schemawechsel, Abweichungen von autorisiertem PROPFIND, gleiche IDs hinter mehreren href und externe XML-Entitäten. Teure Queries sind auch DoS-Fläche; Parser und Budget bestimmen die Reichweite der Antwort.

RFC 5323 macht die Suche brauchbar, weil es ihre Unsicherheit ausdrücken kann. Wer diese Signale speichert, erhält starke lokale Beobachtung. Wer sie entfernt, baut aus sortierten Zeilen eine Autorität, die der Server nie beanspruchte.

Quellen