0006-00000213

更新时间:
复制 MD 格式

Problem description

The policy form field in a PostObject request has expired.

Causes

PostObject requests include an expiration field in the policy form field. This field specifies the deadline, in ISO 8601 UTC format, by which the server must receive the complete request. If the server receives the request after that deadline, OSS rejects it.

This error can be triggered by any of the following conditions:

  • Policy generated too early: The policy was created long before the upload started. By the time the request reaches the server, the policy has already expired.

  • Client clock drift: The client system clock is out of sync with the server clock. Even if the client considers the request to be within the valid window, the server's clock may disagree.

  • Slow upload: Uploading a large object takes time. The policy may still be valid when the upload begins, but it may expire before the server receives the complete request.

Examples

The following policy sets expiration to 2023-02-19T13:19:00.000Z — that is, 1:19 PM UTC on February 19, 2023. OSS rejects any PostObject request that arrives after that moment.

{
    "expiration": "2023-02-19T13:19:00.000Z",
    "conditions": [
        ["content-length-range", 0, 1048576000]
    ]
}
FieldDescription
expirationThe deadline by which the server must receive the request, in ISO 8601 UTC format
content-length-rangeRestricts the accepted object size — in this example, 0 to 1,048,576,000 bytes

Solutions

  • Set the expiration value far enough in the future so the server can receive the complete PostObject request before it expires. Account for upload time when calculating the expiration window, especially for large objects.

  • Sync the client system clock with an NTP server to eliminate clock drift as a source of error.

References