WebAPI调试与发布模式下带编码空格请求返回结果不一致

这个差异的核心在于IIS（发布环境）和IIS Express（调试环境）对URL的规范化与请求过滤行为不一致，具体拆解为以下几点：

1. IIS自动对URL做规范化处理 #

默认情况下，IIS会启用URL规范化模块，它会对传入的URL做一系列标准化处理，其中就包括：

• 将编码的空格（%20）解码为普通空格
• 自动移除URL路径末尾的空格（包括解码后的空格）

所以当你在发布环境请求https://localhost/test/api/objects/123456%20时，IIS会先把这个URL规范化为https://localhost/test/api/objects/123456，再把请求转发给你的Web API。此时你的API接收到的identification参数是123456，自然能匹配到数据，返回200 OK和对应的对象信息。

2. IIS Express默认未启用相同的URL规范化规则 #

调试时使用的IIS Express，默认没有开启和IIS完全一致的URL规范化逻辑。更关键的是：
IIS Express默认的请求过滤规则会拦截包含末尾编码空格的请求，直接返回IIS自带的“无法找到资源”404页面，根本没让请求到达你的Web API代码。这就是为什么调试时你看不到API返回的JSON，而是得到一个HTML格式的404。

3. 额外：你的API代码可能存在隐式的Trim处理 #

从发布环境返回的{"objectIdentification": "123456"}来看，即使IIS没有完全移除空格，你的后端代码可能也对identification参数做了Trim()之类的处理，把末尾的空格去掉后找到了对应的数据，所以返回了200状态码和正确的对象。

如果你想让调试和发布环境的行为一致，可以做以下操作：

• 统一URL规范化规则：在Web.config中添加URL重写规则，强制对URL进行规范化（比如移除末尾空格/编码空格），让IIS Express和IIS行为一致。示例规则：

<system.webServer>
  <rewrite>
    <rules>
      <rule name="Remove Trailing Spaces" stopProcessing="true">
        <match url="^(.*)\s+$" />
        <action type="Redirect" url="{R:1}" redirectType="Permanent" />
      </rule>
      <rule name="Decode and Remove Trailing Spaces" stopProcessing="true">
        <match url="^(.*)%20+$" />
        <action type="Redirect" url="{R:1}" redirectType="Permanent" />
      </rule>
    </rules>
  </rewrite>
</system.webServer>

• 调整IIS Express的请求过滤：修改IIS Express的applicationhost.config文件（通常在Documents\IISExpress\config下），确保允许包含%20的URL路径，让请求能到达你的API代码，这样你就能在调试时看到API的实际处理结果。

内容的提问来源于stack exchange，提问作者Sergeant McFuzzyboots