ОК, чтобы пропустить косую черту перед строкой запроса?

Ответ 1

Нет, неправильно пропускать косую черту. Он может работать в современных браузерах: однако это не делает его правильным.

См. RFC1738 - URL и RFC2396 - URI.

Формат в соответствии с RFC1738 (я исключил формат схемы здесь):

//<пользователь>: <пароль> @<хост>: <порт>/<URL-путь>

И далее следует отметить, что:

... "/" между хостом (или портом) и URL-путем НЕ является частью URL-пути.

В этом случае "?" является частью URL-пути, который

... зависит от используемой схемы, а также от способа ее интерпретации.

Также обратите внимание, что в соответствии со спецификацией вполне допустимо опускать "/url-path" - обратите внимание, что "/" было явно включено в этом случае.

Таким образом, "foo.com?bar" недопустим, потому что перед URL-путем нет "/".

Ответ 2

В соответствии с современными спецификациями, да, допустимо пропускать косую черту, вопреки утверждениям, принятым здесь.

Хотя принятый ответ правильно цитирует RFC 1738 (выпущенный более 20 лет назад!), Он ошибочно утверждает, что RFC 2396 (выпущенный в 1998 г.) требует косой черты, и пренебрегает тем, что обе эти спецификации в свою очередь устарели в RFC 3986, выпущенном в 2005 (еще за несколько лет до того, как принятый ответ был написан), а совсем недавно - стандартом WhatWG URL, которые позволяют опустить косую черту.

Давайте рассмотрим каждую из этих спецификаций по очереди, от самой ранней до последней:

RFC 1738: унифицированные указатели ресурсов (URL) (выпущен в 1994 г.)

Неявно требуется, чтобы косая черта была включена, указав, что она может быть опущена, если URL не содержит ни пути, ни строки запроса (здесь она называется searchpart). Выделение внизу мое:

URL-адрес HTTP принимает форму:

http://<host>:<port>/<path>?<searchpart>

где <host> и <port> такие, как описано в разделе 3.1. Если: <port> не указан, по умолчанию используется порт 80. Имя пользователя или пароль не допускаются. <path> - это селектор HTTP, а <searchpart> - строка запроса. <path> является необязательным, как и <searchpart> и предшествующее ему "?". Если нет ни <path> ни <searchpart>, "/" также может быть опущен.

RFC 2396: унифицированные идентификаторы ресурсов (URI): общий синтаксис (выпущен в 1998 году; "обновляет" RFC 1738)

Здесь допустимо опускать косую черту. Этот 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, где угодно, помечает начало строки запроса, и поэтому спецификация была прагматически обновлена, чтобы соответствовать реальности.

RFC 3986: унифицированный идентификатор ресурса (URI): общий синтаксис (выпущен в 2005 г.; "устарел" RFC 2396)

Опять же, допустимо опускать косую черту. Спецификация выражает это, говоря, что "путь" требуется в каждом URI, который содержит полномочия (хост), и этот путь должен начинаться с косой черты или состоять из символов:

3. Синтаксические компоненты

Общий синтаксис URI состоит из иерархической последовательности компонентов, называемой схемой, полномочиями, путем, запросом и фрагментом.

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

Компоненты схемы и пути являются обязательными, хотя путь может быть пустым (без символов). При наличии прав доступа путь должен быть либо пустым, либо начинаться с символа косой черты ("/").

Для полноты обратите внимание, что path-abempty определяется позже:

path-abempty  = *( "/" segment )

Это действительно позволяет ему не содержать символов.

URL Standard от WhatWG (уровень жизни при активном обслуживании, впервые созданный в 2012 году с целью устаревания RFC 3986)

Опять же, пропуск косой черты допустим, хотя на этот раз у нас нет БНФ, но вместо этого нам нужно читать много прозы.

Раздел 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-адресу, который содержит косую черту. Но что касается спецификаций, пропуск слеша вполне законен.

Ответ 3

Небезопасно это считать. Веб-серверы и автономные веб-приложения обычно проверяют URL-адрес, указанный в запросе, но нет гарантии, что они будут относиться к /abc равным /abc/. Веб-серверы и автономные веб-приложения могут делать все, что им нравится, с информацией, полученной из URL-адреса, и это не обязательно будет тем, что вы ожидаете. Вам нужно будет узнать, что такое соглашение для конкретного URL.

Обратите внимание, что большинство веб-серверов и рамок веб-приложений стараются принять всевозможные входы и справиться с ними соответствующим образом. Поэтому в большинстве случаев веб-сервер или автономное веб-приложение будет относить /abc равным /abc/. Но помните, потому что сервер может делать все, что ему нравится с этим путем, что это просто общее наблюдение с потенциально многочисленными исключениями.

Ответ 4

Добавляя к принятому ответу с дополнительной информацией, которую я нашел после исследования этой проблемы:

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-адреса.

В общем, он должен работать, но падает в крайних случаях.