404 Error in IIS 7 when using a Url with a plus (+) sign in the path

本文探讨了IIS7中使用含有加号(+)的URL路径时出现404错误的问题。该错误源于IIS7对URL标准的严格实施。文章详细解释了错误产生的原因,并提供了一种短期解决方案,即通过修改web.config文件来禁用双重转义验证。

http://www.ifinity.com.au/Blog/EntryId/60/404-Error-in-IIS-7-when-using-a-Url-with-a-plus-sign-in-the-path

I recently had reported problems when using IIS7 that Urls with a + in the url were failing with 404 errors.  This was to do with the Url Master module, which often rewrites Urls to use a simple space encoding (+) rather than the messy (but still valid) %20 encoding.   Normally this is where you have a DNN module that uses a querystring value, where the querystring value gets incorporated into the path of the Url via Friendly Url generation.

As is often the case with errors, I have never heard of them and then within a week I'll get several reports of the same error, even when a particular problem has been 'in the wild' for a long period of time.  It's like the progression of systems across new technologies happens at a steady rate, so that very few people are a long way ahead and trying new things.

The problem occurs in Urls like this : www.mysite.com/my-page-name/key/value+with+spaces.aspx

This Url would be rewritten to this value : www.mysite.com/default.aspx?key=value+with+spaces

Note that with the Url Master module, while it can replace spaces in DotNetNuke page names to construct human friendly urls, it doesn't replace spaces in querystring values.  This is because the module waiting for the rewritten query string might not be expecting a change in the value, and you can't just stick hyphens in where a space is, and then remove them again.   If you did that, you'd eventually run into a case where a legitimate hyphen was removed from the query string.

Example of the Problem

To clarify the problem further, here's an example of how the problem shows up.  It involves two of my modules, the iFinity Tagger and the Url Master modules.

The Tagger module shows a listing of all tagged items when the Tag is requested in the query string, like this :

mysite.com/Tag-List/two+word+tag/

The '+' in the url is put there by the Url Master module, to make the Url look nice and simple, rather than the correct but frantically ugly:

mysite.com/Tag-List/two%20word%20tag/

If you're running your DotNetNuke install (or any asp.net application, for that matter) on IIS7, then you'll get an IIS 404.

Why get 404 errors with +?

The reason that this doesn't work on IIS 7.0 is that Microsoft decided to tighten up on what's legal and what's not, and implement the Url standards more strictly, for security reasons.

Solution to the Problem

The long term solution is to include a choice of space-encoding in the relevant modules, but that will take some time to implement.

The short term solution is from this blog posting:

IIS 7.0 Breaking changes for ASP.NET 2.0 applications in Integrated Mode

Here's the relevant excerpt from the page, which shows the workaround/fix.

Request limits and URL processing

The following changes result due to additional restrictions on how IIS processes incoming requests and their URLs.

11) Request URLs containing unencoded “+” characters in the path (not querystring) is rejected by default

You will receive HTTP Error 404.11 – Not Found: The request filtering module is configured to deny a request that contains a double escape sequence .

This error occurs because IIS is by default configured to reject attempts to doubly-encode a URL, which commonly represent an attempt to execute a canonicalization attack.

Workaround :

1) Applications that require the use of the “+” character in the URL path can disable this validation by setting the allowDoubleEscaping attribute in the system.webServer/security/requestFiltering configuration section in the application’s web.config.  However, this may make your application more vulnerable to malicious URLs:

<system.webServer>

    <security>

            <requestFiltering allowDoubleEscaping="true" />

    </security>

</system.webServer>

内容概要:本文介绍了一个针对电力系统连锁故障传播路径的N-k多阶段双层优化及故障场景筛选模型,该模型基于混合整数线性规划(MILP)方法构建,旨在全面评估电力系统在遭受多重故障时的脆弱性与恢复能力。通过引入故障传播路径的概念,模型能够动态模拟故障在电网中的逐级扩散过程,并结合多阶段优化策略,实现对关键故障场景的有效识别与优先排序。整个框架不仅考虑了初始故障元件的选取,还涵盖了后续因潮流转移引发的级联跳闸行为,从而提升了风险评估的准确性与时效性。该研究已在Matlab平台上完成代码实现,具备良好的可复现性和工程应用价值,适用于提升现代电网的安全防御水平。; 适合人群:电力系统、能源安全及相关领域的科研人员、高校研究生以及从事电网规划与运行管理的工程技术人员。; 使用场景及目标:①用于电力系统安全评估中识别最危险的N-k故障组合;②支撑电网应急预案制定与薄弱环节改造;③作为学术研究中关于级联故障建模与优化求解的教学与验证工具;④服务于智能电网背景下抵御蓄意攻击或极端事件的风险防控决策。; 阅读建议:建议读者结合Matlab代码深入理解模型的数学 formulation 与求解流程,重点关注目标函数设计、约束条件构建及双层优化结构的实现逻辑,同时可通过调整系统参数和故障设定进行仿真对比分析,以掌握不同因素对连锁故障演化的影响规律。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值