在IIS执行非法字符替换吗？如果是这样，如何​​阻止它？ [英] Is IIS performing an illegal character substitution? If so, how to stop it?

问题描述

上下文：ASP.NET MVC在IIS中运行，有一个UTF-8％烯codeD网址

使用标准的项目模板和测试行动的HomeController 这样的：

 公众的ActionResult测试（字符串ID）
{
    返回内容（ID，text / plain的）;
}
 

这工作正常大多数％克斯codeD UTF-8路线，如：

 的http：// mydevserver /首页/测试/％E4％BA％AC％E9％83％BD％E5％BC％81
 

与预期的结果京都弁

不过使用路线：

 的http：// mydevserver /首页/测试/％ee的％93％BB
 

该URL的不的正确接收。

旁白：％EE％93％BB 是％克斯codeD code点0xE4FB;基本-多语种平面，私人使用面积;但最终 - 一个有效的UNI code code点;您也可以手动验证这一点，或者通过：

 字符串值=（（char）的0xE4FB）的ToString（）;
字符串连接codeD = HttpUtility.UrlEn code（值）; //％EE％93％BB
 

现在，接下来发生的事情取决于Web服务器上;在Visual Studio开发服务器（又称卡西尼）上，正确的 ID 接收 - 一个长度的字符串，包含code点0xE4FB

。

但是，如果我这样做在IIS或IIS防爆preSS，我得到一个不同的 ID ，具体I» ，code点：0xEE，0x201C，为0xBB。你会立即承认第一个和最后作为我们百分之恩codeD字符串的开始和结束......还等什么，中间发生了什么？

好

• code点0x93为（source ）


• code点0x201c是（source ）

在我看来非常像IIS处理我的网址时，已执行某种报价翻译的。现在，也许这可能有几个方案用途（我不知道），但它肯定是一件坏事，当它在％克斯codeD中间发生的UTF-8块。

注意 HttpContext.Current.Request.Raw 同时显示了这种转换已经发生，所以这看起来并不像一个MVC的bug;还要注意达林的评论，强调它的工作方式不同路径VS URL的查询部分。

所以（两个舞伴）：

1. 是我的分析缺少UNI code / URL处理一些重要的细微之处？


2. 如何解决呢？ （即让这个我收到预期的字符）

解决方案

最后，要解决这个问题，我不得不使用 request.ServerVariables [HTTP_URL] 和一些手工解析，带着一帮错误处理回退的（另外在乌里补偿一些相关的故障）。不是很大，但只影响别扭请求的极少数。

Context: ASP.NET MVC running in IIS, with a a UTF-8 %-encoded URL.

Using the standard project template, and a test-action in HomeController like:

public ActionResult Test(string id)
{
    return Content(id, "text/plain");
}

This works fine for most %-encoded UTF-8 routes, such as:

http://mydevserver/Home/Test/%e4%ba%ac%e9%83%bd%e5%bc%81

with the expected result 京都弁

However using the route:

http://mydevserver/Home/Test/%ee%93%bb

the url is not received correctly.

Aside: %ee%93%bb is %-encoded code-point 0xE4FB; basic-multilingual-plane, private-use area; but ultimately - a valid unicode code-point; you can verify this manually, or via:

string value = ((char) 0xE4FB).ToString();
string encoded = HttpUtility.UrlEncode(value); // %ee%93%bb

Now, what happens next depends on the web-server; on the Visual Studio Development Server (aka cassini), the correct id is received - a string of length one, containing code-point 0xE4FB.

If, however, I do this in IIS or IIS Express, I get a different id, specifically "î"»", code-points: 0xEE, 0x201C, 0xBB. You will immediately recognise the first and last as the start and end of our percent-encoded string... so what happened in the middle?

Well:

• code-point 0x93 is " (source)
• code-point 0x201c is " (source)

It looks to me very much like IIS has performed some kind of quote-translation when processing my url. Now maybe this might have uses in a few scenarios (I don't know), but it is certainly a bad thing when it happens in the middle of a %-encoded UTF-8 block.

Note that HttpContext.Current.Request.Raw also shows this translation has occurred, so this does not look like an MVC bug; note also Darin's comment, highlighting that it works differently in the path vs query portion of the url.

So (two-parter):

1. is my analysis missing some important subtlety of unicode / url processing?
2. how do I fix it? (i.e. make it so that I receive the expected character)

解决方案

Ultimately, to get around this, I had to use request.ServerVariables["HTTP_URL"] and some manual parsing, with a bunch of error-handling fallbacks (additionally compensating for some related glitches in Uri). Not great, but only affects a tiny minority of awkward requests.

这篇关于在IIS执行非法字符替换吗？如果是这样，如何​​阻止它？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！