Допустима строка запроса с / в?
Из-за недопонимания с партнерским партнером мы работаем с URL, который они называют на нашем сервере, были перепутаны.
Это URL, который они должны вызывать на нашем сервере:
/AAAAAAAA/?b=CCCCCCC
к сожалению, это было реализовано в их системе, как это
?b=CCCCCCC/AAAAAAA
Я могу легко разобрать компоненты, но я боюсь, что параметр строки запроса с / в нем на самом деле не является действительным URL.
Является ли / в URL действительно допустимым - или я должен быть обеспокоен. При каких обстоятельствах может быть незакодировано / вызвать проблемы в строке запроса.
3 ответа
Хотя у меня никогда не было проблем, они технически не разрешены согласно RFC 2396:
Внутри компонента запроса символы ";", "/", "?", ":", "@", "&", "=", "+", "," И "$" зарезервированы.
Но, как я уже сказал... Я никогда не сталкивался с какими-либо проблемами. Я думаю, что это проблема со старыми браузерами больше всего, но, может быть, кто-то может пролить немного света на проблему, которую это вызывает?
Согласно RFC 3986: унифицированный идентификатор ресурса (URI): общий синтаксис (с 2005 года), да, / разрешено в компоненте запроса. Это BNF для строки запроса: (в Приложении A в RFC 3986)
query = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
В спецификации сказано:
- Косая черта ("/") и знак вопроса ("?") Могут представлять данные в компоненте запроса.
- поскольку компоненты запроса часто используются для передачи идентифицирующей информации в виде пар "ключ = значение", а одно часто используемое значение является ссылкой на другой URI, иногда для удобства использования иногда лучше избегать процентного кодирования этих символов
Вот связанный вопрос: Строка запроса: может ли строка запроса содержать URL-адрес, который также содержит строки запроса?
Косая черта - это "зарезервированный символ" в части запроса URL-адреса согласно разделу 3.4 RFC 2396, поэтому согласно разделу 2.2 он должен быть закодирован. То есть часть запроса может содержать %2F но не должен содержать /,