Когда звездочка должна быть закодирована в URL-адресе HTTP?

В соответствии с RFC1738, звездочка (*) "может использоваться некодированная в URL-адресе":

Таким образом, только буквенно-цифровые символы, специальные символы "$ -_. +! * '()," и зарезервированные символы, используемые для их зарезервированных целей, могут использоваться unencoded в URL.

Однако w3.org Именование и адресация говорит, что звездочка "зарезервирована для использования как имеющая особое значение в определенных схемах" и подразумевает, что он должен быть закодирован.

Кроме того, согласно RFC3986, URL-адрес является URI:

Термин "Uniform Resource Locator" (URL) относится к подмножеству URI что в дополнение к определению ресурса определение ресурса путем описания его механизма первичного доступа (например, его местоположение сети).

Он также указывает, что звездочка является "суб-delim", которая является частью "зарезервированного набора" и:

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

Он также явно указывает, что он обновляет RFC1738.

Я прочитал все это как требование, чтобы звездочки были закодированы в URL-адресе, если они не используются для специального назначения, определенного схемой URI.

Является RFC1738 канонической ссылкой для схемы URI HTTP? Это как-то освобождает звездочку от кодирования или устаревает в этом отношении из-за RFC3986?

Wikipedia говорит, что "[t] он не должен быть закодирован в процентах, если у него нет зарезервированной цели". RFC1738 удалить зарезервированную цель звездочки?

Различные ресурсы и инструменты, по-видимому, разделены по этому вопросу.

PHP urlencode и rawurlencode - последний из которых претендует на RFC3986 - сделать кодировку звездочки.

Однако JavaScript escape и encodeURIComponent не кодируют звездочку.

И Java URLEncoder не кодирует звездочку:

Специальные символы ".", "-", "*" и "_" остаются неизменными.

Популярные онлайн инструменты (два первых результата для поиск Google для "онлайн-кодировщика URL" ) также не кодирует звездочку. URL Encode and Decode Tool специально указывает, что "зарезервированные символы должны быть закодированы только при определенных обстоятельствах". Далее он перечисляет звездочку и амперсанд в качестве зарезервированных символов. Он кодирует амперсанд, но не звездочку.

Другие подобные вопросы в сообществе Stack Exchange, похоже, имеют устаревшие, неполные или неубедительные ответы:

urlencode() символ 'звездочка' (звезда?) Этот вопрос подчеркивает различия между обработкой Java и PHP звездочкой и спрашивает, что является "правильным". принятый ответ ссылается только RFC1738, не говоря уже о более позднем RFC3986 и разрешения конфликта. Другой ответ подтверждает несоответствие и предполагает, что звездочки различаются для URL-адресов, в частности, в отличие от других URI, но не предоставляют конкретных полномочий для этого вывода.
Может ли URL-адрес иметь звездочку? Один ответ ссылается только на более старый RFC1738 и принятый ответ подразумевает, что это приемлемо при использовании в качестве разделителя, который, как предполагается, является "зарезервированное назначение" .
Можно ли использовать звездочки в URL-адресах? принятый ответ, кажется, препятствует использованию звездочки без пояснений правила, регулирующие использование. Другой ответговорит, что вы можете использовать звездочку "потому что это зарезервированный символ". Но разве это не так, только если вы используете его для своей зарезервированной цели?
экранирование специального символа в URL Один ответ указывает, что "существует некоторая двусмысленность относительно того, звездочка должна быть закодирована в URL-адресе". Я пытаюсь решить эту двусмысленность с этим вопросом.
Spring UriUtils и RFC3986 В этом вопросе отмечается, что UriUtil encodeQueryParam хочет следовать RFC3986, но он не кодирует звездочку. На этот вопрос нет ответов с 2014-08-01 12:50 вечера CDT.
Как закодировать URL-адрес в JavaScript? Это, похоже, канонический JavaScript-код для кодирования на Stack Overflow, и хотя ответы отмечают, что звездочки исключены из различные методы, они не решают, должны ли они быть.

С учетом всего этого, когда звездочка должна быть закодирована в URL-адресе HTTP?

Ответ 1

Короткий ответ

Текущее определение синтаксиса URL указывает, что вам никогда не нужно кодировать символ звездочки в коде пути, запроса или фрагмента URL-адреса.

HTTP 1.1

Как отметил @Riley Major, RFC указывает, что ссылки HTTP 1.1 для синтаксиса URL были устарели RFC3986, что не так черное и белое относительно использования звездочек, поскольку первоначально ссылка RFC была.

RFC2396 (спецификация URL до января 2005 г. - оригинальный ответ)

Звездочку никогда не нужно кодировать в URL-адресах HTTP 1.1, поскольку * указан как "безоговорочный символ" в RFC2396, который используется для определения Синтаксис URI в HTTP 1.1. Незарезервированные символы разрешены в компоненте пути URL-адреса.

2.3. Незарезервированные символы

Символы данных, разрешенные в URI, но не имеющие зарезервированной цели, называются безоговорочными. К ним относятся буквы верхнего и нижнего регистра, десятичные цифры и ограниченный набор знаков препинания и символов.
   unreserved  = alphanum | mark

   mark        = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
Незарезервированные символы могут быть экранированы без изменения семантики URI, но это не должно выполняться, если URI не используется в контексте, который не позволяет отображать неэкранированный символ.

RFC3986 (текущий синтаксис URL для HTTP)

RFC3986 изменяет RFC2396, чтобы сделать звездочку зарезервированным символом, по той причине, что он "обычно небезопасен для декодирования". Мое понимание этого RFC заключается в том, что символ неэкранированной звездочки разрешен в компонентах пути, запроса и фрагмента URL-адреса, поскольку эти компоненты не указывают звездочку в качестве разделителя (2.2. Зарезервированные символы):

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

Кроме того, 3.3 Путь подтверждает, что подмножество зарезервированных символов (sub-delims) может использоваться некодировано в сегментах пути (части компонента пути разбиты на /):

Помимо точечных сегментов ( "." и ".." ) в иерархических путях, сегмент пути считается непрозрачным по обобщенному синтаксису. В URI-приложениях часто используются зарезервированные символы, разрешенные в сегменте.... Например, зарезервированные символы с запятой ( ";" ) и равно ( "=" ) часто используются для разграничения параметров и значений параметров, применимых к этому сегменту. Зарезервированный символ запятой ( "," ) часто используется для аналогичных целей. Например, один производитель URI может использовать сегмент, такой как "name; v = 1.1", чтобы указать ссылку на версию 1.1 "name", тогда как другой может использовать сегмент, такой как "name, 1.1", чтобы указать то же самое.

HTTP 1.0

HTTP 1.0 ссылается RFC1738, чтобы определить синтаксис URL, который через серию обновлений и устареваний означает, что он использует тот же RFC, что и HTTP 1.1 для синтаксиса URL.

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

Как примечание, символ asterisk имеет особое значение в Request-URI в обоих спецификациях HTTP, но не представляется возможным представлять его с помощью HTTP URL:

Звездочка "*" означает, что запрос не применяется к определенному ресурсу, а к самому серверу и разрешен только в том случае, если используемый метод не обязательно относится к ресурсу. Одним из примеров может быть
   OPTIONS * HTTP/1.1

Отказ от ответственности: я просто читаю и интерпретирую эти RFC самостоятельно, поэтому я могу ошибаться.