Appendix B. Notes on HTTP Client Compatibility (Notes sur la compatibilité des clients HTTP)
Annexe B. Notes on HTTP Client Compatibility (Notes sur la compatibilité des clients HTTP)
WebDAV a été conçu pour être, et s'est avéré être, rétrocompatible avec HTTP 1.1. Les méthodes PUT et DELETE sont définies dans HTTP et peuvent donc être utilisées par des clients HTTP ainsi que par des clients conscients de WebDAV, mais les réponses à PUT et DELETE ont été étendues dans cette spécification de manière à ce que seul un client WebDAV soit entièrement préparé. Certaines préoccupations théoriques ont été soulevées quant à savoir si ces réponses causeraient des problèmes d'interopérabilité avec les clients HTTP uniquement, et cette section aborde ces préoccupations.
Étant donné que tout client HTTP devrait gérer les codes d'état de niveau 400 et 500 non reconnus comme des erreurs, les nouveaux codes d'état suivants ne devraient présenter aucun problème: 422, 423 et 507 (424 est également un nouveau code d'état mais il n'apparaît que dans le corps d'une réponse Multistatus.) Ainsi, par exemple, si un client HTTP tentait de faire un PUT ou DELETE sur une ressource verrouillée, la réponse 423 Locked devrait entraîner une erreur générique présentée à l'utilisateur.
La réponse 207 Multistatus est intéressante car un client HTTP émettant une requête DELETE vers une collection pourrait interpréter une réponse 207 comme un succès, même s'il ne réalise pas que la ressource est une collection et ne peut pas comprendre que l'opération DELETE pourrait avoir été un échec complet ou partiel. Cette interprétation n'est pas entièrement justifiée, car une réponse de niveau 200 indique que le serveur "a reçu, compris et accepté" la demande, et non que la demande a abouti à un succès complet.
Une option est qu'un serveur pourrait traiter un DELETE d'une collection comme une opération atomique, et utiliser soit 204 No Content en cas de succès, soit une réponse d'erreur appropriée (niveau 400 ou 500) pour une erreur. Cette approche maximiserait en effet la rétrocompatibilité. Cependant, étant donné que les tests d'interopérabilité et les discussions du groupe de travail n'ont révélé aucune instance de clients HTTP émettant une requête DELETE contre une collection WebDAV, cette préoccupation est plus théorique que pratique. Ainsi, les serveurs sont susceptibles de réussir complètement à interagir avec les clients HTTP même s'ils traitent toute requête DELETE de collection comme une requête WebDAV et envoient une réponse 207 Multi-Status.
En général, les implémentations de serveur sont encouragées à utiliser les réponses détaillées et autres mécanismes définis dans ce document plutôt que d'apporter des modifications pour des préoccupations d'interopérabilité théoriques.