C# 损坏的查询字符串："；80“；正在被IIS删除？

我已经和这个问题斗争了几天，但似乎不知道是什么原因造成的

我有一个需要激活的注册系统。当用户单击激活链接时，会向用户发送一封带有哈希的电子邮件，该哈希会传回服务器。非常基本的东西。该链接类似于以下内容：

http://site/activate.aspx?activationKey=26a51d9eba86c73b8f7e800c41bf55453ed3b1c4

在我的本地机器（运行VS2010）上进行开发时，它可以完美地工作。但是，当站点被推送到实时服务器（IIS 6）时，查询字符串可能被IIS损坏。一旦查询字符串命中后面的代码，任何出现的“80”都会被删除，导致激活失败

---

我想知道这是否是一个编码/解码问题，但没有一个字符是特殊的，因此我认为不应该是这种情况。

在网站上打开trace.axd并检查发送的值。您确定电子邮件客户端没有执行任何操作吗？我知道，IIS默认情况下不会从查询字符串中删除80。我已经在我的网站上的QueryString中使用过很多次，没有任何问题

查看IIS中的url重写规则。我不确定IIS日志是否使用最终url或IIS之前的url。但考虑到它是80，我想有人想从URL中删除端口80，但为此添加了错误的重写规则

---

所以我会寻找一个地方，有人可以尝试从URL中剥离端口80。可能位于IIS或上游

嗯，我发现了问题所在@pst和@Mikael Eliasson是对的，从某种意义上说，一些暴徒确实制定了一些重写规则

通过重定向403，站点被迫进入SSL；4另一个（预先存在的）应用程序将URL重写为使用HTTPS时出错。从某种意义上说，你可以在一个应用程序上强制使用SSL，其余的都是（破坏的）魔法。以下是原始代码：

if ( Request.ServerVariables[ "SERVER_PORT" ] == "80" ) {
    try {
        string queryString, secureURL;

        queryString = Request.Url.AbsoluteUri.ToString();
        queryString = Request.ServerVariables[ "QUERY_STRING" ];
        Response.Write( queryString + "<br>" );

        secureURL = queryString.Replace( "http", "https" );
        secureURL = secureURL.Replace( "403;", "" );
        secureURL = secureURL.Replace( "80", "" );

        Response.Write( secureURL );
        Response.Redirect( secureURL );
    }
    catch ( Exception ex ) {
    }
}

if（Request.ServerVariables[“SERVER\u PORT”]=“80”）{
试一试{
字符串查询字符串，secureURL；
queryString=Request.Url.AbsoluteUri.ToString（）；
queryString=Request.ServerVariables[“QUERY_STRING”]；
Response.Write（queryString+“
”）；
secureURL=queryString.Replace（“http”、“https”）；
secureURL=secureURL.Replace（“403；”，“”）；
secureURL=secureURL.Replace（“80”，替换为“”）；
Response.Write（secureURL）；
重定向（secureURL）；
}
捕获（例外情况除外）{
}
}

请注意其中“80”的残酷替换。将替换项更改为“：80”可以解决问题，假设我没有传递包含“：80”的查询字符串，我不会这样做

---

感谢你们至少为我指出了正确的方向，伙计们。

是否有管理员或认为自己应该成为管理员的人留下的“重写”信息？（可能是在某些错误的尝试中删除端口号…）这两个服务器之间是否有代理服务器？IIS如何显示日志中的完整请求？如果“80”是路径本身的一部分（不是查询字符串），会发生什么情况？您确定没有在某个地方弄乱查询字符串吗？被遗忘的处理者？没有任何“标准”会像所描述的那样被破坏。与其在VS2010提供的Web服务器上测试，不如尝试IIS本身。为了进行调试，请连接到w3wp.exe，这是通过挖掘IIS日志获得的。你发现了什么。同样，这里是原始查询：

Activate.aspx？activationKey=26A51D9EBA86C73B8F7E800C41BF5553ED3B1C4

，它在IIS日志中显示为：

Activate.aspx？activationKey=26A51D9EBA86C73B8F7E0C41BF5553ED3B1C4

注意“80”已经消失了。现在，考虑到我是一个Linux人（IIS对我来说有点陌生），如果它像那样出现在日志中，它是在进入IIS之前还是之后被修改的？换句话说，IIS中的某些设置不会导致这种情况，这是在它到达IIS之前发生的。您可能需要安装

Wireshark

，并查看数据包请求（您可能需要针对本地pc以外的其他设备运行以进行测试）。我计划今天对Wireshark进行更多调查。昨晚我更关心的是为这个问题创建一个解决方案，因为它是在一个生产服务器上。我曾在多个地方尝试过（在多个浏览器中使用Gmail、Outlook，并将URL直接粘贴到地址栏中）。它仍然在我的开发机器上完美地工作，所以我认为它必须在生产服务器上。