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

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




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




проблема из-за * в URL запроса:



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


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



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



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



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

690   7  

7 ответов:

The * символ не допускается в пути 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");
88  
2012-11-08 23:09:52

Если вы используете .NET 4.0, вы должны иметь возможность разрешить эти URL-адреса через интернет.конфигурации

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

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

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

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

279  
2017-05-23 13:31:30

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

4  
2011-05-11 18:54:23

при работе с Uniform Resource Locator (URL) s есть определенные стандарты синтаксис в данной конкретной ситуации мы имеем дело с Зарезервированные Символы.

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

лучше всего использовать Незарезервированных Символов в URL-адресах или вы можете попробовать кодировать его с помощью java.net.URLEncoder.

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

1  
2017-05-23 13:31:30

для меня, я работаю на .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, я обнаружил, что в поиске, сортировке и разбивке на страницы мы должны обрабатывать параметр запроса следующим образом

/companies?search=Digital%26Mckinsey

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

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

1  
2018-03-28 12:32:57

это исключение произошло в моем приложении и было довольно вводящим в заблуждение.

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

0  
2016-04-05 17:07:48

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

0  
2017-05-03 16:49:50

Comments

    Ничего не найдено.
Click here to cancel reply.