[siddsriv]

Description

Compute the clock skew candidate as the response Date minus the client time when the response headers were received, instead of the request round-trip midpoint. Date is generated with the response, so the midpoint counted half of the server processing time as skew (e.g. about +310s for a 620s request with agreeing clocks).

Fix

• An on_headers listener (added once per request, cleared each attempt with its recorded timestamp cleared before each retry) records the raw client time when headers arrive, before the body is read. Used by both Handler and LegacyHandler through a shared helper on RetryErrors.
• Candidate skew is server_time - received_at. The 15-minute discard, 4-minute retry threshold, Age/missing Date discards, per-endpoint storage, and disable settings are unchanged.
• If no headers time was recorded for an attempt (e.g. a custom send handler that sets headers without signal_headers), the candidate falls back to server_time - now. Net::HTTP, HTTP/2, and stub_responses all record it.
• Both generated minimum core dependencies are raised to 3.264.0.

Testing

• aws-sdk-core specs: 2515 examples, 0 failures (30 added) 2,491 examples, 0 failures, 36 pending.
• Shared clock skew test cases (12) run through an STS client with a fake clock, plus a loopback Net::HTTP test that holds the body after sending headers (200 and 403).
• Focused examples in the existing clock skew and retry specs cover headers arrival, delayed bodies, retry timestamp cleanup, legacy retries, and signing retries and later operations.
• changelog_verifier_spec passes; git diff --check clean.

🤖 Edited by @jterapin with AI assistance. ✨