Lors de la création d'une collection via WebDAV, le nom de la collection doit-il se terminer par une barre oblique

Question

Une bibliothèque WebDAV que j'utilise émet cette demande

MKCOL /collection HTTP/1.1

Pour lequel apache émet un 301 car / collection existe

HTTP/1.1 301
Location: /collection/

Plutôt qu'un

HTTP/1.1 405 Method Not Allowed

La spécification est un peu vague à ce sujet (ou ce pourrait être ma lecture), mais lors de la création d'un MKCOL, le nom de votre collection doit-il toujours se terminer par une barre oblique (puisqu'il s'agit d'une collection)?

Answer 1

Code HTTP 301 signifie " Déplacé de manière permanente " comme vous le savez.

Apache vous redirige gracieusement vers l’URL appropriée. Il ne peut pas vous donner un 405 car aucune ressource n'existe avec l'URL fournie. Mais il ne peut pas non plus créer la ressource avec cette URL exacte. Ce qu’il peut faire, c’est créer la ressource avec l’URL appropriée puis vous rediriger.

Mais pour répondre à votre question, vous devez mettre fin aux collectes avec "" /". supprimer l'ambiguïté, sinon le comportement de normalisation d'URI résultant appartient au serveur, je crois. Je ne pense pas que l'ajout d'un slash final soit obligatoire par un RFC.

EDIT:

La MKCOL peut réussir sans la barre oblique finale, mais notez que la ressource créée a une barre oblique finale.

Le serveur a une option, conformément à la RFC. Puisqu'il détermine la procédure de normalisation d'URL tant qu'il n'enfreint pas la spécification.

Le serveur peut alors essayer de normaliser chaque URL que vous lui envoyez, à chaque opération, en renvoyant de nombreux codes 3xx. Cela coûte cher. Vous pouvez également vous corriger au début (POST, MKCOL, etc.), puis échouer ou rediriger ensuite.

Mais le point clé est qu'il vous indiquera toujours l'URL qu'il préfère.

Quelque chose sur le schéma d'URL HTTP de RFC 2616

  

3.2.3 Comparaison d'URI

     

Lorsque vous comparez deux URI pour décider   si elles correspondent ou non, un client
  DEVRAIT utiliser un sensible à la casse   comparaison octet par octet du   URI entiers, à ces exceptions près:

  - A port that is empty or not given is equivalent to the default
    port for that URI-reference;

    - Comparisons of host names MUST be case-insensitive;

    - Comparisons of scheme names MUST be case-insensitive;

    - An empty abs_path is equivalent to an abs_path of "/".

     

Caractères autres que ceux du   " réservé " et " unsafe " ensembles (voir
  RFC 2396 [42]) sont équivalents à leurs   "% " HEX HEX " encodage.

     

Par exemple, les trois suivants   Les URI sont équivalents:

  http://abc.com:80/~smith/home.html
  http://ABC.com/%7Esmith/home.html
  http://ABC.com:/%7esmith/home.html

Ne notez pas comment abs_path est défini. De plus, le serveur ne peut pas, à proprement parler, ignorer votre barre oblique selon les spécifications. Vous devez donc émettre un "MKCOL / collection". et obtenir un 2xx normal créé sans nouvelle " / collection / " L'URL est incorrecte.

D'après les informations dont je dispose, les RFC associées qui définissent abs_path ne spécifient pas la barre oblique finale. C’est donc au serveur de déterminer comment il compare et normalise ces informations.