Использование двоеточия (:) в URL с ASP.NET/IIS

Я реализую собственный контроллер в ASP.NET MVC и действительно хочу иметь возможность использовать двоеточие в URL, чтобы я мог идентифицировать имена классов / столбцов и их значения, например, так:

http://example.com/user:chaiguy

... но, очевидно, ASP.NET или IIS не допускают двоеточия в URL. Я немного покопался и, по-видимому, это считается проблемой безопасности, но я использую MVC и обрабатываю все URL-пути вручную (просто обрабатываю их как строки), а не связываю их с файловой системой, поэтому я уверен, что это не применяется

Я также слышал разговоры о реализации собственного обработчика Http или чего-то еще.

Любые мысли или идеи будут высоко ценится.

Э-э... почему? Серьезно, зачем нарушать стандарты? - Рандольфо

...

Я предлагаю вам исследовать создание веб-службы. WCF - хорошая технология для этого, и она хорошо работает в IIS.

Мне нравится URL, и WCF слишком сложен для моих целей. Я хочу, чтобы он был совместим с url, как REST, но мог бы больше, чем просто перемещаться по иерархии или делать хорошо продуманные вещи. Проблема, с которой я столкнулся с /users/chaiguy, заключается в том, что она интерпретирует иерархию там, где ее нет: в моей системе "пользователь" - это класс, а не папка. user: chaiguy означает экземпляр пользовательского класса со значением "chaiguy", и это единственная сущность, которая может иметь дочерние сущности. Так, например:

/user:chaiguy/name

... Я хотел бы отобразить имя этого лица. Если бы я сделал это с вашим методом, это выглядело бы так:

/users/chaiguy/name

Проблема в том, как узнать, что это за класс и какова его ценность? Это можно интерпретировать как

/users/chaiguy:name

в моей системе, и это не имеет смысла. Видишь, к чему я клоню? Чтобы привести немного более сложный пример, предположим, что мы хотим выбрать дочерний элемент пользовательского объекта из нескольких экземпляров. Таким образом, у пользователя может быть несколько адресов электронной почты. Чтобы выбрать один, мы могли бы использовать:

/user:chaiguy/email:me@here.com/

Так что это на самом деле рекурсивно. Это не путь к файлу, это больше похоже на XPath (или, может быть, похоже на jQuery, основываясь на том, что я пока мало о нем знаю). То есть это скорее динамически выбираемый выбор запроса, чем жестко заданный путь к файлу. Он оценивается на сервере.

Не заблуждайтесь, я не создаю типичный веб-сайт или даже веб-сервис здесь.

Источник

8 ответов

Изменить requestPathInvalidCharacters атрибут httpRuntime в web.config:

<httpRuntime maxRequestLength="20480" requestValidationMode="2.0" requestPathInvalidCharacters="" maxQueryStringLength="20480" />

и ASP.NET больше не должен блокировать двоеточия из вашего пути запроса.

Источник

Ответил на аналогичный вопрос здесь: /questions/13104425/dvoetochie-v-kodirovke-url-razreshaetsya-v-400-nevernyih-zaprosah/13104429#13104429

Похоже, что ASP.net не разрешает двоеточия до "?" в URL, даже если он закодирован как%3A.

Например, они не будут работать:

http://foo.org/api/persons/foo:bar

http://foo.org/api/persons/foo%3Abar

Но это работает:

http://foo.org/api/persons?id=foo%3Abar

Во всех примерах мы ожидаем, что ASP.NET MVC передаст "foo:bar" в качестве аргумента id, правильно декодированного. Я только что проверил это с MVC4, и это похоже на работу. Досадно, что он не принимает кодировку URL до вопросительного знака, но я уверен, что для этого есть веская причина. Вероятно, чтобы все оставалось до вопросительного знака, действительный URL и любые аргументы после вопросительного знака.

Источник

Попробуйте установить HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters\AllowRestrictedChars. Это с http://support.microsoft.com/?id=820129. Я не знаю, выполняет ли ASP.NET/MVC некоторую проверку самостоятельно, но если это блокирует только http.sys, это должно исправить это.

Источник

Этот параметр web.config работал для меня. Он принимает двоеточия (:) в URL.

<httpRuntime targetFramework="4.6.1" requestPathInvalidCharacters=""/>
Источник

Я предлагаю вам переосмыслить то, что вы хотите сделать. Используйте пути для указания контекста и скрытия имен классов и полей, сопоставляя конкретные контексты в ваших путях URL с именами и полями классов. Если вам нужно указать пользователя, например, создайте свой макет URL, как example.com/users/chaiguy скорее, чем example.com/user:chaiguy,

Источник

На самом деле доступен WCF REST, и вы можете легко приступить к работе в течение часа с помощью начального набора WCF, доступного здесь. Это берет силу REST и объединяет ее с легкостью WCF. Также с WCF вы также можете создать свой собственный транспортный уровень, если вам нужно, чтобы он мог интерпретировать URL-адреса любым удобным для вас способом. Одна интересная вещь в стартовом наборе состоит в том, что он разрешил пробелы в Url, что на самом деле вызывало некоторые головные боли у настоящих REST fundi.

Я не хотел смотреть на это из-за WCF, но вам действительно не нужно знать так много. Решение создает все, что вам нужно, просто добавьте код.

Источник

Я бы предложил использовать точку. REST, основанный на протоколе HTTP, является примером построения нового использования HTTP, которое соответствовало стандартам и было очень успешным. Возможно, вы можете сделать это.

И "." является стандартным "class.method" или "class.attribute" во многих языках.

Теперь, ME, я хотел использовать двоеточие во временных параметрах URL, и некоторые места делают это. Я все еще должен увидеть, смогу ли я сойти с рук.

PS, для меня, я могу использовать это: http://www.businesscasualblog.com/2009/07/how-to-share-a-link-to-a-specific-timecode-in-youtube-video.html

по существу "- ч - м - с"

Источник

Допустимо ли двоеточие в URL? Краткий ответ нет.

Длинный ответ, да, если это фрагмент URL.

Пример: http://site/gwturl#user:45/comments (обратите внимание, что двоеточие переходит к хеш-тегу)

источники

Источник
Другие вопросы по тегам