What do these changes do?

These changes fix a bug where file uploads fail with HTTP 422 errors when encountering 307/308 redirects. The issue occurs because:

1. HTTP 307/308 redirects preserve the request body (unlike 301/302/303)
2. When aiohttp reuses the same file payload for the redirect, the file position is at EOF after the first request
3. This causes the Content-Length calculation to return 0 for the second request, leading to server rejection

The fix includes:

• Client change: Preserve the payload instance (not raw data) for 307/308 redirects to prevent recreation of consumed payloads
• Payload change: Store initial file position on first access and calculate size from that position, ensuring correct Content-Length for reused payloads

Are there changes in behavior for the user?

File uploads that encounter 307/308 redirects will now work correctly instead of failing with HTTP 422 errors. This is a bug fix that restores expected behavior - no breaking changes.

Is it a substantial burden for the maintainers to support this?

No. The changes are minimal and focused:

• Simple logic to preserve payload instances for specific redirect types
• File position management that's already part of the payload lifecycle
• Well-tested with both unit and integration tests
• No new APIs or complex abstractions

Related issue number

Fixes #11270

Implementation Details

Changes Made

1. aiohttp/client.py

   • Modified redirect handling to preserve payload instance for 307/308 redirects
   • Changed from data = req.data to data = req._body to avoid payload recreation

2. aiohttp/payload.py

   • Modified size property to store start position on first access
   • Returns total size from start position instead of remaining bytes
   • Added AttributeError handling for tarfile streams
   • Properly handles unseekable files by returning None for size

3. tests/test_payload.py

   • Added test for payload size calculation after reading
   • Added test for unseekable file handling

4. tests/test_client_functional.py

   • Added integration test for file upload with 307 redirect

Technical Explanation

The root cause identified by Cycloctane in the issue: "Two requests share the same BufferedReaderPayload instance, while the second request get zero Content-Length."

This happens because:

1. First request reads the file, moving position to EOF
2. For 307/308 redirects, the same payload is reused
3. Size calculation was file_size - current_position, which equals 0 at EOF
4. Server receives Content-Length: 0 and returns 422 Unprocessable Entity

The fix stores the initial file position when size is first accessed, then always calculates size from that position. This ensures consistent Content-Length across multiple uses of the same payload instance.

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes (no user-facing API changes)
• Add yourself to CONTRIBUTORS.txt
• Add a new news fragment 11270.bugfix.rst into the CHANGES/ folder