如何测试代理链路中的 Multipart 上传完整性
HTTP 代理可能在普通页面请求中表现正常，却在真实上传流程里出错。Multipart 请求把文本字段、重复名称、文件名、逐段头部和任意二进制字节组合在同一个正文中。代理若缓冲、截断、重试或变换正文，客户端可能仍收到成功状态，但应用实际得到缺失字段、损坏文件或重复提交。
本指南建立一个确定性的 multipart/form-data 验收测试。只可使用自有或明确获准测试的端点，目标是验证正确性与有效业务结果，不是在无关服务上推送大文件。
理解边界约定
请求的 Content-Type 含有 boundary 参数，同一边界必须以精确的分隔格式出现在正文中，并以结束分隔符收尾。每个 part 都有自己的头部、空行和载荷。
通常应由客户端库同时生成正文和匹配的头部。在浏览器代码中手工设置 Content-Type: multipart/form-data，经常会遗漏自动生成的边界而形成无效请求。测试必须检查实际发送结果，不能只看构建表单的代码。
合规中间节点不应静默修改边界、part 头部或字节。两个传输段可以采用不同的合法帧格式，因此应比较解码后的 HTTP 消息，而不是要求数据包边界完全一致。
构建自有上传夹具
建立一个每次接收单一请求并返回精简回执的实验端点，包含：
| Part | 测试值 | 目的 |
|---|---|---|
| text | 短 ASCII 值 | 验证普通字段 |
| note | 多语言 UTF-8 文本 | 验证编码与长度 |
| tag | 两个同名字段 | 验证重复字段的数量与顺序 |
| empty | 零字节字段 | 验证空值保留 |
| file_a | 确定性二进制文件 | 验证字节完整性 |
| file_b | 零字节文件 | 验证空文件行为 |
使用固定种子在本地生成二进制夹具并记录 SHA-256。内容可覆盖零字节、高位字节、CRLF 和类似普通边界文本的片段，但不得包含凭据、个人数据或生产文件。
服务器回执只返回安全证据：字段数、有序字段名哈希、清理后的文件名、声明的媒体类型、接收字节数、逐文件摘要和一个业务结果 ID。
建立直连基线
使用计划投入生产的相同客户端与版本，在无代理情况下发送夹具，并确认：
- 头部边界与正文分隔符匹配；
- 除故意重复的字段外，每个预期 part 恰好出现一次；
- 重复值保留应用要求的顺序；
- 空字段和零字节文件都没有消失；
- UTF-8 文本能够正确往返；
- 文件长度与摘要一致；
- 结束分隔符存在；
- 一个请求只创建一个业务结果。
保存脱敏回执作为基线。能够用哈希和计数证明时，不要保留完整上传正文。
每次只比较一条代理路线
固定客户端、夹具、端点与超时，仅改变代理网关、区域、认证方式、会话策略或地址族。每次记录：
test_id
route_alias
client_version
client_to_proxy_protocol
proxy_to_origin_protocol
request_content_type_hash
part_count
repeated_field_count
received_file_bytes
received_file_digest_match
final_status
application_result_count
retry_count如果完整 Content-Type 含有随机边界，可只保存其哈希。禁止记录代理密码、Cookie、认证头、原始会话 ID 或私密文件内容。
边界参数消失或变化时，配合代理请求头完整性测试定位；回执不完整时，使用代理响应完整性测试。
同时测试缓冲与流式正文
客户端支持时应运行两种模式：
- 发送前即可知道总长度的正文；
- 传输时才决定帧方式的流式正文。
即使一条路径使用 Content-Length，另一条路径采用分块或协议原生帧，应用层 multipart 结构也必须一致。测试小型和适度大小的合成文件，并保持在服务商与端点限制之内。
如果只有流式代理上传失败，应记录失败发生在代理认证、隧道、头部、首批正文、中途传输还是最终响应。单一总超时不足以定位。
安全测试文件名和重复字段
不同客户端与服务器处理非 ASCII 文件名的方式可能不同。先测试普通文件名，应用明确支持时再加入无害的多语言名称。服务器必须去除目录部分，绝不能把客户端文件名直接当作文件系统路径。
重复字段名称合法且常见。确认框架返回所有值，而不是只保留第一个或最后一个。若顺序有业务意义，应把约定写清楚并测试。字典比较会丢失重复项，不能作为 multipart 等价证明。
有意测试重定向
上传端点应尽量避免无意义重定向。自有流程确实包含重定向时，应测试准确状态码与客户端行为。有些处理会改变方法或拒绝重放正文。记录客户端是否重发、哪个目标收到请求，以及产生多少业务结果。
禁止跟随到未批准主机。设置允许列表，目标超出自有测试范围时立即停止。
让重试保持安全
最后一个正文字节发出后发生网络故障，会产生不确定状态：服务器可能已经提交上传，但客户端没有收到回执。盲目轮换代理再发一次可能制造重复结果。
使用应用幂等键或自有上传会话标识，并限制尝试次数、总耗时和发送字节数。同一逻辑操作必须返回或引用同一个结果。启用自动故障转移前，先执行重试风暴预防指南。
大型正文可能在头部阶段被拒绝时，可配合Expect: 100-continue 上传测试。本测试验证 multipart 正文与业务结果，Expect 测试验证头部和正文的握手顺序。
常见故障模式
| 现象 | 优先检查 |
|---|---|
| boundary 参数缺失 | 客户端手工设置了 Content-Type 或头部被修改 |
| 服务器只解析出一个巨大字段 | 分隔符或换行格式错误 |
| 最后一个 part 缺失 | 截断或结束分隔符丢失 |
| 二进制摘要不匹配 | 正文变换、截断或夹具错误 |
| 重复值只剩一个 | 框架或应用折叠了重复项 |
| 直连正常、流式代理失败 | 缓冲、帧、超时或网关限制 |
| 产生两个业务结果 | 不确定失败后的不安全重放 |
| 状态成功但回执错误 | 应用校验或响应完整性故障 |
不要把每个 multipart 故障都归因于出口 IP 信誉。本测试的大多数问题来自消息构造、传输帧、缓冲、限制或重试逻辑。
验收清单
- 客户端生成的边界与正文一致。
- 预期 part 数和重复值被保留。
- 空字段和零字节文件仍存在。
- 多语言文本正确往返。
- 清理后的文件名符合应用约定。
- 文件长度和 SHA-256 一致。
- 已测试缓冲与流式模式。
- 重定向目标和重放行为受控。
- 一个逻辑上传只产生一个业务结果。
- 重试有上限并具备幂等性。
- 日志只含哈希与计数，不含秘密或私密原文件。
常见问题
浏览器代码应手工设置 multipart Content-Type 吗？
通常不应。当浏览器或表单库生成正文时，让它设置头部，确保 boundary 参数匹配。仍需验证所用客户端的实际行为。
HTTP 200 能证明上传完整吗？
不能。还要核对服务器回执、part 数、字节长度、文件摘要和业务结果数量。
代理可以改变传输帧而不破坏 multipart 吗？
可以。两段链路可采用不同的合法帧方式，必须保持的是解码后的 HTTP 消息和 multipart 结构。
上传失败后是否应立即轮换代理 IP？
不应。先确定失败阶段，并判断服务器是否已经提交操作。只有在有界且幂等的策略下才可轮换。
合规说明
Multipart 上传测试仅可针对自有或明确获准使用的系统。遵守文件大小、速率、内容政策、区域数据要求与代理条款。使用合成夹具，清理文件名，减少数据保留，绝不能通过代理轮换绕过上传控制。
