URL, кодирующий символ @ в пути запроса - PullRequest
Новая
       13

URL, кодирующий символ @ в пути запроса

0 голосов
/ 07 июня 2019

Есть места / библиотеки, которые, по-видимому, рассматривают символы "@" в сегменте пути URL как "специальный символ", который должен быть закодирован, и места / библиотеки, которые этого не делают.

Я ищу, чтобы найтииз какой верной версии.Пример строки: "somebody@example.com".

  • Если я перейду к https://www.urlencoder.org/ и попытаюсь закодировать вышеуказанную строку, я получу кого-то% 40example.com

  • Если я использую org.springframework.web.util.UriUtils Я получаю следующие результаты:

    String s1 = UriUtils.encodePathSegment("someone@example.com", "UTF-8"); String s2 = UriUtils.encodeQueryParam("someone@example.com", "UTF-8"); String s3 = UriUtils.encodePath("someone@example.com", "UTF-8"); System.out.println("----------s1: " + s1); System.out.println("----------s2: " + s2); System.out.println("----------s3: " + s3);

... выходные данные 

----------s1: someone@example.com
----------s2: someone@example.com
----------s3: someone@example.com
  • RestEasy-Client v4.0.0.Final не кодирует символ «@» в сегментах пути
  • WSO2 ESB жалуется при получении параметра Path, содержащего @ char (ну, в данный момент он не может найти ресурс).

Кто прав, каким должен быть правильный результат, следует ли преобразовать "@" в "% 40" или нет?

Ответы [ 2 ]

1 голос
/ 07 июня 2019

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

Стандарт, для которого символы должны быть экранированы в сегменте пути: RFC 3986, Приложение A . 

path          = path-abempty    ; begins with "/" or is empty
              / path-absolute   ; begins with "/" but not "//"
              / path-noscheme   ; begins with a non-colon segment
              / path-rootless   ; begins with a segment
              / path-empty      ; zero characters

path-abempty  = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty    = 0<pchar>

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

segment       = *pchar
segment-nz    = 1*pchar
segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / "@" )
              ; non-zero-length segment without any colon ":"

но ... 

pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"

Так что @ разрешен в любом сегменте пути.

Это требуется? Насколько я могу судить, ответ - нет - использование pct-кодированного представления вместо этого разрешено, когда @ не выполняет роль разделителя. Там нет ничего явного, но это наблюдение о незарезервированных символах является подсказкой:

При разыменовании URI компоненты и подкомпоненты, имеющие значение для процесса разыменования для конкретной схемы (если есть), должны быть проанализированы и разделены, прежде чем октеты в этих компонентах, закодированные в процентах, могут быть безопасно декодированы, так как в противном случае данные могут быть ошибочно принят за разделители компонентов. Единственное исключение - октеты с кодированием в процентах, соответствующие символам в незарезервированном наборе, которые могут быть декодированы в любое время. Например, октет, соответствующий символу тильды ("~"), часто кодируется как "% 7E" в более старых реализациях обработки URI; «% 7E» можно заменить на «~» без изменения его интерпретации.

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

Для справки: незарезервированный набор - это почти то, что вы ожидаете. 

unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
0 голосов
/ 07 июня 2019

Если вы называете URL-адрес типа login(:password)@url.com, он соединит вас с этой конечной точкой с вашими учетными данными. Так что я бы не избежал их в этот момент. Но если они появятся после .com, я бы избежал их, потому что их не следует использовать в качестве разделителя.

...