Zusammenfassung

  • WebDAV-Bindings lassen mehrere URIs auf dieselbe Ressource zeigen. Bei einer Sammlung macht ein zweites Binding dieselben Mitglieder unter einem weiteren Pfad erreichbar und kann einen Zyklus erzeugen.
  • Bei einem bind-fähigen PROPFIND mit Depth: infinity wird ein Vorkommen mit 200 samt Nachfahren ausgegeben. Weitere Pfade bleiben als Antworten mit 208 Already Reported erhalten, aber ihr Teilbaum wird nicht wiederholt.
  • DAV:resource-id liefert die stabile Objektidentität unter den Pfaden. Der Client bewahrt jede Binding-Kante und expandiert eine Sammlung einmal; versteht er 208 nicht, beendet 508 die Schleife, statt eine unerklärlich verkürzte Struktur als Erfolg auszugeben.

Zwei Verzeichniseinträge führten zu demselben Bestand

Ein Archiv kann dieselbe Sammlung von zwei Gängen aus zugänglich machen. Beide Türen sind wirkliche Bestandteile des Gebäudes. Die Schränke dahinter existieren dennoch nur einmal.

Ein Walker, der Pfade für Objekte hält, zählt jeden Schrank zweimal. Führt ein Gang zu einem Vorfahren zurück, erzeugt er aus einem endlichen Gebäude unendlich viele Namen. Ein Walker, der beim Erkennen des Raums sofort den zweiten Eingang löscht, beendet zwar die Arbeit, verfälscht aber den Grundriss.

208 trennte die Kante vom Arbeitsaufwand. Der zweite Eingang wird berichtet und mit der bereits besuchten Sammlung verbunden. Nur der erneute Abstieg fällt aus.

Die Topologie bleibt vollständig, während die Ausgabe endlich wird.

WebDAV hatte die Einzelurteile bereits in 207 gelegt

RFC 4918 beschreibt 2007 den Zustand einer WebDAV-Sammlung als Zuordnungen zwischen Pfadsegmenten und Ressourcen sowie Eigenschaften der Sammlung. Ein Mitgliedsname ist daher eine Zugangskante, nicht das Zielobjekt.

PROPFIND arbeitet mit Tiefe null, eins oder unendlich. Eine unendliche Anfrage umfasst alle Nachfahren. Der Server antwortet mit 207 Multi-Status und einer flachen Liste von DAV:response-Elementen. href nennt den Pfad, während propstat die Ergebnisse der angeforderten Eigenschaften trägt.

Der äußere Status war nie das Gesamturteil. Der Empfänger musste den Körper lesen. Dieses Modell bot später den richtigen Platz für 208: Es beschreibt ein einzelnes Vorkommen innerhalb der Bestandsaufnahme, nicht die gesamte HTTP-Anfrage.

Mehrere URIs für eine Ressource waren schon möglich. Der Binding-Zusatz gab Clients die Methode, einen neuen Pfad zu einer vorhandenen Ressource bewusst anzulegen.

BIND erzeugte eine Beziehung und keine Kopie

Der als Experimental veröffentlichte RFC 5842 definierte im April 2010 BIND, UNBIND und REBIND. BIND verbindet ein Segment in einer Sammlung mit einer bestehenden Ressource. Die daraus entstehende URI kann dieselbe Ressource adressieren.

Neu ist das Binding, nicht die Ressource. Zwei übergeordnete Sammlungen können je eine eigenständige Beziehung zum gleichen Ziel enthalten.

Binding-Integrität verlangt, dass die Beziehung bestehen bleibt und dieselbe Identität bezeichnet, bis eine ausdrücklich definierte Operation sie entfernt oder verändert. Das Löschen einer Kante darf eine andere nicht brechen und keine Ressourcenfreigabe auslösen, solange noch ein Binding existiert.

Ein Alias ist weder Eigentümer noch bedeutungsloses Etikett. Er ist ein gesondertes Stück Namensraumzustand.

Ein Sammlungs-Binding vervielfachte Pfade unterhalb

Ein Binding auf eine Blattressource fügt eine URI hinzu. Zeigt es auf eine Sammlung, werden auch deren Nachfahren unter dem neuen Präfix erreichbar, obwohl die internen Bindings nicht kopiert werden.

Damit können mehr URI-Zuordnungen als Ressourcen entstehen. Bindet sich eine Sammlung an sich selbst oder einen Vorfahren, lassen sich dieselben Segmente beliebig oft aneinanderreihen.

RFC 5842 verlangt bei Depth: infinity die Erkennung solcher Collection-Bind-Schleifen. Der Server darf schon deren Erzeugung ablehnen, denn Schleifenunterstützung ist optional. Wer sie zulässt, muss die Struktur als Graph behandeln.

Nicht der Speicher enthält unendlich viele Objekte. Der pfadbasierte Algorithmus produziert unendlich viele scheinbare Vorkommen.

Eine dauerhafte ID blieb unter beweglichen Adressen

Unterschiedliche URI beweisen keine unterschiedlichen Ressourcen. Gleicher Inhalt beweist umgekehrt keine gemeinsame Identität; zwei Objekte können heute gleich sein und morgen auseinanderlaufen.

RFC 5842 macht DAV:resource-id verpflichtend. Die Kennung entsteht mit der Ressource, ist für alle Zeit unter allen Ressourcen eindeutig, bleibt bei Updates und REBIND unverändert und darf selbst nach dem Verlust sämtlicher URI-Zuordnungen nicht neu vergeben werden.

Identische Werte über zwei Bindings belegen, dass beide Pfade dasselbe Objekt erreichen. Die Kennung wählt keine bevorzugte Adresse. Sie bleibt, während Adressen hinzukommen oder verschwinden.

Ein Client kann sie in PROPFIND anfordern und so die Binding-Struktur rekonstruieren. Das Auslassen eines Teilbaums wird dadurch nachprüfbar.

Ein treuer Walker führte zwei Besuchslisten

Die erste Liste erfasst jede Kante mit Elternsammlung, Segment und href. Die zweite erfasst, welche Sammlungsidentitäten in dieser Antwort bereits expandiert wurden.

Eine reine Pfadliste bewahrt den Namensraum, wiederholt aber Arbeit und folgt Zyklen. Eine reine Objektliste stoppt Zyklen, kann jedoch eine legitime Kante löschen, bevor sie festgehalten wurde.

Der Client muss deshalb zuerst das Binding speichern und danach entscheiden, ob die Zielidentität noch einen Abstieg benötigt. Die Deduplizierung betrifft Expansion, nicht Beziehung.

208 verbindet beide Listen: Dieser Pfad existiert; seine Sammlung hat ihre Nachfahren bereits über ein anderes Vorkommen geliefert.

Die spätere Kante verschwand nicht

208 ist für Depth: infinity und den Einsatz innerhalb eines DAV:propstat definiert. Bei mehreren Bindings zur selben Sammlung erhält ein Vorkommen 200. Spätere DAV:response-Elemente tragen 208 und enthalten keine erneuten Antworten für die Nachfahren.

Das spätere href bleibt erhalten. Über DAV:resource-id kann es mit dem früheren 200-Vorkommen verbunden werden.

Im RFC-Beispiel besitzen /Coll/ und /Coll/Bar dieselbe ID. Der erste Pfad liefert Mitglieder mit 200; der zweite erhält 208. Eine Folge wie /Coll/Bar/Bar wird nicht weiter aufgebaut, weil sie zum selben Knoten zurückführt.

„Already Reported“ bezeichnet die Expansionsgeschichte dieses Multi-Status. Es entwertet den Alias nicht.

Das 200-Vorkommen wurde nicht zum kanonischen Herrscher

Für eine endliche Antwort muss der Server ein Vorkommen als Träger des Teilbaums wählen. Daraus folgt weder Originalität noch dauerhaftes Eigentum.

Jedes Binding bleibt Zustand seiner Elternsammlung und kann einen eigenen Navigations-, Berechtigungs- oder Auditkontext besitzen. Wer 208-Pfade als Duplikate löscht, entfernt diese Kontexte.

UNBIND kann dann fälschlich wie Ressourcenlöschung wirken. Oder die Sammlung des zuerst expandierten Pfads erhält vermeintlich Kontrolle über Kanten anderer Eltern.

Die Reihenfolge einer Bestandsaufnahme darf nicht zur Verfassung des Namensraums werden.

Außen blieb 207, innen stand 208

Auf Anfrageebene steht gewöhnlich 207 Multi-Status. 208 erscheint im Körper beim Eigenschaftsergebnis eines Pfades.

Es bedeutet daher nicht, der Client habe die HTTP-Anfrage wiederholt oder die gesamte Antwort sei schon früher gesendet worden. Nur die Nachfahren dieser Sammlung wurden in demselben Bericht durch ein anderes Binding aufgezählt.

href bewahrt Pfadidentität, resource-id verbindet Pfade mit dem Objekt, 200 und 208 verteilen die Expansionsarbeit.

Ein Vermittler, der daraus nur success=true macht, transportiert den Umschlag und vernichtet die Graphbeweise darin.

Weglassen verlangte ausgehandelte Fähigkeit

Ein fehlender Teilbaum kann bereits berichtet oder verloren sein. Ohne 208-Kenntnis sieht beides gleich aus.

Ein Binding-Server kündigt die Compliance-Klasse bind im DAV-Header einer OPTIONS-Antwort an. Der Client sollte DAV: bind senden und muss dann insbesondere 208 verstehen.

Zur Rückwärtskompatibilität sollte 208 nicht ohne dieses Signal in Multi-Status verwendet werden. Ältere Clients könnten den unbekannten Status als Fehler oder die Sammlung als kinderlos interpretieren.

Die Einsparung ist deshalb keine einseitige Kompression. Sie ist ein gemeinsamer Vertrag darüber, welche Daten wo bereits stehen und durch welche Identität sie verbunden sind.

508 stoppte, was 208 fortsetzen konnte

Gerät ein nicht bind-fähiger Client bei tiefer PROPFIND-Abfrage in eine Schleife, sieht RFC 5842 508 Loop Detected vor. Vor Beginn des Streamings kann 508 außen stehen; bei laufendem Multi-Status kann der Fehler im Bericht erscheinen.

Mit 208 führt der vorbereitete Client die endliche Traversierung fort: Alias behalten, Teilbaum nicht wiederholen. Mit 508 beendet der Server die Operation wegen einer Endlosschleife, und die Operation schlägt fehl.

Das sind keine milde und strenge Variante. Die eine übermittelt eine verstandene Referenz; die andere zieht eine Grenze, weil diese Referenz nicht sicher verstanden würde.

Explizites Scheitern ist ehrlicher als ein scheinbar vollständiger Baum mit unerklärten Lücken.

Mehr Kanten schufen mehr Angriffsfläche

BIND erleichtert versehentliche und böswillige Schleifen. Die verpflichtende Erkennung bei tiefer Verarbeitung löst jedoch nicht jede Ressourcenfrage.

RFC 5842 nennt Datenschutz- und Denial-of-Service-Risiken. Serverübergreifende Bindings können Last zu einem ungeeigneten Ziel lenken. Das optionale DAV:parent-set kann private Orte offenlegen und Wartungskosten erzeugen, die andere Verwaltungsdomänen beeinflussen.

208 begrenzt Wiederholung in einer Antwort. Es legt kein CPU-, Speicher-, Knoten- oder Antwortbudget fest und verteilt keine Berechtigung zur Kantenerzeugung.

Die gemeinsame Schicht bleibt schmal: Sie behebt eine nachweisbare Verstärkung, ohne umfassende Sicherheit vorzutäuschen.

Gemeinsame Ressource hieß nicht gleiche Beobachtung

Eine gemeinsame resource-id beweist Objektidentität, nicht identische Werte jeder Eigenschaft auf jedem Pfad. Dead Properties sind unabhängig von Bindings und Pfad; Live Properties folgen ihrer Definition und können Pfadkontext besitzen.

Alles per ID zusammenzuführen löscht Kontext. Jede Abweichung als neues Objekt zu behandeln löscht Identität.

Ressourcenfakten, Binding-Fakten und pfadbezogene Beobachtungen gehören in getrennte Ebenen. 208 benutzt gemeinsame Identität nur für die Expansionsentscheidung.

Ein Beweis bleibt nützlich, wenn seine Autorität nicht weiter reicht als seine Aussage.

IANA registrierte den engen Sinn

Das IANA-Register der HTTP-Statuscodes verweist für 208 Already Reported auf RFC 5842. Dasselbe Experimental-Dokument definiert 508; 207 verweist auf RFC 4918.

Die Registrierung macht die Erweiterung nicht zum Internet Standard, belegt keine heutige Verbreitung und schafft keinen allgemeinen Code für Datenbankduplikate, Idempotenz oder Caches.

208 gehört in einen bind-fähigen WebDAV-Depth-infinity-Multi-Status. Sein enger Kontext verhindert, dass „bereits“ als pauschale Löschgenehmigung missverstanden wird.

Jede Kante, nur eine Expansion

HTTP 208 zwang den Graphen nicht zurück in einen Baum. Es erhielt Pfade, stabilisierte Identität und begrenzte Arbeit.

Jedes Binding wird berichtet, weil Zugang realer Zustand ist. Jede Ressource behält eine ID, weil sie keiner einzelnen URI gehört. Nachfahren werden einmal expandiert, weil Wiederholung keine Struktur hinzufügt. Die Auslassung trägt einen Status, weil unerklärte Stille wie Datenverlust aussieht.

Kein Pfad wird souverän, kein Alias zur Kopie und kein Zyklus zu unendlich vielen Ressourcen.

Der zweite Eingang bleibt im Plan. Den Raum dahinter muss niemand ein zweites Mal zählen.