Curl 7.29.0上传至lighttpd 1.4.45正常但7.61.1返回500如何排查

两个版本Curl执行结果不一致，主要来自Curl版本迭代带来的请求逻辑变更，和旧版lighttpd的兼容性问题：

1. Expect: 100-continue 处理差异：Curl默认会对大小超过1KB的POST请求自动添加Expect: 100-continue请求头，等待服务端响应100状态码后再发送请求体。Curl 7.29到7.61之间对该逻辑的超时等待、重试策略做过调整，而lighttpd 1.4.45存在对该请求头的解析兼容bug，会导致后续请求体解析失败。
2. Brotli压缩支持差异：Curl 7.57才正式加入Brotli(br)压缩支持，你请求头里带了Accept-Encoding: gzip, deflate, br，7.29版本实际不会携带br标识，而7.61版本会正常携带，如果lighttpd的mod_deflate模块未配置br支持，或者后端应用无法处理br压缩的请求/响应，就会触发错误。
3. multipart/form-data 格式差异：Curl 7.61调整了multipart表单的边界生成规则、文件名编码规则，如果你的$FileName包含非ASCII字符（比如中文），7.61会默认使用RFC5987标准编码文件名，而旧版lighttpd或者后端应用无法识别该编码格式，解析表单失败。
4. 请求头格式差异：你手动指定了Content-Type: multipart/form-data; 末尾带了分号，Curl 7.29会自动补全boundary参数在分号后，7.61的拼接逻辑可能存在差异，导致服务端无法识别表单边界。

该问题大概率和lighttpd 1.4.45的已知兼容bug有关，你返回的HTTP响应头已经明确是lighttpd返回，且1.4.45版本存在多例multipart表单解析、Expect头处理的相关bug，升级到1.4.46及以上版本可修复大部分此类问题。

• 首先在Curl 7.61的命令中添加-H "Expect:"参数，强制移除Expect请求头，重试请求，如果请求成功即可确认是100-continue的兼容问题。
• 移除--compressed参数，同时将Accept-Encoding头改为gzip, deflate，去掉br标识，测试是否为压缩协商导致的问题。
• 测试时固定$FileName为纯英文名称，排除文件名编码导致的解析异常。
• 去掉手动指定的Content-Type: multipart/form-data;请求头，Curl使用-F参数时会自动生成带正确boundary的Content-Type头，避免手动指定导致的格式错误。
• 开启lighttpd debug日志：在lighttpd配置中添加debug.log-request-header = "enable"、debug.log-request-body = "enable"，对比两个版本Curl的请求报文差异，定位具体解析失败的字段。
• 抓包对比：用tcpdump分别抓取两个版本Curl的完整请求报文，逐行对比请求头、请求体的差异，找到触发服务端错误的具体字段。

内容的提问来源于stack exchange，提问作者Albert.Huang