Можно ли всегда пропускать конечную косую черту при добавлении строки запроса?
То есть, могу ли я использовать
http://example.com?querystring
вместо:
http://example.com/?querystring
? Все веб-хосты, которые я использовал, поддерживают это, но можно ли предположить, что все серверные среды будут поддерживать этот метод? Это стандартно?
Нет, неправильно пропускать косую черту. Он может работать в современных браузерах: однако это не делает его правильным.
См. RFC1738 - URL и RFC2396 - URI.
Формат в соответствии с RFC1738 (я исключил формат схемы здесь):
//<пользователь>: <пароль> @<хост>: <порт>/<URL-путь>
И далее следует отметить, что:
... "/" между хостом (или портом) и URL-путем НЕ является частью URL-пути.
В этом случае "?" является частью URL-пути, который
... зависит от используемой схемы, а также от способа ее интерпретации.
Также обратите внимание, что в соответствии со спецификацией вполне допустимо опускать "/url-path" - обратите внимание, что "/" было явно включено в этом случае.
Таким образом, "foo.com?bar" недопустим, потому что перед URL-путем нет "/".
В соответствии с современными спецификациями, да, допустимо пропускать косую черту, вопреки утверждениям, принятым здесь.
Хотя принятый ответ правильно цитирует RFC 1738 (выпущенный более 20 лет назад!), Он ошибочно утверждает, что RFC 2396 (выпущенный в 1998 г.) требует косой черты, и пренебрегает тем, что обе эти спецификации в свою очередь устарели в RFC 3986, выпущенном в 2005 (еще за несколько лет до того, как принятый ответ был написан), а совсем недавно - стандартом WhatWG URL, которые позволяют опустить косую черту.
Давайте рассмотрим каждую из этих спецификаций по очереди, от самой ранней до последней:
Неявно требуется, чтобы косая черта была включена, указав, что она может быть опущена, если URL не содержит ни пути, ни строки запроса (здесь она называется searchpart). Выделение внизу мое:
URL-адрес HTTP принимает форму:
http://<host>:<port>/<path>?<searchpart>где
<host>и<port>такие, как описано в разделе 3.1. Если:<port>не указан, по умолчанию используется порт 80. Имя пользователя или пароль не допускаются.<path>- это селектор HTTP, а<searchpart>- строка запроса.<path>является необязательным, как и<searchpart>и предшествующее ему "?". Если нет ни<path>ни<searchpart>, "/" также может быть опущен.
Здесь допустимо опускать косую черту. Этот RFC узаконивает некоторые странные синтаксисы URL, которые не имеют двойной косой черты после схемы, но если мы игнорируем их (они с opaque_part в спецификации BNF) и придерживаемся URL, содержащих хост, то мы обнаружить, что absoluteURI определяется следующим образом...
absoluteURI = scheme ":" ( hier_part | opaque_part )
и что hier_part выглядит так:
hier_part = ( net_path | abs_path ) [ "?" query ]
и что net_path выглядит так:
net_path = "//" authority [ abs_path ]
где abs_path, в свою очередь, определен, чтобы начинаться с косой черты. Обратите внимание, что abs_path является необязательным в приведенной выше грамматике - это означает, что URL-адрес scheme://authority?query формы scheme://authority?query является полностью допустимым.
Мотивация для этого изменения указана в приложении G.2. Модификации как из RFC 1738, так и из RFC 1808:
Вопросительный знак "?" символ был удален из набора разрешенных символов для userinfo в компоненте полномочий, поскольку тестирование показало, что многие приложения обрабатывают его как зарезервированный для ветки компонента запроса от остальной части URI.
Другими словами - код в реальном мире предполагал, что первый знак вопроса в URL, где угодно, помечает начало строки запроса, и поэтому спецификация была прагматически обновлена, чтобы соответствовать реальности.
Опять же, допустимо опускать косую черту. Спецификация выражает это, говоря, что "путь" требуется в каждом URI, который содержит полномочия (хост), и этот путь должен начинаться с косой черты или состоять из символов:
Общий синтаксис URI состоит из иерархической последовательности компонентов, называемой схемой, полномочиями, путем, запросом и фрагментом.
URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] hier-part = "//" authority path-abempty / path-absolute / path-rootless / path-emptyКомпоненты схемы и пути являются обязательными, хотя путь может быть пустым (без символов). При наличии прав доступа путь должен быть либо пустым, либо начинаться с символа косой черты ("/").
Для полноты обратите внимание, что path-abempty определяется позже:
path-abempty = *( "/" segment )
Это действительно позволяет ему не содержать символов.
Опять же, пропуск косой черты допустим, хотя на этот раз у нас нет БНФ, но вместо этого нам нужно читать много прозы.
Раздел 4.3 говорит нам:
Строка абсолютного URL должна быть одной из следующих
- строка URL-схемы, которая является ASCII-нечувствительным к регистру соответствием для специальной схемы, а не ASCII-нечувствительным к регистру соответствием для "
file", за которым следуют ":" и строка схемы-относительного-специального-URL-адреса- строка схемы URL, которая не является ASCII-регистронезависимым совпадением для специальной схемы, за которой следуют ":" и строка относительного URL
- строка URL-схемы, которая является ASCII-регистронезависимым совпадением для "файла", за которым следует ":" и строка схемы-относительного файла-URL-адреса
любой необязательно сопровождается "?" и строка URL-запроса.
Поскольку HTTP и HTTPS являются специальными схемами, любой URL-адрес HTTP или HTTPS должен удовлетворять первому из этих трех параметров, то есть http: или https: последующей строкой относительного-специального-URL-адреса схемы, которая:
должно быть "
//", за которым следует допустимая строка хоста, за которой необязательно следует ":" и строка URL-порта, за которой необязательно следует строка path-absolute-URL.
Строка path-absolute-URL определена, чтобы начинаться с косой черты, но явно необязательна в определении строки absolute-URL выше; таким образом, можно разрешить прямой переход от хоста к строке " ? " и строке запроса, поэтому URL-адреса, такие как http://example.com?query являются допустимыми.
Конечно, ничто из этого не дает железной гарантии того, что каждый веб-сервер или HTTP-библиотека будет принимать такие URL-адреса или что они будут обрабатывать их как семантически эквивалентные URL-адресу, который содержит косую черту. Но что касается спецификаций, пропуск слеша вполне законен.
Небезопасно это считать. Веб-серверы и автономные веб-приложения обычно проверяют URL-адрес, указанный в запросе, но нет гарантии, что они будут относиться к /abc равным /abc/. Веб-серверы и автономные веб-приложения могут делать все, что им нравится, с информацией, полученной из URL-адреса, и это не обязательно будет тем, что вы ожидаете. Вам нужно будет узнать, что такое соглашение для конкретного URL.
Обратите внимание, что большинство веб-серверов и рамок веб-приложений стараются принять всевозможные входы и справиться с ними соответствующим образом. Поэтому в большинстве случаев веб-сервер или автономное веб-приложение будет относить /abc равным /abc/. Но помните, потому что сервер может делать все, что ему нравится с этим путем, что это просто общее наблюдение с потенциально многочисленными исключениями.
Добавляя к принятому ответу с дополнительной информацией, которую я нашел после исследования этой проблемы:
http://tools.ietf.org/html/rfc2396
Компонент полномочий предшествует двойной косой чертой "//" и заканчивается следующей косой чертой "/" , вопросительным знаком "?" или к концу URI. В пределах компонента полномочий символы ";", ":", "@", "?" И "/" зарезервированы
Основываясь на этом утверждении, знак вопроса должен указывать конец компонента полномочий с или без косой черты.
http://tools.ietf.org/html/rfc1738 (теги заменены)
{путь} не является обязательным, как и {searchpart} и его предыдущие "?" . Если нет {path} и {searchpart}, "/" также может быть опущен.
Однако это утверждение говорит о том, что конечная косая черта может быть опущена только в том случае, если путь и путь поиска не заданы.
В реальном мире я ранее мог опустить конечную косую черту перед значением запроса, но недавно обнаружил, что ситуация падает. Если у вас есть такой запрос, как http://my.domain.com?do=something, и вы просматриваете html-страницу в Internet Explorer, ссылка фиксируется IE. Если вы затем щелкните "Файл", "Отправить", "Страница" по электронной почте..., ссылка будет добавлена в электронное письмо с недопустимым форматом. Проблемы различаются по содержанию значения запроса, но мы смогли создать недопустимые URL-адреса.
В общем, он должен работать, но падает в крайних случаях.