代理认证重试与不可重复的上传请求体
理解为什么认证重试可能暴露一次性上传流，并有意识地选择有界缓冲或可重复的内容。
GET 可以通过代理完成认证，而 POST 或 PUT 却因请求体不可重复或回绕错误而失败。账号可能是正确的：在客户端已经消耗上传数据之后，认证交换仍可能需要再一次请求。
| 请求体来源 | 重放选择 |
|---|---|
| 小型有限请求体 | 有界缓冲区可以保留其字节。 |
| 可寻址文件 | 客户端支持的回绕接口可以使其可重复。 |
| 生成器、管道或实时生产者 | 一次性来源可能需要另一种设计。 |
libcurl 记录了用于包括多轮认证在内的场景的 seek 回调。Jersey 提供缓冲和分块的实体处理模式，具体取决于连接器的行为。一个 Jersey 2 Apache 连接器示例 展示了缓冲设置。两者都不会让无限制的内存上传变得合适。
复现失败的方法和请求体来源。预备性 GET 没有可重放的上传，也不能证明后续上传会共享其连接或认证状态。新的目标、客户端对象或连接策略都可能改变这一点。基于文件的请求体和实时流也不相同，即使它们的示例文本一样。
如果进行缓冲，要明确其大小上限、存放位置和生命周期。并发上传会成倍增加成本，敏感数据会留在缓冲区所在的任何地方。
对已知兼容代理进行预先认证 可以避免一次初始质询。但它无法排除后续每一轮认证、重定向或关闭的连接，这些都可能要求再次尝试。
把代理响应、请求体消耗点和重放错误放在一起看。然后区分协议重放与不确定的应用结果：请求可能在其响应丢失之前已被处理。再次发送之前，请遵循目标端的幂等规则。