ASP.NET Core Kestrel 请求头编码问题解析

在 ASP.NET Core 的 Kestrel 服务器中，处理 HTTP 请求头时存在一个值得开发者注意的编码问题。当请求头中包含非 ASCII 字符时，如果未正确配置编码方式，可能会导致服务器返回 400 Bad Request 错误。

问题现象

开发者在使用 Kestrel 服务器时发现，当 HTTP 请求头中包含特殊字符（如"Ç"）时，服务器会返回 400 错误。即使按照官方文档说明，RequestHeaderEncodingSelector 属性在返回 null 时应该默认使用 UTF-8 编码，实际行为却不符合预期。

技术背景

Kestrel 服务器内部使用严格的 UTF-8 编码验证机制。具体来说，它使用了一个特殊的 UTF8Encoding 实例，其构造函数参数设置为：

• encoderShouldEmitUTF8Identifier: false（不输出 UTF-8 标识）
• throwOnInvalidBytes: true（遇到无效字节时抛出异常）

这与标准的 Encoding.UTF8 有所不同，后者在遇到无效字节时会进行替换而不是抛出异常。

问题根源

问题的核心在于字符编码的差异。以"Ç"字符为例：

• Unicode 形式是单字节 199
• UTF-8 编码形式是双字节 195 135

当客户端发送的是 Unicode 形式的"Ç"（单字节 199）时，Kestrel 的严格 UTF-8 验证会将其视为无效字节而拒绝请求。

解决方案

针对不同场景，开发者可以考虑以下解决方案：

1. 确保客户端使用 UTF-8 编码：客户端应正确地将特殊字符编码为 UTF-8 字节序列。

2. 使用 Latin1 编码：如果确实需要处理可能包含非 UTF-8 编码的请求头，可以配置：

options.RequestHeaderEncodingSelector = _ => Encoding.Latin1;

3. 宽松的 UTF-8 处理：虽然不推荐，但可以通过自定义编码实现：

options.RequestHeaderEncodingSelector = _ => 
    new UTF8Encoding(encoderShouldEmitUTF8Identifier: false, throwOnInvalidBytes: false);

最佳实践

1. 在 REST API 设计中，尽量避免在 HTTP 头中使用非 ASCII 字符。

2. 如果必须使用特殊字符，确保客户端和服务器使用一致的编码方式。

3. 对于国际化需求，考虑将特殊内容放在请求体而非头中，或者进行适当的编码（如 Base64）。

理解这些编码细节对于构建健壮的 Web 应用程序至关重要，特别是在处理国际化内容时。开发者应当充分测试各种字符编码场景，确保系统的兼容性和稳定性。