5. Collections of Web Resources (Collections de ressources Web)

Cette section fournit une description d'un type de ressource Web, la collection, et discute de ses interactions avec l'espace de noms d'URL HTTP et avec les méthodes HTTP. Le but d'une ressource de collection est de modéliser des objets de type collection (par exemple, des répertoires de système de fichiers) dans l'espace de noms d'un serveur.

Toutes les ressources conformes à DAV DOIVENT prendre en charge le modèle d'espace de noms d'URL HTTP spécifié ici.

5.1 HTTP URL Namespace Model (Modèle d'espace de noms d'URL HTTP)

L'espace de noms d'URL HTTP est un espace de noms hiérarchique où la hiérarchie est délimitée par le caractère "/".

Un espace de noms d'URL HTTP est dit cohérent s'il remplit les conditions suivantes: pour chaque URL dans la hiérarchie HTTP, il existe une collection qui contient cette URL en tant qu'URL de membre interne. La racine, ou collection de niveau supérieur de l'espace de noms considéré, est exemptée de la règle précédente. La collection de niveau supérieur de l'espace de noms considéré n'est pas nécessairement la collection identifiée par le chemin absolu '/' -- elle peut être identifiée par un ou plusieurs segments de chemin (par exemple, /servlets/webdav/...)

Ni HTTP/1.1 ni WebDAV n'exigent que l'ensemble de l'espace de noms d'URL HTTP soit cohérent -- une ressource compatible WebDAV peut ne pas avoir de collection parente. Cependant, certaines méthodes WebDAV sont interdites de produire des résultats qui causent des incohérences d'espace de noms.

Comme cela est implicite dans [RFC2616] et [RFC3986], toute ressource, y compris les ressources de collection, PEUT être identifiée par plus d'un URI. Par exemple, une ressource pourrait être identifiée par plusieurs URL HTTP.

5.2 Collection Resources (Ressources de collection)

Les ressources de collection diffèrent des autres ressources en ce qu'elles agissent également comme des conteneurs. Certaines méthodes HTTP s'appliquent uniquement à une collection, mais certaines s'appliquent à certaines ou à toutes les ressources à l'intérieur du conteneur défini par la collection. Lorsque la portée d'une méthode n'est pas claire, le client peut spécifier quelle profondeur appliquer. La profondeur peut être soit zéro niveau (uniquement la collection), un niveau (la collection et les ressources directement contenues), ou des niveaux infinis (la collection et toutes les ressources contenues récursivement).

L'état d'une collection consiste au moins en un ensemble de mappages entre des segments de chemin et des ressources, et un ensemble de propriétés sur la collection elle-même. Dans ce document, une ressource B sera dite être contenue dans la ressource de collection A s'il existe un mappage de segment de chemin qui mappe à B et qui est contenu dans A. Une collection DOIT contenir au plus un mappage pour un segment de chemin donné, c'est-à-dire qu'il est illégal d'avoir le même segment de chemin mappé à plus d'une ressource.

Les propriétés définies sur les collections se comportent exactement comme les propriétés sur les ressources non-collection. Une collection PEUT avoir un état supplémentaire tel que des corps d'entité retournés par GET.

Pour toutes les ressources conformes à WebDAV A et B, identifiées par les URL "U" et "V", respectivement, telles que "V" est égale à "U/SEGMENT", A DOIT être une collection qui contient un mappage de "SEGMENT" à B. Donc, si la ressource B avec l'URL http://example.com/bar/blah est conforme à WebDAV et si la ressource A avec l'URL http://example.com/bar/ est conforme à WebDAV, alors la ressource A doit être une collection et doit contenir exactement un mappage de "blah" à B.

Bien que généralement un mappage consiste en un seul segment et une ressource, en général, un mappage consiste en un ensemble de segments et une ressource. Cela permet à un serveur de traiter un ensemble de segments comme équivalents (c'est-à-dire, soit tous les segments sont mappés à la même ressource, soit aucun des segments n'est mappé à une ressource). Par exemple, un serveur qui effectue un pliage de casse sur les segments traitera les segments "ab", "Ab", "aB" et "AB" comme équivalents. Un client peut alors utiliser n'importe lequel de ces segments pour identifier la ressource. Notez qu'un résultat PROPFIND sélectionnera l'un de ces segments équivalents pour identifier le mappage, il y aura donc un élément de réponse PROPFIND par mappage, et non un par segment dans le mappage.

Les ressources de collection PEUVENT avoir des mappages vers des ressources non conformes à WebDAV dans la hiérarchie d'espace de noms d'URL HTTP, mais ne sont pas obligées de le faire. Par exemple, si la ressource X avec l'URL http://example.com/bar/blah n'est pas conforme à WebDAV et que la ressource A avec l'URL http://example.com/bar/ identifie une collection WebDAV, alors A peut ou non avoir un mappage de "blah" à X.

Si une ressource conforme à WebDAV n'a pas de membres internes conformes à WebDAV dans la hiérarchie d'espace de noms d'URL HTTP, alors la ressource conforme à WebDAV n'est pas tenue d'être une collection.

Il existe une convention établie selon laquelle lorsqu'une collection est référencée par son nom sans barre oblique finale, le serveur PEUT traiter la demande comme si la barre oblique finale était présente. Dans ce cas, il DEVRAIT retourner un en-tête Content-Location dans la réponse, pointant vers l'URL se terminant par "/". Par exemple, si un client invoque une méthode sur http://example.com/blah (sans barre oblique finale), le serveur peut répondre comme si l'opération était invoquée sur http://example.com/blah/ (barre oblique finale), et devrait retourner un en-tête Content-Location avec la valeur http://example.com/blah/. Partout où un serveur produit une URL faisant référence à une collection, le serveur DEVRAIT inclure la barre oblique finale. En général, les clients DEVRAIENT utiliser la forme avec barre oblique finale des noms de collection. Si les clients n'utilisent pas la forme avec barre oblique finale, le client doit être prêt à voir une réponse de redirection. Les clients trouveront la propriété DAV:resourcetype plus fiable que l'URL pour déterminer si une ressource est une collection.

Les clients DOIVENT être capables de prendre en charge le cas où les ressources WebDAV sont contenues à l'intérieur de ressources non-WebDAV. Par exemple, si une réponse OPTIONS de http://example.com/servlet/dav/collection indique un support WebDAV, le client ne peut pas supposer que http://example.com/servlet/dav/ ou son parent sont nécessairement des collections WebDAV.

Un scénario typique dans lequel les URL mappées n'apparaissent pas comme membres de leur collection parente est le cas où un serveur permet des liens ou des redirections vers des ressources non-WebDAV. Par exemple, "/col/link" pourrait ne pas apparaître comme membre de "/col/", bien que le serveur répondrait avec un statut 302 à une demande GET vers "/col/link"; ainsi, l'URL "/col/link" serait effectivement mappée. De même, une page générée dynamiquement pourrait avoir un mappage d'URL de "/col/index.html", ainsi cette ressource pourrait répondre avec un 200 OK à une demande GET mais ne pas apparaître comme membre de "/col/".

Certains mappages vers même des ressources conformes à WebDAV pourraient ne pas apparaître dans la collection parente. Un exemple pour ce cas sont les serveurs qui prennent en charge plusieurs URL d'alias pour chaque ressource conforme à WebDAV. Un serveur peut implémenter des URL insensibles à la casse, ainsi "/col/a" et "/col/A" identifient la même ressource, mais seul "a" ou "A" est rapporté lors de la liste des membres de "/col". Dans les cas où un serveur traite un ensemble de segments comme équivalents, le serveur DOIT exposer un seul segment préféré par mappage, choisi de manière cohérente, dans les réponses PROPFIND.