Python Requests HTTP 307 Stream Replay

What's being tested

These debugging questions test tracing HTTP 307 redirect semantics through Python requests, especially preserving the method and replaying a streamed request body. You must reason from bytes on the wire—stream position, Content-Length, socket reads, and timeout behavior—then propose a minimal, robust fix for seekable versus non-replayable bodies.

Patterns & templates

• 307 preserves method and body: the redirected request remains POST; unlike 303, it must resend the original payload to the new URL.

• Seekable stream replay: record the initial position with body.tell(), then call body.seek(position) before retrying or redirect replay.

• requests may rewind using its internal body-position metadata; verify PreparedRequest._body_position and inspect requests/urllib3 behavior rather than assuming automatic replay.

• Content-Length framing must match bytes actually available; a reused stream at EOF can advertise N bytes while sending zero, causing the server to wait.

• Prefer a bytes/string body for small payloads: it is naturally replayable; use a reopened file or seekable object for large uploads.

• Treat generators and pipes as non-replayable unless buffered; retrying them can duplicate, truncate, or silently alter the payload.

• Debug with a short timeout, request/response logging, tell() before and after sends, and a local redirect server; distinguish client hang from server processing.

Common pitfalls

Pitfall: Saying “307 changes the request to GET” confuses it with 303; 307 preserves both method and body.

Pitfall: Rewinding only after the timeout is insufficient if the first request already consumed the stream; restore the position before the redirected send.

Pitfall: Recommending blind retries ignores non-seekable bodies and duplicate side effects; use idempotency keys or explicit buffering where appropriate.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.