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

StackOverflow https://stackoverflow.com/questions/1617058

  •  06-07-2019
  •  | 
  •  

Вопрос

Безопасно ли всегда пропускать косую черту в конце при добавлении строки запроса?

То есть, могу ли я использовать

http://example.com?querystring

вместо того, чтобы:

http://example.com/?querystring

?Все веб-хостинги, которые я использовал, поддерживают это, но можно ли с уверенностью предположить, что все серверные среды будут поддерживать этот метод?Это стандартно?

Это было полезно?

Решение

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

Видеть RFC1738 — URL-адрес иRFC2396 — URI.

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

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

И далее отмечается, что:

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

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

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

Также обратите внимание, что согласно спецификации вполне допустимо пропускать «/url-path» — обратите внимание, что в этом случае явно указан символ «/».

Таким образом, «foo.com?bar» недействителен, поскольку перед URL-путем нет символа «/».

Другие советы

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

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

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

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 в спецификации БНФ) и придерживаться 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 является полностью законным.

Мотивация этого изменения указана в приложении. Г.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

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

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

path-abempty  = *( "/" segment )

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

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

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

Раздел 4.3 говорит нам:

Ан строка абсолютного URL должно быть одним из следующих

При желании следует "?" и строка URL-Query.

Поскольку HTTP и HTTPS специальные схемы, любой URL-адрес HTTP или HTTPS должен удовлетворять первому из этих трех параметров, то есть http: или https: за которым следует строка URL-адреса относительной схемы, который:

должно быть "//", за которым следует действительная строка хоста, за которым необязательно следует ":"и Строка URL-порта, за которым необязательно следует строка абсолютного URL-адреса пути.

А строка абсолютного URL-адреса пути определяется так, чтобы начинаться с косой черты, но является явно необязательным в определении строки абсолютного URL-адреса выше;таким образом, допустимо перейти прямо с хоста на "?" и строку запроса, поэтому такие URL-адреса, как http://example.com?query являются законными.

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

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

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

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

http://tools.ietf.org/html/rfc2396

Компоненту authority предшествует двойная косая черта "//" и заканчивается следующей косой чертой "/", вопросительным знаком "?" или концом URI.В компоненте полномочий символы ";", ":", "@", "?", и "/" зарезервированы

Исходя из этого утверждения, вопросительный знак должен указывать на конец компонента authority, с косой чертой или без нее.

http://tools.ietf.org/html/rfc1738 (теги заменены)

{path} является необязательным, как и {searchpart} и предшествующее ему "?".Если ни {path}, ни {searchpart} не присутствуют, символ "/" также может быть опущен.

Однако в этом заявлении говорится, что завершающая косая черта может быть опущена только в том случае, если и path, и searchpart не заданы заранее.

В реальном мире я ранее мог опускать косую черту перед значением запроса, но недавно обнаружил ситуацию, когда она падает.Если у вас есть запрос, подобный этому http://my.domain.com?do=something, и вы просматриваете html-страницу в Internet Explorer, ссылка исправлено с помощью IE.Если вы затем нажмете Файл, Отправить, Страницу по электронной почте ..., ссылка будет добавлена в электронное письмо с недопустимым форматом.Проблемы зависят от содержимого значения запроса, но мы смогли создать недопустимые URL-адреса.

Подводя итог, можно сказать, что следует работает, но в крайних случаях выходит из строя.

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top