UWP HttpClient中请求头与内容头的区别及配置适用规则

核心定位差异 #

两个Headers属性根本不是冗余设计，是UWP HttpClient严格遵循HTTP RFC协议规范做的分层封装，二者的语义边界和生效逻辑完全独立：

• HttpRequestMessage.Headers：对应协议层请求通用头部的封装，所有和请求行为本身强绑定、与请求携带的实体内容无直接关联的头部，都应该配置在这里。这类头部最终会被序列化到HTTP请求的通用头域，属于请求级的全局配置。
• HttpStreamContent（所有HttpContent子类）.Headers：对应协议层实体头部的封装，所有用于描述本次携带的实体内容自身属性的头部，都应该配置在这里。这类头部最终会和通用请求头一起出现在请求报文的头部区域（实体分隔线之前），但语义上完全归属于当前绑定的内容对象。

注意：两类头在最终HTTP报文中没有物理位置的硬分隔，所有头字段都在实体块之前，区别仅为协议语义的归属，不存在“实体头会被放到请求体里”的情况。

重复添加头部的错误性 #

将同一组头部同时添加到两个位置的写法存在明确问题，不存在“智能自动过滤非法字段”的兜底逻辑：

• UWP的HttpClient底层基于WinHTTP协议栈实现，对头部的语义归属有严格校验逻辑：如果把本该属于请求通用头的字段添加到Content.Headers，栈会直接将其从实体头配置中移除，最终不会发送到服务端；如果把本该属于实体头的字段添加到Request.Headers，栈会直接丢弃该配置，不会将其加入最终请求的头域。
• 哪怕你用TryAppendWithoutValidation方法绕过客户端的本地校验，最终发送时栈依然会按协议规范做归属处理，你在错误位置添加的同名配置会被直接覆盖或丢弃，不会重复出现在请求中。比如你代码中同时配置的Content-Length，最终栈只会读取Content上设置的强类型长度值，你在Request层绕校验加的同名头会被直接忽略。
• 你当前代码里两层循环重复塞同一组头的写法，大部分配置都是无效操作，只有刚好和Headers归属匹配的那部分才会真正生效，剩下的写了等于没写。

头部配置的归属判断规则 #

两类头部完全无法互换，判断标准非常直接：

• 配置到HttpRequestMessage.Headers的场景：只要头部描述的是请求本身的行为、认证要求、客户端能力、缓存策略等和传输实体无关的属性，就配置在这里。典型字段包括：Authorization、User-Agent、Accept、Cache-Control（请求级）、If-Match、Range、Referer。
• 配置到HttpContent.Headers的场景：只要头部描述的是本次传输的实体内容本身的格式、大小、编码、范围等属性，就配置在内容对象的Headers下。典型字段包括：Content-Type、Content-Length、Content-Encoding、Content-Range、Content-MD5。

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