Потенциально опасное значение Request.Path было обнаружено у клиента (*)

Я получаю довольно объяснительную ошибку:

Потенциально опасное значение Request.Path было обнаружено у клиента (*).

Проблема связана с * в URL-адресе запроса:

https://stackoverflow.com/Search/test*/0/1/10/1

Этот URL-адрес используется для заполнения страницы поиска, где "test *" - это поисковый запрос, а остальная часть URL-адреса относится к различным другим фильтрам.

Есть ли простой способ разрешить эти специальные символы в URL? Я пробовал модифицировать web.config, но безрезультатно.

Должен ли я вручную кодировать/декодировать специальные символы? Или есть лучшая практика для этого, я хотел бы избежать использования строк запроса. - но это может быть вариант.

Само приложение является приложением c# asp.net webforms, которое использует маршрутизацию для создания хорошего URL-адреса выше.

Ответ 1

Символу * не разрешен путь к URL-адресу, но нет проблемы с его использованием в строке запроса:

http://localhost:3286/Search/?q=test*

Это не проблема с кодировкой, символ * не имеет особого значения в URL-адресе, поэтому не имеет значения, закодирован ли вам URL-адрес. Вам нужно будет закодировать его, используя другую схему, а затем декодировать его.

Например, используя произвольный символ как escape-символ:

query = query.Replace("x", "xxx").Replace("y", "xxy").Replace("*", "xyy");

И декодирование:

query = query.Replace("xyy", "*").Replace("xxy", "y").Replace("xxx", "x");

Ответ 2

Если вы используете .NET 4.0, вы можете разрешить эти URL через web.config

<system.web>
    <httpRuntime 
            requestPathInvalidCharacters="&lt;,&gt;,%,&amp;,:,\,?" />
</system.web>

Обратите внимание, я только что удалил звездочку (*), исходная строка по умолчанию:

<httpRuntime 
          requestPathInvalidCharacters="&lt;,&gt;,*,%,&amp;,:,\,?" />

Смотрите этот вопрос для более подробной информации.

Ответ 3

Вы должны закодировать значение маршрута, а затем (при необходимости) декодировать значение перед поиском.

Ответ 4

Для меня я работаю над.net 4.5.2 с web api 2.0, у меня такая же ошибка, я устанавливаю его просто путем добавления requestPathInvalidCharacters = "" в параметрах requestPathInvalidCharacters, которые вы должны установить недопустимыми символами, еще вам нужно удалить символы, которые вызывают эту проблему.

<system.web>
     <httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
     <pages  >
      <namespaces>
     ....
 </namespaces>
    </pages> 
  </system.web>

** Обратите внимание, что это не очень хорошая практика, может быть сообщение с этим параметром, поскольку атрибут объекта лучше или попытаться кодировать специальный символ. - После поиска лучшей практики для проектирования rest api, я обнаружил, что в поиске, сортировке и paginnation мы должны обрабатывать параметр запроса, как это

/companies?search=Digital%26Mckinsey

и это решает проблему, когда мы кодируем & и заменяем его на URL% 26 любым способом, на сервере мы получаем правильный параметр Digital & Mckinsey

эта ссылка может помочь в передовом опыте проектирования сайта для отдыха. api https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9

Ответ 5

Это исключение произошло в моем приложении и было довольно ошибочным.

Он был брошен, когда я вызывал веб-метод .aspx-страницы, используя вызов метода ajax, передавая объект массива JSON. Подпись Web-страницы содержала массив строго типизированного объекта .NET, OrderDetails. Свойство Actual_Qty было определено как int, а свойство Actual_Qty объекта JSON содержало "4" (дополнительный пробел). После удаления дополнительного места преобразование стало возможным, метод веб-страницы был успешно достигнут вызовом ajax.

Ответ 6

При работе с Uniform Resource Locator (URL) существуют определенные стандарты синтаксиса, в этой конкретной ситуации мы имеем дело с зарезервированными символами.

Что касается RFC 3986, зарезервированные символы могут (или не могут) определяться как разделители по общему синтаксису, по каждому синтаксису, специфичному для схемы, или специфически для реализации синтаксиса алгоритма разыменования URI; А звездочка (*) - это зарезервированный символ.

Рекомендуется использовать незарезервированные символы в URL-адресах или попытаться их кодировать.

Продолжай копать:

Ответ 7

Попробуйте установить сервер веб-проектов как локальный IIS, если это IIS Express. Убедитесь, что правильный URL проекта и создайте каталог virual.

Ответ 8

Для меня при вводе URL пользователь случайно использовал/вместо? запустить параметры запроса

например.:

url.com/endpoint/parameter=SomeValue&otherparameter=Another+value

который должен был быть:

url.com/endpoint?parameter=SomeValue&otherparameter=Another+value