RFC 4918 Points techniques des annexes
Ce document résume le contenu clé des annexes A-F de RFC 4918.
Annexe A. Processing XML Elements (Considérations sur le traitement des éléments XML)
Points clés
1. Exigences d'analyse XML:
- Doit utiliser un analyseur XML conforme aux normes W3C
- Doit prendre en charge les espaces de noms XML
- Doit traiter le XML bien formé
2. Traitement des éléments inconnus:
- Les clients et serveurs doivent ignorer les éléments XML non reconnus
- Cela garantit la compatibilité ascendante
- Les extensions ne cassent pas les implémentations existantes
3. Traitement des espaces blancs:
- Les espaces blancs dans les valeurs d'attributs sont significatifs
- Les espaces blancs dans les valeurs d'attributs doivent être préservés
- Ignorer l'attribut xml:space
4. Considérations de sécurité:
- Désactiver les entités externes pour prévenir les attaques XXE
- Limiter la taille du document XML
- Limiter la profondeur d'analyse
Annexe B. HTTP Client Compatibility (Considérations de compatibilité des clients HTTP)
Directives de compatibilité
1. Clients HTTP/1.1:
- Les clients HTTP/1.1 de base peuvent accéder aux ressources WebDAV
- Mais ne peuvent pas utiliser les fonctionnalités spécifiques à WebDAV (verrouillage, propriétés, etc.)
- Utiliser des méthodes HTTP standard (GET, PUT, DELETE)
2. Support partiel de WebDAV:
- Les clients peuvent implémenter un sous-ensemble de WebDAV
- Doivent découvrir les capacités du serveur via OPTIONS
- Dégradation gracieuse vers les fonctionnalités HTTP/1.1
3. Interopérabilité:
- Suivre les spécifications HTTP
- Gérer correctement les redirections
- Prendre en charge les connexions persistantes
Annexe C. The 'opaquelocktoken' Scheme (Schéma et URI opaquelocktoken)
Schéma URI opaquelocktoken
Définition: Schéma URI spécialement conçu pour les jetons de verrouillage WebDAV
Syntaxe:
opaquelocktoken:<UUID>
Exemple:
opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
Caractéristiques:
- Globalement unique: Utilise UUID pour garantir l'unicité
- Opaque: Les clients ne doivent pas analyser sa structure interne
- Sûr pour URL: Peut être utilisé dans les en-têtes HTTP et XML
Scénarios d'utilisation:
- Jeton de verrouillage retourné par la méthode LOCK
- Jeton de verrouillage soumis dans l'en-tête If
- Jeton de verrouillage spécifié dans l'en-tête Lock-Token
Différence avec d'autres URI:
- Non déréférençable (pas de ressource correspondante)
- Utilisé uniquement pour identifier les verrous
- Cycle de vie identique au verrou
Annexe D. Lock-null Resources (Ressources verrouillées nulles)
Concept de ressource verrouillée nulle (LNR)
Définition: Type de ressource spécial défini dans RFC 2518, créé en exécutant LOCK sur une URL non mappée.
Changements dans RFC 4918:
- RFC 4918 recommande l'utilisation de "ressources vides verrouillées" au lieu de LNR
- Mais pour la compatibilité ascendante, les serveurs peuvent continuer à prendre en charge LNR
Ressources vides verrouillées vs LNR
| Caractéristique | Ressource vide verrouillée (recommandé) | Lock-Null Resource (compatibilité) |
|---|---|---|
| Méthode de création | LOCK sur URL non mappée | LOCK sur URL non mappée |
| Comportement GET | Retourne 200 et contenu vide | Retourne 404 |
| Propriétés | Propriétés de ressource normales | Propriétés LNR spéciales |
| Visibilité | Visible comme membre de collection | Peut être invisible |
| MKCOL | Échoue (405) | Converti en collection |
Recommandations de compatibilité client:
- Après avoir exécuté LOCK sur une URL non mappée, utiliser PUT pour ajouter du contenu
- Ne pas dépendre du comportement spécifique de GET ou MKCOL
- Ne pas dépendre des propriétés spécifiques de LNR
Annexe E. Guidance for Clients Desiring to Authenticate (Guide pour les clients souhaitant s'authentifier)
Découverte de l'authentification
Problème: Comment un client découvre-t-il qu'une ressource nécessite une authentification?
Méthode 1 - Requête OPTIONS proactive:
OPTIONS /resource HTTP/1.1
Host: example.com
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm="WebDAV"
Méthode 2 - Essayer l'opération et gérer 401:
PROPFIND /resource HTTP/1.1
Host: example.com
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Digest realm="WebDAV"
Meilleures pratiques d'authentification
1. Prendre en charge plusieurs schémas d'authentification:
- Authentification Basic (nécessite HTTPS)
- Authentification Digest
- Jetons Bearer OAuth 2.0
- Certificats clients
2. Mettre en cache les informations d'authentification:
- Mettre en cache les informations pour le même realm
- Implémenter des timeouts appropriés
- Stocker en toute sécurité les informations sensibles
3. Gérer les échecs d'authentification:
- Fournir des messages d'erreur clairs
- Permettre la réauthentification
- Éviter de verrouiller les comptes utilisateurs
4. Considérations de sécurité:
- Toujours utiliser HTTPS pour transmettre les informations d'identification
- Ne pas inclure de mots de passe dans l'URL
- Implémenter une limitation de taux pour prévenir les attaques par force brute
Annexe F. Summary of Changes from RFC 2518 (Résumé des modifications par rapport à RFC 2518)
RFC 4918 obsolète RFC 2518, les principales modifications incluent:
F.1 Modifications des implémentations client et serveur
1. Suppression des ressources verrouillées nulles (LNR):
- Recommande l'utilisation de "ressources vides verrouillées"
- Simplifie l'implémentation
- Améliore l'interopérabilité
2. Clarification de la syntaxe de l'en-tête If:
- Règles de correspondance plus claires
- Exemples améliorés
- Élimine les ambiguïtés
3. Comportement des collections:
- Clarifie le comportement de DELETE sur les collections
- Clarifie l'utilisation de l'en-tête Depth
- Améliore la gestion des erreurs
4. Traitement des propriétés:
- Clarifie les propriétés vivantes vs mortes
- Améliore les exigences d'atomicité de PROPPATCH
- Clarifie le traitement XML des valeurs de propriétés
F.2 Modifications des implémentations serveur
1. Réponse 207 Multi-Status:
- Exigences de format plus strictes
- Rapport d'erreurs amélioré
- Élément href obligatoire
2. Comportement de verrouillage:
- Clarifie le mécanisme de rafraîchissement du verrou
- Améliore la gestion des timeouts
- Clarifie les exigences de soumission de jeton de verrouillage
3. Sémantique COPY/MOVE:
- Clarifie le comportement de l'en-tête Overwrite
- Améliore le traitement des ressources de destination
- Clarifie l'impact des verrous
F.3 Autres modifications
1. Améliorations de sécurité:
- Ajoute des directives de sécurité XML
- Améliore les recommandations de protection DoS
- Clarifie les exigences d'authentification
2. Améliorations de l'interopérabilité:
- Spécifications plus claires
- Plus d'exemples
- Élimine les ambiguïtés d'implémentation
3. Fonctionnalités obsolètes:
- Certaines fonctionnalités optionnelles de RFC 2518
- Simplifie les exigences de conformité
- Réduit la charge d'implémentation
Résumé des annexes
Les annexes fournissent les informations clés suivantes:
- Directives d'implémentation (A, B): Traitement XML et compatibilité HTTP
- Détails techniques (C, D): Schéma URI de jeton de verrouillage et ressources verrouillées nulles
- Conseils pratiques (E): Directives d'implémentation de l'authentification
- Historique d'évolution (F): Modifications de RFC 2518 à RFC 4918
Ces annexes sont très précieuses pour implémenter des clients et serveurs WebDAV de haute qualité.