8. General Request and Response Handling (Traitement général des requêtes et des réponses)

8.1 Precedence in Error Handling (Priorité dans le traitement des erreurs)

Les serveurs DOIVENT retourner les erreurs d'autorisation de préférence aux autres erreurs. Cela évite de divulguer des informations sur les ressources protégées (par exemple, un client qui découvre qu'une ressource cachée existe en voyant une réponse 423 Locked à une requête anonyme vers la ressource).

8.2 Use of XML (Utilisation de XML)

Dans HTTP/1.1, les informations de paramètres de méthode étaient exclusivement encodées dans les en-têtes HTTP. Contrairement à HTTP/1.1, WebDAV encode les informations de paramètres de méthode soit dans un corps d'entité de requête XML ([REC-XML]), soit dans un en-tête HTTP. L'utilisation de XML pour encoder les paramètres de méthode a été motivée par la capacité d'ajouter des éléments XML supplémentaires aux structures existantes, offrant une extensibilité; et par la capacité de XML d'encoder des informations dans des jeux de caractères ISO 10646, offrant un support d'internationalisation.

En plus d'encoder les paramètres de méthode, XML est utilisé dans WebDAV pour encoder les réponses des méthodes, offrant les avantages d'extensibilité et d'internationalisation de XML pour la sortie de méthode, ainsi que l'entrée.

Lorsque XML est utilisé pour un corps de requête ou de réponse, le type Content-Type DEVRAIT être application/xml. Les implémentations DOIVENT accepter à la fois text/xml et application/xml dans les corps de requête et de réponse. L'utilisation de text/xml est déconseillée.

Tous les clients et ressources conformes à DAV DOIVENT utiliser des analyseurs XML conformes à [REC-XML] et [REC-XML-NAMES]. Tout XML utilisé dans les requêtes ou les réponses DOIT être, au minimum, bien formé et utiliser correctement les espaces de noms. Si un serveur reçoit du XML qui n'est pas bien formé, alors le serveur DOIT rejeter l'ensemble de la requête avec un 400 (Bad Request). Si un client reçoit du XML qui n'est pas bien formé dans une réponse, alors le client NE DOIT PAS supposer quoi que ce soit sur le résultat de la méthode exécutée et DEVRAIT traiter le serveur comme dysfonctionnel.

Notez que le traitement de XML soumis par une source non fiable peut causer des risques liés à la confidentialité, à la sécurité et à la qualité du service (voir Section 20). Les serveurs PEUVENT rejeter les requêtes douteuses (même si elles consistent en XML bien formé), par exemple, avec un code de statut 400 (Bad Request) et un corps de réponse optionnel expliquant le problème.

8.3 URL Handling (Traitement des URL)

Les URL apparaissent à de nombreux endroits dans les requêtes et les réponses. L'expérience d'interopérabilité avec [RFC2518] a montré que de nombreux clients analysant les réponses Multi-Status n'ont pas complètement implémenté la résolution de référence complète définie dans la Section 5 de [RFC3986]. Ainsi, les serveurs en particulier doivent être prudents dans le traitement des URL dans les réponses, pour s'assurer que les clients ont suffisamment de contexte pour pouvoir interpréter toutes les URL. Les règles de cette section s'appliquent non seulement aux URL de ressource dans l'élément 'href' dans les réponses Multi-Status, mais aussi aux URL de ressource des en-têtes Destination et If.

L'expéditeur a le choix entre deux approches: utiliser une référence relative, qui est résolue par rapport au Request-URI, ou un URI complet. Un serveur DOIT s'assurer que chaque valeur 'href' dans une réponse Multi-Status utilise le même format.

WebDAV n'utilise qu'une forme de référence relative dans ses extensions, le chemin absolu.

Simple-ref = absolute-URI | ( path-absolute [ "?" query ] )

Les productions absolute-URI, path-absolute et query sont définies dans les Sections 4.3, 3.3 et 3.4 de [RFC3986].

Dans les productions Simple-ref, les expéditeurs NE DOIVENT PAS:

utiliser des segments de points ("." ou ".."), ou
avoir des préfixes qui ne correspondent pas au Request-URI (en utilisant les règles de comparaison définies dans la Section 3.2.3 de [RFC2616]).

Les identifiants de collections DEVRAIENT se terminer par un caractère '/'.

8.3.1 Exemple - Traitement correct des URL

Considérons la collection http://example.com/sample/ avec l'URL de membre interne http://example.com/sample/a%20test et la requête PROPFIND ci-dessous:

Requête:

PROPFIND /sample/ HTTP/1.1
Host: example.com
Depth: 1

Dans ce cas, le serveur devrait retourner deux éléments 'href' contenant soit

http://example.com/sample/ et http://example.com/sample/a%20test, ou
/sample/ et /sample/a%20test

Notez que même si le serveur peut stocker la ressource membre en interne comme 'a test', elle doit être encodée en pourcentage lorsqu'elle est utilisée dans une référence URI (voir Section 2.1 de [RFC3986]). Notez également qu'un URI légal peut toujours contenir des caractères qui doivent être échappés dans les données de caractères XML, tels que le caractère esperluette.

8.4 Required Bodies in Requests (Corps requis dans les requêtes)

Certaines de ces nouvelles méthodes ne définissent pas de corps. Les serveurs DOIVENT examiner toutes les requêtes pour un corps, même lorsqu'un corps n'était pas attendu. Dans les cas où un corps de requête est présent mais serait ignoré par un serveur, le serveur DOIT rejeter la requête avec 415 (Unsupported Media Type). Cela informe le client (qui tentait peut-être d'utiliser une extension) que le corps n'a pas pu être traité comme le client l'avait prévu.

8.5 HTTP Headers for Use in WebDAV (En-têtes HTTP à utiliser dans WebDAV)

HTTP définit de nombreux en-têtes qui peuvent être utilisés dans les requêtes et réponses WebDAV. Tous ne sont pas appropriés dans toutes les situations et certaines interactions peuvent être indéfinies. Notez que HTTP 1.1 requiert l'en-tête Date dans toutes les réponses si possible (voir Section 14.18, [RFC2616]).

Le serveur DOIT effectuer des vérifications d'autorisation avant de vérifier tout en-tête conditionnel HTTP.

8.6 ETag

HTTP 1.1 recommande l'utilisation d'ETags plutôt que de dates de modification, pour le contrôle du cache, et il existe des raisons encore plus fortes de préférer les ETags pour la création. L'utilisation correcte des ETags est encore plus importante dans un environnement de création distribuée, car les ETags sont nécessaires avec les verrous pour éviter le problème de mise à jour perdue. Un client peut échouer à renouveler un verrou, par exemple, lorsque le verrou expire et que le client est accidentellement hors ligne ou au milieu d'un long téléchargement. Lorsqu'un client échoue à renouveler le verrou, il est tout à fait possible que la ressource puisse encore être reverrouillée et que l'utilisateur puisse continuer à éditer, tant qu'aucun changement n'a été effectué entre-temps. Les ETags sont nécessaires pour que le client puisse distinguer ce cas. Sinon, le client est forcé de demander à l'utilisateur s'il faut écraser la ressource sur le serveur sans même pouvoir dire à l'utilisateur si elle a changé. Les horodatages ne résolvent pas ce problème aussi bien que les ETags.

Les ETags forts sont beaucoup plus utiles pour les cas d'utilisation de création que les ETags faibles (voir Section 13.3.3 de [RFC2616]). L'équivalence sémantique peut être un concept utile mais cela dépend du type de document et du type d'application, et l'interopérabilité pourrait nécessiter un accord ou une norme en dehors de la portée de cette spécification et de HTTP. Notez également que les ETags faibles ont certaines restrictions dans HTTP, par exemple, ceux-ci ne peuvent pas être utilisés dans les en-têtes If-Match.

Notez que la signification d'un ETag dans une réponse PUT n'est clairement définie ni dans ce document ni dans RFC 2616 (c'est-à-dire, si l'ETag signifie que la ressource est équivalente octet par octet au corps de la requête PUT, ou si le serveur aurait pu apporter des modifications mineures au formatage ou au contenu du document lors du stockage). Ceci est un problème HTTP, pas purement un problème WebDAV.

Parce que les clients peuvent être forcés de demander aux utilisateurs ou de rejeter le contenu modifié si l'ETag change, un serveur WebDAV NE DEVRAIT PAS changer l'ETag (ou le temps Last-Modified) pour une ressource qui a un corps et un emplacement inchangés. L'ETag représente l'état du corps ou du contenu de la ressource. Il n'y a pas de moyen similaire de savoir si les propriétés ont changé.

8.7 Including Error Response Bodies (Inclusion de corps de réponse d'erreur)

HTTP et WebDAV n'utilisaient pas les corps de la plupart des réponses d'erreur pour des informations analysables par machine jusqu'à ce que la spécification pour les Extensions de Versioning à WebDAV introduise un mécanisme pour inclure des informations plus spécifiques dans le corps d'une réponse d'erreur (Section 1.6 de [RFC3253]). Le mécanisme de corps d'erreur est approprié à utiliser avec toute réponse d'erreur qui peut prendre un corps mais n'a pas déjà un corps défini. Le mécanisme est particulièrement approprié lorsqu'un code de statut peut signifier beaucoup de choses (par exemple, 400 Bad Request peut signifier que des en-têtes requis sont manquants, que les en-têtes sont incorrectement formatés, et bien plus encore). Ce mécanisme de corps d'erreur est couvert dans la Section 16.

8.8 Impact of Namespace Operations on Cache Validators (Impact des opérations d'espace de noms sur les validateurs de cache)

Notez que les en-têtes de réponse HTTP "Etag" et "Last-Modified" (voir [RFC2616], Sections 14.19 et 14.29) sont définis par URL (pas par ressource), et sont utilisés par les clients pour la mise en cache. Par conséquent, les serveurs doivent s'assurer que l'exécution de toute opération qui affecte l'espace de noms d'URL (telle que COPY, MOVE, DELETE, PUT ou MKCOL) préserve leur sémantique, en particulier:

Pour toute URL donnée, la valeur "Last-Modified" DOIT s'incrémenter chaque fois que la représentation retournée lors du GET change (dans les limites de la résolution de l'horodatage).
Pour toute URL donnée, une valeur "ETag" NE DOIT PAS être réutilisée pour différentes représentations retournées par GET.

En pratique, cela signifie que les serveurs

pourraient devoir incrémenter les horodatages "Last-Modified" pour chaque ressource à l'intérieur de l'espace de noms de destination d'une opération d'espace de noms à moins qu'ils ne puissent le faire de manière plus sélective, et
de même, pourraient devoir réaffecter les valeurs "ETag" pour ces ressources (à moins que le serveur n'alloue des balises d'entité de manière à ce qu'elles soient uniques dans tout l'espace de noms d'URL géré par le serveur).

Notez que ces considérations s'appliquent également à des cas d'utilisation spécifiques, tels que l'utilisation de PUT pour créer une nouvelle ressource à une URL qui a été mappée auparavant, mais qui a été supprimée depuis.