All Products
Search
Document Center

Object Storage Service:PostObject

Last Updated:Feb 29, 2024

Uploads an object to a bucket by using an HTML form.

Usage notes

  • To upload an object to a bucket by using an HTML form, you must have the oss:PutObject permission. For more information, see Attach a custom policy to a RAM user.

  • The size of the object that you want to upload by calling the PostObject operation cannot exceed 5 GB.

  • To initiate a PostObject request to a bucket, you must have the write permissions on the bucket. If the access control list (ACL) of the bucket to which you want to initiate a PostObject request is public-read-write, you do not need to sign the PostObject request. Otherwise, Object Storage Service (OSS) verifies the signature information in the request.

  • Unlike the PutObject operation, the PostObject operation uses an AccessKey secret to calculate the signature for the policy form field. The calculated signature string is used as the value of the Signature form field. OSS checks this value to verify the validity of the signature.

  • The URL of the submitted form is the domain name of the bucket. You do not need to specify the object that you want to upload to the bucket in the URL. The request line is in the format of POST / HTTP/1.1 instead of POST /ObjectName HTTP/1.1.

  • OSS does not check the signature information in headers or URLs in PostObject requests.

Versioning

If you initiate a PostObject request to a versioning-enabled bucket, OSS generates a unique version ID for the uploaded object and returns the version ID as the value of the x-oss-version-id header in the response.

If you initiate a PostObject request to a versioning-suspended bucket, OSS generates a version ID of null for the uploaded object and returns the version ID as the value of the x-oss-version-id header in the response. An object can have only one version whose ID is null.

Request syntax

POST / HTTP/1.1 
Host: BucketName.oss-cn-hangzhou.aliyuncs.com
User-Agent: browser_data
Content-Length: ContentLength
Content-Type: multipart/form-data; boundary=9431149156168
--9431149156168
Content-Disposition: form-data; name="key"
key
--9431149156168
Content-Disposition: form-data; name="success_action_redirect"
success_redirect
--9431149156168
Content-Disposition: form-data; name="Content-Disposition"
attachment;filename=oss_download.jpg
--9431149156168
Content-Disposition: form-data; name="x-oss-meta-uuid"
myuuid
--9431149156168
Content-Disposition: form-data; name="x-oss-meta-tag"
mytag
--9431149156168
Content-Disposition: form-data; name="OSSAccessKeyId"
access-key-id
--9431149156168
Content-Disposition: form-data; name="policy"
encoded_policy
--9431149156168
Content-Disposition: form-data; name="Signature"
signature
--9431149156168
Content-Disposition: form-data; name="file"; filename="MyFilename.jpg"
Content-Type: image/jpeg
file_content
--9431149156168
Content-Disposition: form-data; name="submit"
Upload to OSS
--9431149156168--

Request headers

Important
  • The body of a PostObject request is encoded in the multipart/form-data format. In the PostObject operation, the parameters are passed as form fields in the request body, whereas the parameters are passed as HTTP request headers in the PutObject operation.

  • You cannot add tags to objects by passing the x-oss-tagging request header during the PostObject operation. You can call the PutObjectTagging operation to add tags to objects after the PostObject operation is complete.

Header

Type

Required

Description

Content-Type

String

No

The type of the object that you want to upload and the encoding format of the web page. Browsers determine how to read and encode the object based on the value of the header.

The form submitted in the PostObject operation must be encoded in the multipart/form-data format. The Content-Type header must be in the multipart/form-data;boundary=xxxxxx format.

In this format, boundary is a boundary string that is randomly generated by the form. You do not need to specify a boundary string. If you use an OSS SDK to create a form, the SDK also generates a random boundary string.

x-oss-object-acl

String

No

The ACL of the object that you want to upload.

If you specify x-oss-object-acl in the request header and the form field, the ACL that is specified in the form field takes precedence over the ACL that is specified in the request header.

Valid values:

  • default (default): The ACL of the object is the same as that of the bucket in which the object is stored.

  • private: The ACL of the object is private. Only the owner of the object and authorized users have the read and write permissions on the object.

  • public-read: The ACL of the object is public-read. Only the owner of the object and authorized users have the read and write permissions on the object. Other users have only the read permissions on the object. Exercise caution when you set the object ACL to this value.

  • public-read-write: The ACL of the object is public-read-write. All users have the read and write permissions on the object. Exercise caution when you set the object ACL to this value.

For more information, see Object ACLs.

For more information about the common request headers in a PostObject request, such as Host and Date, see Common request headers.

Request elements

Important
  • The last form field must be file. No particular order is required for other form fields.

  • The key of a form field cannot exceed 8 KB, and the value of a form field cannot exceed 2 MB.

Element

Type

Required

Description

Cache-Control

String

No

The caching behavior of the web page when the object is downloaded. For more information, see RFC 2616.

This element is empty by default.

Content-Disposition

String

No

The name of the object when the object is downloaded. For more information, see RFC 2616.

This element is empty by default.

Content-Encoding

String

No

The content encoding format of the object when the object is downloaded. For more information, see RFC 2616.

This element is empty by default.

Expires

String

No

The time when the cached data expires. For more information, see RFC 2616.

This element is empty by default.

OSSAccessKeyId

String

Conditional

The AccessKey ID of the account that owns the bucket.

This element is empty by default.

Condition: This form field is required if the bucket ACL is not public-read-write or the policy or Signature form field is specified in the request.

policy

String

Conditional

The validity of the form fields in the request. A request that does not contain the policy form field is considered as an anonymous request and can be used only to access buckets whose ACLs are public-read-write.

This element is empty by default.

Condition: This form field is required if the bucket ACL is not public-read-write or the OSSAccessKeyId or Signature form field is specified in the request.

Important

The form and the policy form field must be UTF-8-encoded. The policy form field must also be Base64-encoded.

Signature

String

Conditional

The signature information that is calculated based on the AccessKey secret and the policy form field. OSS checks the signature information to verify the validity of the PostObject request. For more information, see Appendix: Signature.

This element is empty by default.

Condition: This form field is required if the bucket ACL is not public-read-write or the OSSAccessKeyId or policy form field is specified in the request.

Note

Form fields are not case-sensitive, but their values are case-sensitive.

x-oss-server-side-encryption-key-id

String

No

The ID of the customer master key (CMK) that is managed by Key Management Service (KMS). You can configure this element only when the x-oss-server-side-encryption element is set to KMS.

x-oss-content-type

String

No

You can add the x-oss-content-type form field to the body of a PostObject request to specify the content type of the object that you want to upload. The content type specified by the x-oss-content-type form field takes precedence over the content type specified by the file form field that is automatically generated by browsers.

The content types are prioritized in the following order: x-oss-content-type form field > Content-Type specified in the file form field that is automatically generated by browsers.

This element is empty by default.

x-oss-forbid-overwrite

String

No

Specifies whether the PostObject operation overwrites the existing object that has the same name.

When versioning is enabled or suspended for the bucket to which you want to upload the object, x-oss-forbid-overwrite does not take effect. In this case, the object that is uploaded by calling the PostObject operation overwrites the existing object that has the same name.

  • If x-oss-forbid-overwrite is not specified or x-oss-forbid-overwrite is set to false, the object uploaded by calling the PostObject operation overwrites the existing object that has the same name.

  • If x-oss-forbid-overwrite is set to true, the object uploaded by calling the PostObject operation does not overwrite the existing object that has the same name.

If you specify x-oss-forbid-overwrite, the queries per second (QPS) performance of OSS may be degraded. If you want to use x-oss-forbid-overwrite to perform a large number of operations (QPS greater than 1,000), contact technical support.

x-oss-object-acl

String

No

The ACL of the object that you want to upload. You can specify the ACL of the object that you want to upload in the request header and the form field.

If you specify x-oss-object-acl in the request header and the form field, the ACL that is specified in the form field takes precedence over the ACL that is specified in the request header.

Valid values:

  • default (default): The ACL of the object is the same as that of the bucket in which the object is stored.

  • private: The ACL of the object is private. Only the owner of the object and authorized users have the read and write permissions on the object.

  • public-read: The ACL of the object is public-read. Only the owner of the object and authorized users have the read and write permissions on the object. Other users have only the read permissions on the object. Exercise caution when you set the object ACL to this value.

  • public-read-write: The ACL of the object is public-read-write. All users have the read and write permissions on the object. Exercise caution when you set the object ACL to this value.

For more information, see Object ACLs.

x-oss-storage-class

String

No

The storage class of the object.

If you specify x-oss-storage-class when you upload an object, the storage class of the uploaded object is the specified value regardless of the storage class of the bucket to which the object is uploaded. For example, if you set the x-oss-storage-class header to Standard when you upload an object to an Infrequent Access (IA) bucket, the object is stored as a Standard object.

Valid values:

  • Standard

  • IA

  • Archive

  • ColdArchive

  • DeepColdArchive

    Important

    If you want to upload a large number of objects and set the storage classes of the objects to Deep Cold Archive, you are charged high PUT request fees. We recommend that you set the storage classes of the objects to Standard when you upload the objects, and configure lifecycle rules to convert the storage classes of the Standard objects to Deep Cold Archive. This reduces PUT request fees.

For more information, see Overview.

key

String

Yes

The name of the object that you want to upload. You do not need to encode the object name. If the object name contains a path, such as destfolder/example.jpg, OSS creates the corresponding directory.

This element is empty by default.

success_action_redirect

String

No

The URL to which the client is redirected after the object is uploaded. If this form field is not specified, the returned result is specified by the success_action_status form field. If the upload fails, OSS returns an error code, and the client is not redirected to the URL.

This element is empty by default.

success_action_status

String

No

The HTTP status code that is returned to the client when the success_action_redirect form field is not specified and the object is uploaded.

Valid values: 200, 201, and 204. Default value: 204.

  • If this form field is set to 200 or 204, OSS returns an empty file and HTTP status code 200 or 204.

  • If this form field is set to 201, OSS returns an XML file and HTTP status code 201.

  • If this form field is not specified or set to an invalid value, OSS returns an empty file and HTTP status code 204.

x-oss-meta-*

String

No

The user metadata of the object.

This element is empty by default.

If the request contains a form field whose name contains the x-oss-meta- prefix, the form field is considered as the user metadata of the object. Example: x-oss-meta-location.

Note

An object can have multiple form fields whose names contain the x-oss-meta- prefix. However, the total size of all user metadata of the object cannot exceed 8 KB.

x-oss-security-token

String

No

The security token for temporary access authorization. If you obtain temporary access credentials from Security Token Service (STS) and use the temporary access credentials for the request, you must set this form field to the security token and set OSSAccessKeyId to the AccessKey ID in the temporary access credentials. You can calculate the signature for a request that uses a temporary AccessKey ID in the same manner that you calculate the signature for a request that uses an AccessKey ID.

This element is empty by default.

For more information, see Use temporary credentials provided by STS to access OSS. You can call the AssumeRole operation or use STS SDKs for various programming languages to obtain temporary access credentials.

file

String

Yes

The file or text content. You do not need to encode the content. Browsers automatically add the Content-Type form field based on the file type and overwrite the content type specified in the Content-Type header. You can upload only one object by using a PostObject request.

This element is empty by default.

Important

The last form field must be file.

Response headers

Header

Type

Example

Description

x-oss-server-side-encryption

String

KMS

The algorithm that is used to encrypt the object on the server side. If x-oss-server-side-encryption is specified in the request, the response contains this header.

Content-MD5

String

1B2M2Y8AsgTpgAmY7PhC****

The MD5 hash of the object.

Important

The MD5 hash of the object is obtained after the client uploads the object. The MD5 hash of the object is not the MD5 hash in the response body.

x-oss-hash-crc64ecma

String

316181249502703****

The CRC-64 value of the object.

x-oss-version-id

String

CAEQNhiBgMDJgZCA0BYiIDc4MGZjZGI2OTBjOTRmNTE5NmU5NmFhZjhjYmY0****

The version ID of the object. This header is returned only if you upload the object to a versioning-enabled bucket.

For more information about the common response headers, such as Date and x-oss-request-id, in the response to a PostObject request, see Common response headers.

Response elements

Element

Type

Description

PostResponse

Container

The container that stores the result of the PostObject request.

Child nodes: Bucket, ETag, Key, and Location

Bucket

String

The name of the bucket.

Parent nodes: PostResponse

ETag

String

The entity tag (ETag) that is created when the object is uploaded. If an object is created by calling the PostObject operation, the ETag value is not the MD5 hash of the object content but a unique value calculated based on a specific rule. The ETag value of an object can be used to check whether the object content is modified.

Parent nodes: PostResponse

Location

String

The URL that is used to access the uploaded object.

Parent nodes: PostResponse

Examples

  • Sample request

    POST / HTTP/1.1
    Host: oss-example.oss-cn-hangzhou.aliyuncs.com
    Content-Length: 344606
    Content-Type: multipart/form-data; boundary=9431149156168
    --9431149156168
    Content-Disposition: form-data; name="key"
    /user/a/objectName.txt
    --9431149156168
    Content-Disposition: form-data; name="success_action_status"
    200
    --9431149156168
    Content-Disposition: form-data; name="Content-Disposition"
    content_disposition
    --9431149156168
    Content-Disposition: form-data; name="x-oss-meta-uuid"
    uuid
    --9431149156168
    Content-Disposition: form-data; name="x-oss-meta-tag"
    metadata
    --9431149156168
    Content-Disposition: form-data; name="OSSAccessKeyId"
    44CF9590006BF252****
    --9431149156168
    Content-Disposition: form-data; name="policy"
    eyJleHBpcmF0aW9uIjoiMjAxMy0xMi0wMVQxMjowMDowMFoiLCJjb25kaXRpb25zIjpbWyJjb250ZW50LWxlbmd0aC1yYW5nZSIsIDAsIDEwNDg1NzYwXSx7ImJ1Y2tldCI6ImFoYWhhIn0sIHsiQSI6ICJhIn0seyJrZXkiOiAiQUJDIn1dfQ==
    --9431149156168
    Content-Disposition: form-data; name="Signature"
    kZoYNv66bsmc10+dcGKw5x2P****
    --9431149156168
    Content-Disposition: form-data; name="file"; filename="MyFilename.txt"
    Content-Type: text/plain
    abcdefg
    --9431149156168
    Content-Disposition: form-data; name="submit"
    Upload to OSS
    --9431149156168--
  • Sample success response

    HTTP/1.1 200 OK
    x-oss-request-id: 61d2042d-1b68-6708-5906-33d81921362e 
    Date: Fri, 24 Feb 2014 06:03:28 GMT
    ETag: "5B3C1A2E053D763E1B002CC607C5****"
    Connection: keep-alive
    Content-Length: 0
    x-oss-hash-crc64ecma: 316181249502703****
    Content-MD5: 1B2M2Y8AsgTpgAmY7PhC****
    Server: AliyunOSS

Error codes

Error code

HTTP status code

Description

FieldItemTooLong

400

The size of the form field key exceeds 8 KB or the size of the form field value exceeds 2 MB.

InvalidArgument

400

One of the OSSAccessKeyId, policy, and Signature form fields is specified but the other two form fields are not specified in the request regardless of whether the ACL of the bucket is public-read-write.

InvalidDigest

400

The Content-MD5 value that is calculated by OSS based on the request body is different from the Content-MD5 value that is specified in the request header.

EntityTooLarge

400

The total size of the PostObject request body exceeds 5 GB.

InvalidEncryptionAlgorithmError

400

The x-oss-server-side-encryption header is set to a value other than AES256 or KMS. The x-oss-server-side-encryption header can be set only to AES256 or KMS.

IncorrectNumberOfFilesInPOSTRequest

400

The number of objects in the PostObject request is invalid. A PostObject request can contain only one file form field.

FileAlreadyExists

409

The request contains the x-oss-forbid-overwrite=true element, but an object that has the same name already exists.

KmsServiceNotEnabled

403

The x-oss-server-side-encryption header is set to KMS but KMS is not activated in advance.

FileImmutable

409

The data that you want to delete or modify is protected by a retention policy.

Appendix: Policy

The policy form field in a PostObject request is used to verify the validity of the request. The value of the policy form field is a JSON string that is encoded in UTF-8 and Base64. This value specifies the conditions that a PostObject request must meet. The policy form field is optional when you upload an object to a bucket whose ACL is public-read-write. However, we recommend that you specify this form field to limit PostObject requests.

Example:

{
  "expiration": "2014-12-01T12:00:00.000Z",
  "conditions": [
    {"bucket": "johnsmith" },    
    ["content-length-range", 1, 10],
    ["eq", "$success_action_status", "201"],
    ["starts-with", "$key", "user/eric/"],
    ["in", "$content-type", ["image/jpg", "image/png"]],
    ["not-in", "$cache-control", ["no-cache"]]
  ]
}

The policy form field must contain the expiration and conditions parameters.

  • Expiration

    The expiration parameter specifies the expiration time of the request. The time must follow the ISO 8601 standard and must be in GMT. For example, 2014-12-01T12:00:00.000Z specifies that the PostObject request must be sent before 12:00 on December 1, 2014.

  • Conditions

    The conditions parameter is a list that specifies the valid values of the form fields in the PostObject request.

    The following table describes the conditions that can be configured in the policy field.

    Parameter

    Description

    Matching mode

    bucket

    The name of the bucket.

    bucket

    content-length-range

    The minimum and maximum allowed sizes of the object to upload. Unit: bytes.

    content-length-range

    Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires

    The HTTP request headers.

    Important

    To prevent malicious modifications to the Content-Type header during form upload, we recommend that you specify the Content-Type header in the policy form field. You can use one of the following methods to specify the Content-Type header:

    • Add the x-oss-content-type element to the body of a PostObject request to specify the Content-Type header. Example: Content-Type: image/jpeg. For more information about the values of the Content-Type header supported by OSS, see How do I configure the Content-Type header?

    • Use the file form field to specify the Content-Type header. Example: Content-Type: image/png. For more information about the values of the Content-Type header supported by OSS, see How do I configure the Content-Type header?

    The content type specified by the x-oss-content-type element takes precedence over the content type specified by the file form field.

    eq, starts-with, in, and not-in

    key

    The name of the object.

    eq, starts-with, in, and not-in

    success_action_redirect

    The URL to which the client is redirected after the object is uploaded.

    eq, starts-with, in, and not-in

    success_action_status

    The HTTP status code to return after the object is uploaded if success_action_redirect is not specified.

    eq, starts-with, in, and not-in

    x-oss-meta-*

    The user metadata of the object.

    Note

    The policy field specifies the form fields that must be contained in the PostObject request. If you specify ["eq", "$x-oss-meta-biedb", "biedb-test001"], you must add the form field whose key is x-oss-meta-biedb and value is biedb-test001. Otherwise, the Invalid according to Policy: Policy Condition failed: ["eq", "$x-oss-meta-biedb", "biedb-test001"] error message is returned.

    eq, starts-with, in, and not-in

    If the PostObject request contains additional form fields, OSS adds these form fields to the conditions of the policy and checks their validity.

  • Condition matching modes

    Matching mode

    Description

    content-length-range

    The size of the object that you want to upload must be within the range of the supported object size. For example, if the supported object size is 1 to 10 bytes, the condition must be ["content-length-range", 1, 10].

    eq

    The value of a form field must be exactly the same as the value that is specified in the conditions. For example, if the value of the key form field must be a, you can specify ["eq", "$key", "a"] as the condition.

    starts-with

    The value of a form field must start with the specified prefix. For example, if the value of the key form field starts with user/user1, you can specify ["starts-with", "$key", "user/user1"] as the condition.

    in

    The elements that you want to include in the verification. The elements must be specified in the condition string. For example, if you want to verify whether JPG and PNG images can be uploaded in a PostObject request, the condition must be ["in", "$content-type", ["image/jpg", "image/png"]].

    not-in

    The elements that you want to exclude from the verification. The elements must be specified in the condition string. For example, if you want to specify an object caching behavior and exclude the no-cache element, the condition must be ["not-in", "$cache-control", ["no-cache"]].

In the policy form field of a PostObject request, the dollar sign ($) indicates a variable. To describe the dollar sign ($), you must use the following escape character: \$. The following table describes the escape characters used in the JSON string of the policy form field in a PostObject request.

Escape character

Description

\/

Forward slash

\\

Backslash

\"

Double quotation mark

\$

Dollar sign

\b

Space

\f

Form feed

\n

Line break

\r

Carriage return

\t

Horizontal tab

\uxxxx

Unicode characters

Appendix: Signature

(Recommend) V4 signature

A PostObject request supports the V4 signature. The form and the policy form field must contain the following information to support signature verification in OSS.

  • Form

    Field

    Data type

    Required

    Description

    policy

    String

    Yes

    A Base64-encoded policy string to be signed. The string specifies the allowed requests.

    x-oss-signature-version

    String

    Yes

    The version and algorithm of the signature. Valid value: OSS4-HMAC-SHA256.

    x-oss-credential

    String

    Yes

    The credentials that you can use to calculate the signature. Format:

    <AccessKeyId>/<date>/<region>/oss/aliyun_v4_request
    • AccessKeyId: the AccessKey ID in the AccessKey pair.

    • date: the date when the request was initiated. Format: YYYYMMDD. Example: 20231203.

    • region: the region from which the request was sent.

    • oss: the name of the requested service. Valid value: oss.

    • aliyun_v4_request: the description of the signature version in the request. Valid value: aliyun_v4_request.

    x-oss-date

    String

    Yes

    The time when the request was initiated. The time must follow the ISO 8601 standard. Example: 20231203T121212Z.

    • An offset of up to 15 minutes after the request was initiated is allowed. Therefore, the time when the server receives the request can be up to 15 minutes later than the time specified by x-oss-date. This ensures that the requests can be processed as expected even if network transmission latency or time difference between the client and the server exists.

    • The request has a validity period of up to seven days. Seven days after the time specified by x-oss-date, OSS denies the request and an error is reported. This ensures the timeliness and security of requests and prevents malicious submission of expired or signed requests.

    • The time specified by x-oss-date is used as the timestamp for the string to sign. The value must be the same as that of the date field in the derived keys and that of the x-oss-date field in the policy form field.

    x-oss-signature

    String

    Yes

    The description used for signature verification. The value is calculated by encrypting the Base64-encoded policy string by using HMAC-SHA256, and then converting the binary hash obtained by using HMAC-SHA256 into hexadecimal format.

    x-oss-security-token

    String

    No

    The security token issued by Security Token Service (STS). This field is required only when you use an STS user to construct the URL signature.

  • Policy

    {
      "expiration": "2023-12-03T13:00:00.000Z",
      "conditions": [
        {"bucket": "johnsmith"},
        {"x-oss-signature-version": "OSS4-HMAC-SHA256"},
        {"x-oss-credential": "AKIDEXAMPLE/20231203/cn-hangzhou/oss/aliyun_v4_request"},
        {"x-oss-date": "20231203T121212Z"},
        ["content-length-range", 1, 10],
        ["eq", "$success_action_status", "201"],
        ["starts-with", "$key", "user/eric/"],
        ["in", "$content-type", ["image/jpg", "image/png"]],
        ["not-in", "$cache-control", ["no-cache"]]
      ]
    }

    The conditions of a policy form field must contain the following fields.

    Field

    Data type

    Required

    Description

    x-oss-signature-version

    String

    Yes

    The version and algorithm of the signature. Valid value: OSS4-HMAC-SHA256.

    x-oss-credential

    String

    Yes

    The credentials that you can use to calculate the signature. Format:

    <AccessKeyId>/<date>/<region>/oss/aliyun_v4_request
    • AccessKeyId: the AccessKey ID in the AccessKey pair.

    • date: the date when the request was initiated.

    • region: the region from which the request was sent.

    • oss: the name of the requested service. Valid value: oss.

    • aliyun_v4_request: the description of the signature version in the request. Valid value: aliyun_v4_request.

    x-oss-date

    String

    Yes

    The time when the request was initiated. The time must follow the ISO 8601 standard. Example: 20231203T121212Z.

    • An offset of up to 15 minutes after the request was initiated is allowed. Therefore, the time when the server receives the request can be up to 15 minutes later than the time specified by x-oss-date. This ensures that the requests can be processed as expected even if network transmission latency or time difference between the client and the server exists.

    • The request has a validity period of up to seven days. Seven days after the time specified by x-oss-date, OSS denies the request and an error is reported. This ensures the timeliness and security of requests and prevents malicious submission of expired or signed requests.

    • The time specified by x-oss-date is used as the timestamp for the string to sign. The value must be the same as that of the date field in the derived keys and that of the x-oss-date field in the policy form field.

  • Signature calculation process

    image

    1. Create a UTF-8-encoded policy.

    2. Base64-encode the policy to generate a string that can be transmitted securely as the string to be signed.

    3. Encrypt the string to sign by using HMAC-SHA256. Use the derived keys of the account as the keys for using HMAC-SHA256.

    4. Convert the binary hash calculated by using HMAC-SHA256 to a hexadecimal string. The obtained hexadecimal string is the signature used to verify the integrity and validity of the request.

V1 signature

To verify a PostObject request, you must include the policy and Signature form fields in the HTML form. The policy form field specifies the values that are supported in the request.

You can perform the following steps to calculate the value of the Signature form field:

  1. Create a UTF-8-encoded policy.

  2. Encode the policy in Base64. The result is the value of the policy form field, and the value is used as the string to be signed.

  3. Use the AccessKey secret to sign the string in the following format: Signature = base64(hmac-sha1(AccessKeySecret,base64(policy))).

FAQ

What do I do if the "Your proposed upload exceeds the maximum allowed size." error message is returned?

  • Cause: The size of the uploaded object exceeds the size range specified by the content-length-range parameter.

  • Solution: Add the content-length-range parameter to specify the minimum and maximum allowed sizes of the uploaded object. Unit: bytes. For example, if the size of the object that you want to upload is 1 GB, you can set the content-length-range parameter to ["content-length-range", 1, 1073741824].

References