Proxy Authentication Retries and Non-Repeatable Upload Bodies
Understand why authentication retries can expose a one-shot upload stream, and choose bounded buffering or repeatable content deliberately.
A GET can authenticate through a proxy while a POST or PUT fails with a non-repeatable-body or rewind error. The account may be correct: an authentication exchange can require another request after the client has already consumed the upload.
| Body source | Replay choice |
|---|---|
| Small finite body | A bounded buffer can retain its bytes. |
| Seekable file | The client's supported rewind interface can make it repeatable. |
| Generator, pipe or live producer | A one-shot source may require another design. |
libcurl documents seek callbacks for uses including multi-pass authentication. Jersey offers buffered and chunked entity-processing modes subject to connector behavior. A Jersey 2 Apache connector example shows the buffered setting. Neither makes unbounded in-memory uploads appropriate.
Reproduce the method and body source that fail. A preparatory GET has no upload to replay, and it does not establish that a later upload shares its connection or authentication state. A new destination, client object or connection policy can change that. A file-backed body and a live stream also differ even when their sample text is the same.
If you buffer, define its size limit, storage location and lifetime. Concurrent uploads multiply the cost, and sensitive data remains wherever the buffer is kept.
Preauthentication to a known compatible proxy can avoid one initial challenge. It cannot exclude every later authentication round, redirect or closed connection that might demand another attempt.
Keep the proxy reply, body-consumption point and replay error together. Then distinguish protocol replay from an uncertain application result: a submission may have been processed before its response was lost. Follow the destination's idempotency rules before sending it again.