- Expédié
- 10 août 2026 à 14:52 UTC
- Auteur
- Kamo
- Commite
- 7746fce
mkCol a construit un ContactBook ne portant ni organisation ni propriétaire et retourné 201 indépendamment, donc créer un carnet d'adresses à partir d'un CardDAV Un client a échoué à la chasse à l'eau à chaque fois: ORGANISATION-ID NON NON NALE, et un Un livre sans propriétaire viole 'OWNER'ID 'NE NELL' 'O 'OR'G'DEFAULT' 'VRAI. MKCOL est acheminé et fait la publicité dans son propre en-tête de permis, donc c'était joignable, pas de code mort. Les deux champs d'application proviennent maintenant de la session établie par le filtre d'auths du DAV davUserId et davOrgId, la même paire utilise toutes les autres écritures ici. Que a également des questions plus importantes qu'auparavant: la propriété est devenue un contrôle d'accès avec le changement d'adresse par membre, donc un livre créé sans propriétaire serait invisible pour le membre pour lequel il a été fait même si l'encart avait succès. Deux corrections plus petites alors qu'il est ici: - MKCOL contre une collection qui existe déjà des réponses 405 plutôt que création silencieusement un deuxième livre (RFC 4918 section 9.3.1). - La réponse porte un en-tête de localisation. Le segment de chemin ne peut pas devenir L'identifiant du nouvel ouvrage est généré par la base de données, de sorte que les terres de collecte à sa propre URL, et l'emplacement est la façon dont le client est censé la trouver. Les broches d'essai qui l'accompagnent, sous contrat MKCOL, doivent satisfaire: Le manipulateur a besoin d'un servotaire pour faire de l'exercice, mais le NOT NULL l'organisation, la contrainte de contrôle propriétaire-ou-org-default et la contrainte obligatoire C'est exactement ce que l'ancien code a violé.