一个潜在的危险请求。从客户端检测到路径值(*)

我收到了一个不言自明的错误:

一个潜在的危险请求。日志含义从客户端检测到路径值(*)。

问题是由于请求URL中的*:

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

该url用于填充搜索页面，其中“test*”是搜索词，url的其余部分与各种其他过滤器相关。

是否有一种简单的方法允许这些特殊字符出现在URL中?我尝试过修改web.config，但没有用。

我应该手动编码/解码特殊字符吗? 或者是否有这样做的最佳实践，我希望避免使用查询字符串。-但这可能是一个选项

应用程序本身是一个c# asp.net webforms应用程序，它使用路由来生成上面漂亮的URL。

383435 次浏览
小开

您应该对路由值进行编码，然后(如果需要的话)在搜索之前解码该值。

小开
最佳答案

*字符不允许出现在URL的路径中，但在查询字符串中使用它没有问题:

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

这不是编码问题，*字符在URL中没有特殊含义，所以URL是否对它编码并不重要。您需要使用不同的方案对其进行编码，然后对其进行解码。

例如，使用任意字符作为转义字符:

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

和解码:

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

如果你使用的是。net 4.0，你应该能够通过web.config允许这些url

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

注意，我刚刚删除了星号(*)，原始的默认字符串是:

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

更多细节参见这个问题。

小开

这个异常发生在我的应用程序中，相当容易引起误解。

当我使用ajax方法调用一个.aspx页面Web方法，传递一个JSON数组对象时，它被抛出。Web Page方法签名包含一个强类型的. net对象OrderDetails数组。 Actual_Qty属性被定义为int, JSON对象Actual_Qty属性包含“4”(额外的空格字符)。 在移除多余的空间后，转换就成为可能，ajax调用成功到达Web Page方法
小开

当处理统一资源定位符(URL)时，有一些语法标准，在这种特殊情况下，我们处理的是保留字符。

在RFC 3986之前，保留字符可以(也可以不)由通用语法、每个特定于方案的语法或URI的解引用算法的特定于实现的语法定义为分隔符;星号(*)是保留字符。

最好的做法是在url中使用无限制的字符，或者你可以尝试对它进行编码。

继续挖掘:

小开

尝试将web项目的服务器属性设置为本地IIS，如果它是IIS Express。确认项目url是否正确，并创建虚拟目录。

小开
对于我来说，我正在使用。net 4.5.2和web api 2.0， 我有同样的错误，我设置它只是通过添加requestPathInvalidCharacters="" 在requestPathInvalidCharacters中，你必须设置不允许的字符，否则你必须删除导致这个问题的字符。< / p > 
<system.web>
<httpRuntime targetFramework="4.5.2" requestPathInvalidCharacters="" />
<pages  >
<namespaces>
....
</namespaces>
</pages>
</system.web>
**注意这不是一个好的做法，可能一个post用这个参数作为对象属性更好或者尝试编码特殊字符。 ——在搜索rest api的最佳实践后，我发现在搜索、排序和分页中，我们必须像这样处理查询参数

/companies?search=Digital%26Mckinsey

这解决了当我们编码&并将其替换为url上的%26 无论如何，在服务器上我们接收到正确的参数Digital&Mckinsey

这个链接可能有助于设计rest web API的最佳实践 https://hackernoon.com/restful-api-designing-guidelines-the-best-practices-60e1d954e7c9 < / p >

小开

对我来说，当输入url时，一个用户不小心用了/而不是?命令，启动查询参数

例如:

url.com/endpoint/parameter = SomeValue& otherparameter =另一个+价值

应该是:

url.com/endpoint ?参数= SomeValue& otherparameter =另一个+价值

小开

我在Azure数据工厂中遇到了类似的:字符问题。

我解决了这个问题用%3A代替

如在这里所示。

比如，我代入了

date1=2020-01-25T00:00:00.000Z

与

date1=2020-01-25T00%3A00%3A00.000Z

提交答案