aBurmeseDev
commented
1 week ago Hi @lromor - thanks for reaching out.
As you're probably aware, this RequestTimeTooSkewed error is due to the mismatch between the server time and current time. In order for us to understand your use case better, can you share a minimal repro code?
Checkboxes for prior research
Describe the bug
From the browser the s3 client changes the X-Amz-Date based on the Date header. https://github.com/aws/aws-sdk-js-v3/blob/main/packages/middleware-signing/src/awsAuthMiddleware.ts#L105
Sometimes the responses are cached, and so their Date header. This introduces a drift in the systemClockOffset which eventually turns into the server returning time skew too large errors in successive requests.
SDK version number
@aws-sdk/client-s3@^3.433.0
Which JavaScript Runtime is this issue in?
Browser
Details of the browser/Node.js/ReactNative version
Browsers: Chrome: 125.0.6422.142 Safari: 17.5
Reproduction Steps
Request cacheable content using the "Cache-Control" headers. After a while, the server will return errors as the date of the sever and the client is too skewed.
Observed Behavior
After a while, X-Amz-Date used during requests is calculated with an offset that is very large. The server then responds with an error RequestTimeTooSkewed.
Expected Behavior
The client shouldn't try to compute an offset over cached responses.
Possible Solution
Either adjust the offset on requests that the client is certain are not cached.
Additional Information/Context
No response