5. Collections of Web Resources (Sammlungen von Web-Ressourcen)

Dieser Abschnitt bietet eine Beschreibung eines Typs von Web-Ressource, der Sammlung, und erörtert ihre Interaktionen mit dem HTTP-URL-Namespace und mit HTTP-Methoden. Der Zweck einer Sammlungsressource besteht darin, sammlungsähnliche Objekte (z. B. Dateisystemverzeichnisse) innerhalb des Namespace eines Servers zu modellieren.

Alle DAV-konformen Ressourcen MÜSSEN das hier spezifizierte HTTP-URL-Namespace-Modell unterstützen.

5.1 HTTP URL Namespace Model (HTTP-URL-Namespace-Modell)

Der HTTP-URL-Namespace ist ein hierarchischer Namespace, bei dem die Hierarchie durch das Zeichen "/" begrenzt wird.

Ein HTTP-URL-Namespace wird als konsistent bezeichnet, wenn er die folgenden Bedingungen erfüllt: Für jede URL in der HTTP-Hierarchie existiert eine Sammlung, die diese URL als interne Mitglieds-URL enthält. Die Wurzel oder Top-Level-Sammlung des betrachteten Namespace ist von der vorherigen Regel ausgenommen. Die Top-Level-Sammlung des betrachteten Namespace ist nicht notwendigerweise die durch den absoluten Pfad '/' identifizierte Sammlung -- sie kann durch ein oder mehrere Pfadsegmente identifiziert werden (z. B. /servlets/webdav/...)

Weder HTTP/1.1 noch WebDAV erfordern, dass der gesamte HTTP-URL-Namespace konsistent ist -- eine WebDAV-kompatible Ressource hat möglicherweise keine übergeordnete Sammlung. Bestimmte WebDAV-Methoden dürfen jedoch keine Ergebnisse produzieren, die Namespace-Inkonsistenzen verursachen.

Wie in [RFC2616] und [RFC3986] impliziert, KANN jede Ressource, einschließlich Sammlungsressourcen, durch mehr als einen URI identifiziert werden. Beispielsweise könnte eine Ressource durch mehrere HTTP-URLs identifiziert werden.

5.2 Collection Resources (Sammlungsressourcen)

Sammlungsressourcen unterscheiden sich von anderen Ressourcen dadurch, dass sie auch als Container fungieren. Einige HTTP-Methoden gelten nur für eine Sammlung, aber einige gelten für einige oder alle Ressourcen innerhalb des durch die Sammlung definierten Containers. Wenn der Umfang einer Methode nicht klar ist, kann der Client angeben, welche Tiefe anzuwenden ist. Die Tiefe kann entweder null Ebenen (nur die Sammlung), eine Ebene (die Sammlung und direkt enthaltene Ressourcen) oder unendliche Ebenen (die Sammlung und alle rekursiv enthaltenen Ressourcen) sein.

Der Zustand einer Sammlung besteht mindestens aus einer Menge von Zuordnungen zwischen Pfadsegmenten und Ressourcen sowie einer Menge von Eigenschaften der Sammlung selbst. In diesem Dokument wird gesagt, dass eine Ressource B in der Sammlungsressource A enthalten ist, wenn es eine Pfadsegmentzuordnung gibt, die auf B abbildet und die in A enthalten ist. Eine Sammlung MUSS höchstens eine Zuordnung für ein gegebenes Pfadsegment enthalten, d. h., es ist illegal, dasselbe Pfadsegment auf mehr als eine Ressource abzubilden.

Auf Sammlungen definierte Eigenschaften verhalten sich genau wie Eigenschaften auf Nicht-Sammlungsressourcen. Eine Sammlung KANN zusätzlichen Zustand haben, wie z. B. von GET zurückgegebene Entity-Bodies.

Für alle WebDAV-konformen Ressourcen A und B, identifiziert durch die URLs "U" bzw. "V", sodass "V" gleich "U/SEGMENT" ist, MUSS A eine Sammlung sein, die eine Zuordnung von "SEGMENT" zu B enthält. Wenn also Ressource B mit URL http://example.com/bar/blah WebDAV-konform ist und Ressource A mit URL http://example.com/bar/ WebDAV-konform ist, dann muss Ressource A eine Sammlung sein und genau eine Zuordnung von "blah" zu B enthalten.

Obwohl eine Zuordnung üblicherweise aus einem einzelnen Segment und einer Ressource besteht, besteht eine Zuordnung im Allgemeinen aus einer Menge von Segmenten und einer Ressource. Dies ermöglicht es einem Server, eine Menge von Segmenten als äquivalent zu behandeln (d. h. entweder sind alle Segmente derselben Ressource zugeordnet, oder keines der Segmente ist einer Ressource zugeordnet). Beispielsweise behandelt ein Server, der eine Groß-/Kleinschreibungs-Faltung an Segmenten durchführt, die Segmente "ab", "Ab", "aB" und "AB" als äquivalent. Ein Client kann dann jedes dieser Segmente verwenden, um die Ressource zu identifizieren. Beachten Sie, dass ein PROPFIND-Ergebnis eines dieser äquivalenten Segmente auswählt, um die Zuordnung zu identifizieren, sodass es ein PROPFIND-Antwortelement pro Zuordnung gibt, nicht eines pro Segment in der Zuordnung.

Sammlungsressourcen KÖNNEN Zuordnungen zu nicht-WebDAV-konformen Ressourcen in der HTTP-URL-Namespace-Hierarchie haben, sind aber nicht dazu verpflichtet. Wenn beispielsweise Ressource X mit URL http://example.com/bar/blah nicht WebDAV-konform ist und Ressource A mit URL http://example.com/bar/ eine WebDAV-Sammlung identifiziert, dann kann A eine Zuordnung von "blah" zu X haben oder nicht.

Wenn eine WebDAV-konforme Ressource keine WebDAV-konformen internen Mitglieder in der HTTP-URL-Namespace-Hierarchie hat, dann ist die WebDAV-konforme Ressource nicht erforderlich, eine Sammlung zu sein.

Es gibt eine etablierte Konvention, dass, wenn auf eine Sammlung mit ihrem Namen ohne abschließenden Schrägstrich verwiesen wird, der Server die Anfrage so behandeln KANN, als ob der abschließende Schrägstrich vorhanden wäre. In diesem Fall SOLLTE er einen Content-Location-Header in der Antwort zurückgeben, der auf die URL zeigt, die mit "/" endet. Wenn beispielsweise ein Client eine Methode auf http://example.com/blah (ohne abschließenden Schrägstrich) aufruft, kann der Server antworten, als ob die Operation auf http://example.com/blah/ (mit abschließendem Schrägstrich) aufgerufen worden wäre, und sollte einen Content-Location-Header mit dem Wert http://example.com/blah/ zurückgeben. Wo immer ein Server eine URL erzeugt, die auf eine Sammlung verweist, SOLLTE der Server den abschließenden Schrägstrich einschließen. Im Allgemeinen SOLLTEN Clients die Form mit abschließendem Schrägstrich von Sammlungsnamen verwenden. Wenn Clients nicht die Form mit abschließendem Schrägstrich verwenden, muss der Client darauf vorbereitet sein, eine Weiterleitungsantwort zu sehen. Clients werden feststellen, dass die DAV:resourcetype-Eigenschaft zuverlässiger als die URL ist, um herauszufinden, ob eine Ressource eine Sammlung ist.

Clients MÜSSEN in der Lage sein, den Fall zu unterstützen, in dem WebDAV-Ressourcen in Nicht-WebDAV-Ressourcen enthalten sind. Wenn beispielsweise eine OPTIONS-Antwort von http://example.com/servlet/dav/collection WebDAV-Unterstützung anzeigt, kann der Client nicht davon ausgehen, dass http://example.com/servlet/dav/ oder sein Elternteil notwendigerweise WebDAV-Sammlungen sind.

Ein typisches Szenario, in dem zugeordnete URLs nicht als Mitglieder ihrer übergeordneten Sammlung erscheinen, ist der Fall, in dem ein Server Links oder Weiterleitungen zu Nicht-WebDAV-Ressourcen zulässt. Beispielsweise erscheint "/col/link" möglicherweise nicht als Mitglied von "/col/", obwohl der Server mit einem 302-Status auf eine GET-Anfrage an "/col/link" antworten würde; daher wäre die URL "/col/link" tatsächlich zugeordnet. Ebenso könnte eine dynamisch generierte Seite eine URL-Zuordnung von "/col/index.html" haben, sodass diese Ressource mit 200 OK auf eine GET-Anfrage antworten könnte, aber dennoch nicht als Mitglied von "/col/" erscheint.

Einige Zuordnungen zu sogar WebDAV-konformen Ressourcen erscheinen möglicherweise nicht in der übergeordneten Sammlung. Ein Beispiel für diesen Fall sind Server, die mehrere Alias-URLs für jede WebDAV-konforme Ressource unterstützen. Ein Server kann URLs implementieren, die nicht zwischen Groß- und Kleinschreibung unterscheiden, sodass "/col/a" und "/col/A" dieselbe Ressource identifizieren, aber beim Auflisten der Mitglieder von "/col" nur entweder "a" oder "A" gemeldet wird. In Fällen, in denen ein Server eine Menge von Segmenten als äquivalent behandelt, MUSS der Server in PROPFIND-Antworten nur ein bevorzugtes Segment pro Zuordnung, konsistent gewählt, offenlegen.