При создании коллекции через WebDAV имя коллекции должно заканчиваться косой чертой

Библиотека WebDAV, которую я использую, выдает этот запрос

MKCOL /collection HTTP/1.1

На что apache выдает 301, потому что / collection существует

HTTP/1.1 301
Location: /collection/

Вместо

HTTP/1.1 405 Method Not Allowed

Спецификация немного расплывчата (или это может быть мое прочтение), но при выдаче MKCOL должно ли имя вашей коллекции всегда заканчиваться косой чертой (поскольку это коллекция)?


collections webdav
person Dave Cheney    schedule 25.09.2008    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Как вы знаете, HTTP-код 301 означает «Перемещено навсегда».

Apache любезно перенаправляет вас на правильный URL. Он не может дать вам 405, потому что не существует ресурса с указанным вами URL-адресом. Но он также не может создать ресурс с этим точным URL-адресом. Что он может сделать, так это создать ресурс с правильным URL-адресом, а затем перенаправить вас.

Но чтобы ответить на ваш вопрос, вы должны заканчивать коллекции знаком «/», чтобы устранить двусмысленность, иначе результирующее поведение нормализации URI, как я полагаю, зависит от сервера. Я не верю, что добавление косой черты в конце обязательно в любом RFC.

РЕДАКТИРОВАТЬ:

MKCOL может быть успешным без завершающей косой черты, но обратите внимание, что ресурс, о котором сообщается, имеет завершающую косую черту.

У сервера есть опция, согласно RFC. Поскольку он определяет процедуру нормализации URL-адресов, если она не нарушает спецификацию.

Затем сервер может либо попытаться нормализовать любой URL-адрес, который вы отправляете, при каждой операции, возвращая множество кодов 3xx. Это становится дорого. Или он может исправить вас в начале (POST, MKCOL и т. д.), а затем сбой или перенаправление после этого.

Но ключевым моментом является то, что он всегда сообщит вам URL-адрес, который он предпочитает.

Кое-что о схеме URL-адресов HTTP из RFC 2616

3.2.3 Сравнение URI

При сравнении двух URI, чтобы решить, совпадают они или нет, клиент
ДОЛЖЕН использовать пооктетное сравнение всех URI с учетом регистра, за следующими исключениями:

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

Символы, не входящие в наборы "reserved" и "unsafe" (см.
RFC 2396 [42]), эквивалентны их кодировке ""%" HEX HEX".

Например, следующие три URI эквивалентны:

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

Обратите внимание, что нет упоминания о том, как определяется abs_path. Также сервер, строго говоря, не может игнорировать вашу косую черту в соответствии со спецификацией. Таким образом, выдача «MKCOL / collection» и получение обычного 2xx, созданного без нового URL-адреса «/ collection /», неверно.

Насколько я знаю, связанные RFC, определяющие abs_path, не указывают завершающую косую черту. Так что это зависит от сервера, как он сравнивает и нормализует их.

person kervin    schedule 25.09.2008
comment
Я согласен, если бы наш клиент выполнил перенаправление на /коллекцию/, он получил бы правильный код ответа. Суть в том, что если бы /коллекция/ не существовало, то MKCOL /коллекция была бы успешной. - person Dave Cheney; 25.09.2008
comment
Есть ли в конце созданного URL-адреса косая черта? Это все равно, что сказать, можно мне банан?, а Apache говорит: «Конечно, вот ваш апельсин». Сообщается, что созданный URL-адрес — это тот, который имеет значение :-) По крайней мере, в теории... - person kervin; 25.09.2008