Могу ли я использовать запятые в URL?

Question

Я обычно использую перезапись URL для передачи идентификаторов контента на мой веб-сайт, так что

 Foo.1.aspx 

переписывает на

 Foo.aspx?id=1

Для конкретного приложения мне нужно передать несколько идентификаторов на одну страницу, поэтому я переписал вещи, чтобы принять это:

 Foo.1,2,3,4,5.aspx

Это прекрасно работает в Cassini (встроенный специальный веб-сервер для Visual Studio), но дает мне «Internet Explorer не может отобразить веб-страницу», когда я пробую его на живом сервере с IIS. Это ограничение IIS? Должен ли я просто использовать тире или подчеркивание вместо запятых?

Answer 1

Запятые разрешены в части имени файла URL, но, насколько мне известно, являются зарезервированными символами в домене *.

Какую версию IE вы используете? Я наткнулся на странный отчет об усеченных URL-адресах в IE5.5 через запятую ( ссылка здесь ), но я проверил URL-адреса с запятыми в IE7, и, похоже, все в порядке, так что если была ошибка IE, похоже, его там больше нет - может ли это быть проблема IIS?

Мне интересно, связана ли ошибка страницы с ошибкой правила с mod_rewrite - вы можете опубликовать правило, совпадающее с несколькими идентификаторами, и передать их вашему Foo.aspx? Есть ли вероятность того, что он соответствует только Foo.N,N и не содержит больше запятых?

---

* Из URI RFC :

2,2. Зарезервированные персонажи

Многие URI включают компоненты, состоящие из или разделенные определенным специальные символы. Эти символы называются «зарезервированными», так как их использование в компоненте URI ограничено их зарезервированным цель. Если данные для компонента URI будут конфликтовать с зарезервированная цель, то конфликтующие данные должны быть экранированы до формирование URI.

 reserved    = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
                "$" | ","

Класс зарезервированного синтаксиса выше относится к тем символам, которые разрешено в URI, но не может быть разрешено в пределах конкретный компонент общего синтаксиса URI

Answer 2

Напоминаю, что Url Routing по умолчанию сначала проверяет, существует ли файл, и не заданы ли запятые в именах файлов, что, возможно, объясняет, почему вы получаете ошибки. IIS может иметь устаревший код, который прерывает запрос, прежде чем он может попасть на asp.net для обработки.

Сообщение Скотта Хансельмана в блоге немного говорит об этом и может быть актуально для вас.

---

В качестве общего комментария: перезапись URL-адреса обычно используется для того, чтобы сделать URL-адрес удобным и легким для запоминания.

~/page.aspx?id=1,2,3,4 не хуже и не лучше, чем ~/page/1-2-3-4.aspx: оба сложны в использовании, так зачем делать дополнительные усилия? Избегайте создания новых форм URL только потому, что вы можете. Пользователи, служба поддержки и другие разработчики будут просто сбиты с толку.

Перезапись URL лучше всего использовать для преобразования

~/products/view.aspx?id=1
~/products/category.aspx?type=beverage

в

~/products/view/1
~/products/category/beverage

Answer 3

Попробуйте использовать %2c в URL для замены запятых.

Answer 4

В дополнение к ответу ConroyP ниже приведена еще одна цитата к RFC. Он отмечает ряд небезопасных символов, но не упоминает запятую (предполагая, что запятая безопасна):

Символы могут быть небезопасными по ряду причин. Космос символ небезопасен, потому что значительные пробелы могут исчезнуть и незначительные пробелы могут быть введены, когда URL транскрибируются или набирают или подвергают обработке текстовые программы. Символы «<» и «>» небезопасны, поскольку они используются в качестве разделители вокруг URL в свободном тексте; знак кавычки ("" ") используется для Разделяйте URL-адреса в некоторых системах. Символ "#" небезопасен и должен всегда кодируется, потому что он используется в World Wide Web и в других системы для отделения URL-адреса от идентификатора фрагмента / якоря, который может следуй за этим. Символ "%" небезопасен, потому что он используется для кодировки других символов. Другие персонажи небезопасны, потому что Известно, что шлюзы и другие транспортные агенты иногда изменяют такие персонажи. Это символы "{", "}", "|", "\", "^", "~", "[", "]" и "` ".

Все небезопасные символы всегда должны быть закодированы в URL. За Например, символ "#" должен быть закодирован в URL даже в системы, которые обычно не имеют дело с фрагментом или якорем идентификаторы, так что если URL-адрес копируется в другую систему, которая действительно использует их, нет необходимости изменять кодировку URL.

Answer 5

Запятая допускается в пути, строке запроса и фрагменте согласно спецификации. Меня не удивит, если IE не будет соответствовать спецификации. Попробуйте сущность, как предлагает Клавдиу, но я не знаю, зачем это нужно.

Answer 6

Если бы вы установили фронт-контроллер, вы могли бы сделать что-то вроде:

index.aspx?c=Foo/1/2/3/4

Фронт-контроллер выбирает имя метода и параметры для передачи ему. В наше время это довольно распространенная техника.

Answer 7

Ответ

Проблема была в запятых. Я предполагаю, что у IIS была проблема с этим (не IE), так как IE смог нормально отобразить его на localhost.

Во всяком случае, я просто изменил формат URL на этот, и он отлично работает:

Foo.1-2-3-4-5.aspx

Answer 8

Правильный способ принять несколько идентификаторов выглядит так:

Foo.aspx?id=1;id=2;id=3;id=4;id=5

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

Мне тоже пришлось это узнать на StackOverflow. Смотрите этот вопрос:
Выделить целые из строки