Lors de la création d'une collection via WebDAV si le nom de la collection se terminer par une barre oblique

Question

Une bibliothèque WebDAV J'utilise est l'émission cette demande

 
MKCOL /collection HTTP/1.1 

Pour qu'Apache est l'émission d'un 301 parce que/collection existe

 
HTTP/1.1 301 
Location: /collection/ 

au lieu d'un

 
HTTP/1.1 405 Method Not Allowed 

La spécification est un peu vague sur ce (ou il pourrait être ma re ading de celui-ci), mais lors de l'émission d'un MKCOL, le nom de votre collection devrait-il toujours se terminer par une barre oblique (comme c'est une collection)?

Answer 1

Le code HTTP 301 signifie "déplacé en permanence" comme vous le savez. Apache vous redirige gracieusement vers l'adresse URL appropriée.

Il ne peut pas vous donner un 405 car aucune ressource n'existe avec l'URL que vous avez fournie. Mais il ne peut pas non plus créer la ressource avec cette URL exacte. Ce qu'il peut faire est de créer la ressource avec l'URL appropriée puis de vous rediriger.

Mais pour répondre à votre question, vous devriez terminer les collections par "/" pour supprimer l'ambiguïté, sinon le comportement de normalisation de l'URI qui en résulte dépend du serveur que je crois. Je ne crois pas que l'ajout d'une barre oblique est imposé par un RFC.

EDIT:

Le MKCOL peut réussir sans le slash, mais remarquez que la ressource a créé un déclaré slash.

Le serveur dispose d'une option, conformément à la RFC. Puisqu'il détermine la procédure de normalisation d'URL tant qu'elle ne viole pas la spécification.

Le serveur peut alors soit essayer de normaliser l'URL que vous lui envoyez à chaque opération, renvoyant beaucoup de codes 3xx. Cela devient cher. Ou il peut vous corriger au début (POST, MKCOL, etc.) puis échouer ou rediriger après cela.

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

Quelque chose sur HTTP URL Scheme de RFC 2616

3.2.3 URI Comparaison

Lorsque l'on compare deux URIs pour décider si elles correspondent ou non, un client
doit utiliser un sensible à la casse comparaison octet par octet des adresses URI entières , avec les exceptions suivantes:

- 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 "/". 

Les caractères autres que ceux des ensembles "réservé" et "non sécurisé" (voir
RFC 2396 [42]) sont équivalents à leur codage "HEX HEX" "".

Par exemple, les trois URIs suivantes sont équivalentes:

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

Avis aucune mention sur la façon dont abs_path est défini. Aussi le serveur ne peut pas à proprement parler ignorer votre barre oblique selon les spécifications. Donc, émettre un "MKCOL/collection" et obtenir un 2xx régulier créé sans nouvelle URL "/ collection /" est incorrect. AFAIK, les RFC connexes qui définissent abs_path ne spécifient pas le slash final. Il appartient donc au serveur de comparer et de normaliser ceux-ci.