Gatling HTTP模块：正确处理空请求体的Content-Type头部问题

在HTTP协议中，Content-Type头部字段用于指示请求或响应中传输的媒体类型。对于某些特定的Content-Type，如application/x-www-form-urlencoded，空字符串是一个合法的请求体值。然而，在Gatling的HTTP模块中，近期的一个改动（#4429）导致当请求体为空时，Content-Type头部被过度移除，这实际上是一个错误行为。

问题背景

Gatling是一个高性能的负载测试工具，其HTTP模块负责处理HTTP请求的构建和发送。在之前的版本中，当请求体为空时，系统会无条件地移除Content-Type头部。这种设计假设空请求体不需要Content-Type，但实际上，某些特定的Content-Type（如表单提交）允许空请求体作为有效值。

技术分析

HTTP协议规范并没有禁止空请求体与Content-Type头部的组合。特别是对于以下情况：

1. application/x-www-form-urlencoded：表单提交时可能没有参数
2. multipart/form-data：可能包含零个部分
3. 其他自定义媒体类型：可能有特殊语义允许空内容

Gatling之前的实现过于激进地移除了这些头部，导致某些合法的HTTP请求无法正确构建。

解决方案

正确的做法应该是：

1. 对于明确需要特定内容类型的便捷方法（如asJson和asXml），当请求体为空时可以不设置Content-Type，因为这些编码的空字符串不是有效内容
2. 对于其他情况，特别是用户显式设置了Content-Type头部时，应该保留该头部，即使请求体为空

这种修改既保持了API的便利性，又确保了HTTP协议的合规性。

影响评估

这一改动主要影响以下场景：

1. 测试表单提交但无参数的场景
2. 测试需要特定Content-Type头部但无请求体的API
3. 自定义HTTP客户端行为的测试用例

对于大多数JSON/XML API测试场景，行为保持不变。

最佳实践建议

作为Gatling用户，在处理空请求体时应注意：

1. 如果API需要特定Content-Type，即使请求体为空也应显式设置
2. 使用asFormUrlEncoded等方法时，空参数集是合法情况
3. 对于自定义需求，可以直接操作请求头部

这一修复将包含在Gatling的下一个版本中，确保HTTP请求构建更加符合协议规范和实际需求。