Object Storage Service:HTTP 400 errors

Cause: The destination region specified in the cross-region replication (CRR) configuration does not exist.

Solution: Verify that the region of the destination bucket is valid.

Cause: The Origin request header is missing from the preflight request for a cross-origin request.

Solution: Before sending a cross-origin request, a browser sends a preflight request (OPTIONS) to OSS. This request must include the Origin header to identify the source domain of the cross-origin request. This ensures that the cross-origin resource sharing (CORS) policy is matched correctly.

Cause: The Access-Control-Request-Method request header is missing from the preflight request for a cross-origin request.

Solution: Before sending a cross-origin request, a browser sends a preflight request (OPTIONS) to OSS. This request must include the Access-Control-Request-Method header to identify the HTTP method used by the actual request. This allows OSS to verify whether the method is permitted.

Cause: A CRR relationship already exists between the source bucket and the destination bucket.

Solution: To configure a new CRR rule, you must first delete the existing CRR rule.

Cause: The number of CORS rules configured for the bucket exceeds the limit.

Solution: A bucket can have a maximum of 10 CORS rules. Exceeding this limit can make the cross-origin access policy too complex. You can merge similar cross-origin configurations or delete unnecessary rules. For more information, see PutBucketCors.

Cause: The number of objects in the bucket exceeds the limit for daily manifest file exports.

Solution: When you export a manifest file on a daily basis, the number of objects in the bucket must be less than 10 billion.

If the number of objects in the bucket is 10 billion or more, export the manifest file on a weekly basis instead.

Cause: The size of the uploaded object exceeds the maximum allowed size.

Solution: When you upload a file using the PostObject operation, set valid values for the form fields in the PostPolicy. Use the content-length-range condition to specify the allowed size range for the uploaded object. For more information, see Appendix: Post Policy.

Cause: The size of the uploaded object is smaller than the minimum allowed size.

Solution: When you upload a file using the PostObject operation, set valid values for the form fields in the PostPolicy. Use the content-length-range condition to specify the allowed size range for the uploaded object.

Cause: A form field in the PostObject request is too large.

Solution: Except for the file form field, the size of other form fields cannot exceed 4 KB. For more information, see Troubleshoot PostObject errors.

Cause: The requested part has been deleted.

Solution: Verify that all required parts have been successfully uploaded and have not been deleted. You can check the status of uploaded parts by calling the CompleteMultipartUpload operation.

Cause: The image size exceeds the limit.

Solution: Make sure that the source image file meets the following size limits:

• The size of the source image file cannot exceed 20 MB.

• When you rotate an image, the width or height of the source image cannot exceed 4,096 pixels.

• The length of a single side of the source image cannot exceed 30,000 pixels.

Cause: The number of bytes specified by the Content-Length parameter does not match the number of bytes actually sent.

Solution: Set the Content-Length parameter to the actual number of bytes sent.

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

Solution: Make sure that the PostObject request contains only one file form field.

Cause:

1. Object size limit exceeded: The size of the uploaded file exceeds the limit for the current upload operation.

2. Hotlink protection configuration limit exceeded: The total size of the Referer whitelist and blacklist configurations exceeds 20 KB.

Solution:

• Scenario 1: Object size limit exceeded

  Adjust the upload method based on the file size:

  • Simple/Form/Append upload: The maximum file size is 5 GB.

  • Multipart upload: The maximum file size is 48.8 TB.

• Scenario 2: Hotlink protection configuration limit exceeded

  Delete unnecessary hotlink protection rules to ensure that the total data size of the Referer whitelist and blacklist does not exceed 20 KB.

Cause: The AccessKey ID and Signature parameters are missing from the Authorization header calculation method.

Solution: Add the AccessKey ID parameter to the Authorization header calculation method and complete the signature calculation as shown in the following signature example.

Assume that the AccessKey ID is LTAI**************** and the AccessKey secret is yourAccessKeySecret. The following Python code provides an example of how to calculate the signature:

import hmac
import hashlib
import base64
import os

accessKeySecret = os.getenv('OSS_ACCESS_KEY_SECRET')
h = hmac.new(accessKeySecret.encode('utf-8'),
             "PUT\neB5************==\ntext/html\nWed, 28 Dec 2022 10:27:41 GMT\nx-oss-meta-author:alice\nx-oss-meta-magic:abracadabra\n/examplebucket/nelson".encode('utf-8'), hashlib.sha1)
signature =  base64.encodebytes(h.digest())
print(signature)

The calculated signature is 77Dv****************, which is combined with the structure of the Authorization header to form the message body to be sent:

PUT /nelson HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Wed, 28 Dec 2022 10:27:41 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com
x-oss-meta-author: alice
x-oss-meta-magic: abracadabra

Cause: An invalid parameter is specified in the Authorization header calculation method.

Solution: Troubleshoot the Authorization header calculation based on the following instructions.

• Calculation method:

  Authorization = "OSS " + AccessKeyId + ":" + Signature
  Signature = base64(hmac-sha1(AccessKeySecret,
              VERB + "\n"
              + Content-MD5 + "\n" 
              + Content-Type + "\n" 
              + Date + "\n" 
              + CanonicalizedOSSHeaders
              + CanonicalizedResource))

• Parameter descriptions:

  Parameter	Type	Required	Example	Description
  AccessKeyId	String	Yes	LTAI****************	The AccessKey ID of the key.
  AccessKeySecret	String	Yes	yourAccessKeySecret	The AccessKey secret of the key.
  VERB	Enumeration	Yes	PUT	The HTTP request method, such as PUT, GET, POST, HEAD, DELETE, or OPTIONS.
  \n	String	No	\n	A line feed.
  Content-MD5	String	No	eB5eJF1ptWaXm4bijSPyxw==	The MD5 hash of the request content data. To obtain this value, calculate the MD5 hash of the message content (excluding headers) to get a 128-bit number, and then Base64-encode the number. For more information, see RFC2616 Content-MD5. This request header can be used to check the integrity of the message (whether the message content is the same as when it was sent). This header can be empty. For information about how to calculate the Content-MD5 hash, see Calculate a Content-MD5 hash.
  Content-Type	String	No	application/octet-stream	The type of the request content. This header can be empty.
  Date	String	Yes	Sun, 22 Nov 2015 08:16:38 GMT	Important The time of the operation. The Date parameter must be in GMT format and cannot be empty. If the time difference between the Date in the request and the current time on the OSS server is more than 15 minutes, the OSS server rejects the request and returns an HTTP 403 error.
  CanonicalizedOSSHeaders	String	No	x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n	The HTTP headers that are prefixed with x-oss- and sorted in lexicographic order. This parameter can be empty. If you set CanonicalizedOSSHeaders to empty, you do not need to add the \n separator at the end. If there is only one CanonicalizedOSSHeaders, you must add the \n separator at the end, for example, x-oss-meta-a\n. If there are multiple CanonicalizedOSSHeaders, you must add the \n separator after each CanonicalizedOSSHeaders, for example, x-oss-meta-a:a\nx-oss-meta-b:b\nx-oss-meta-c:c\n. For information about how to construct CanonicalizedOSSHeaders, see Construct CanonicalizedOSSHeaders.
  CanonicalizedResource	String	Yes	/examplebucket/	The OSS resource that you want to access. This parameter cannot be empty. For information about how to construct CanonicalizedResource, see Construct CanonicalizedOSSHeaders.

• Signature example:

  Request	Signature string calculation formula	Signature string
  PUT /nelson HTTP/1.0 Content-MD5: eB5eJF1ptWaXm4bijSPyxw== Content-Type: text/html Date: Wed, 28 Dec 2022 10:27:41 GMT Host: examplebucket.oss-cn-hangzhou.aliyuncs.com x-oss-meta-author: alice x-oss-meta-magic: abracadabra	Signature = base64(hmac-sha1(AccessKeySecret,VERB + "\n" + Content-MD5 + "\n"+ Content-Type + "\n" + Date + "\n" + CanonicalizedOSSHeaders+ CanonicalizedResource))	PUT\n eB5eJF1ptWaXm4bijSPyxw==\n text/html\n Wed, 28 Dec 2022 10:27:41 GMT\n x-oss-meta-magic:abracadabra\nx-oss-meta-author:alice\n/examplebucket/nelson

  Assume that the AccessKey ID is LTAI**************** and the AccessKey secret is yourAccessKeySecret. The following Python code provides an example of how to calculate the signature:

  import hmac
  import hashlib
  import base64
  import os
  
  accessKeySecret = os.getenv('OSS_ACCESS_KEY_SECRET')
  h = hmac.new(accessKeySecret.encode('utf-8'),
               "PUT\neB5************==\ntext/html\nWed, 28 Dec 2022 10:27:41 GMT\nx-oss-meta-author:alice\nx-oss-meta-magic:abracadabra\n/examplebucket/nelson".encode('utf-8'), hashlib.sha1)
  signature =  base64.encodebytes(h.digest())
  print(signature)

  The calculated signature is 77Dv****************, which is combined with the structure of the Authorization header to form the message body to be sent:

  PUT /nelson HTTP/1.0
  Authorization:OSS qn6q**************:77Dv****************
  Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
  Content-Type: text/html
  Date: Wed, 28 Dec 2022 10:27:41 GMT
  Host: oss-example.oss-cn-hangzhou.aliyuncs.com
  x-oss-meta-author: alice
  x-oss-meta-magic: abracadabra

Cause: An incorrect parameter is specified in the Authorization header calculation method.

Solution: Complete the Authorization header calculation based on the parameter descriptions in the following table.

Cause: A required parameter in the Authorization header calculation method is empty.

Solution: Complete the Authorization header calculation based on the parameter descriptions in the following table.

Cause: The time parameter is invalid.

Solution: The time format must comply with the RFC 1123 standard, for example, Sun, 06 Nov 1994 08:49:37 GMT.

Cause: The Host is invalid.

Solution: The Host can be a bucket domain name or an IP address. The bucket domain name format is BucketName.Endpoint, for example, examplebucket.oss-cn-hangzhou.aliyuncs.com. If the Host is an IP address, make sure that the IP address is valid.

Cause: The source bucket and source object are not specified when you copy a file.

Solution: When you copy a file, you must specify the x-oss-copy-source parameter in the /sourcebucket/sourcekey format. For example, if the source bucket is examplebucket and the source object is exampleobject, set the x-oss-copy-source parameter to /examplebucket/exampleobject.

Cause: The callback parameter is included in both the request URL and the request header.

Solution: The callback parameter can be included in either the request URL or the request header, but not both.

Cause: The callback-var parameter is included in both the request URL and the request header.

Solution: The callback-var parameter can be included in either the request URL or the request header, but not both.

Cause

In the same request, the Authorization field for signing is present in the request header, and the OSSAccessKeyId, Expires, and Signature fields for signing are present in the request URI. Example:

PUT /example_file?OSSAccessKeyId=LTAI****************&Expires=1141889120&Signature=vjbyPxybdZaNmGa%2ByT272YEAiv**** HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

Solution

In the same request, use either header signing or URI signing, but not both. The following code provides an example of using only header signing:

PUT /example_file HTTP/1.0
Authorization:OSS qn6q**************:77Dv****************
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

The following code provides an example of using only URI signing:

PUT /example_file?OSSAccessKeyId=LTAI****************&Expires=1141889120&Signature=vjby******** HTTP/1.0
Content-Md5: eB5eJF1ptWaXm4bijSPyxw==
Content-Type: text/html
Date: Tue, 20 Dec 2022 08:48:18 GMT
Host: oss-example.oss-cn-hangzhou.aliyuncs.com

Cause: The parameter format is invalid.

Solution: See the corresponding API operation in API overview and specify the parameters in the correct format.

Cause: The time parameter is invalid. The UNIX timestamp is later than the current time.

Solution: The UNIX timestamp must be earlier than the current time.

Cause: The time parameter is invalid. The UNIX timestamp is less than 0.

Solution: The UNIX timestamp must be greater than 0.

Cause: The specified object version ID is invalid.

Solution: Call the GetBucketVersions (ListObjectVersions) operation to confirm whether versioning is enabled for the bucket and whether the specified version ID of the object is correct.

Cause: The KMSMasterKeyID parameter is specified when the server-side encryption (SSE) algorithm is set to AES256.

Solution: The KMSMasterKeyID parameter is required only when the SSE algorithm is set to KMS and a specified key is used for encryption.

Cause: The user does not have the required permissions.

Solution: Only the bucket owner or an authorized RAM user can set encryption rules for a bucket. For more information, see PutBucketEncryption.

Cause: The specified bucket storage class does not exist.

Solution: OSS supports the following storage classes: Standard, Infrequent Access (IA), Archive Storage, Cold Archive, and Deep Cold Archive. For more information, see PutBucket.

Cause: The Date in the Authorization header is invalid.

Solution: The Date parameter indicates the time of the operation and must be in GMT format, for example, Sun, 22 Nov 2015 08:16:38 GMT.

Cause: The total length of the body in the PostObject request exceeds 5 GB.

Solution: The total length of the body in a PostObject request cannot exceed 5 GB. For more information, see PostObject.

Cause: The OSSAccessKeyId form field is missing from the PostObject request header.

Solution: The OSSAccessKeyId form field is required if the bucket is not public-read-write or if the Policy (or Signature) form field is provided.

Cause: The signature information is missing from the PostObject request header.

Solution: The Signature form field is required if the bucket is not public-read-write or if the OSSAccessKeyId (or Policy) form field is provided. The following steps describe how to calculate the signature:

1. Create a policy in UTF-8 encoding.

2. Base64-encode the policy. The result is the value of the Policy form field. Use this value as the string to be signed.

3. Use the AccessKey secret to sign the string. The signature method is Signature = base64(hmac-sha1(base64(policy), AccessKeySecret)).

Cause: OSS cannot send a callback request to a private IP address.

Solution: Use a public IP address to send the callback request.

Cause: The line following the filename field contains a custom parameter.

Solution: The line following the filename field must be a standard Content-Type parameter, as shown in the following figure:

Cause: The key form field is not specified in the PostObject request, or the order of the key form field is incorrect.

Solution: Specify the key form field in the PostObject request. The key form field must precede the file form field. For more information, see PostObject.

Cause: The POST request form contains an invalid parameter or a parameter in an incorrect format.

Solution: Specify the parameters in the standard format. For more information, see PostObject.

Cause: The callbackBody parameter is not specified.

Solution: The Callback parameter must be a Base64-encoded JSON string. You must specify the server URL for the callback (callbackUrl) and the content of the callback (callbackBody).

Cause: The callbackBody parameter is invalid and cannot be parsed as JSON.

Solution: The callbackBody parameter specifies the value of the request body when a callback is initiated, for example, key=$(object)&etag=$(etag)&my_var=$(x:my_var). For troubleshooting, see Callback.

Cause: The callbackBodyType parameter is invalid and cannot be parsed as JSON.

Solution: The callbackBodyType parameter specifies the Content-Type of the callback request. Supported values are application/x-www-form-urlencoded and application/json.

Cause: The Callback parameter is not Base64-encoded.

Solution: The Callback parameter must be a Base64-encoded JSON string. You must specify the server URL for the callback and the content of the callback. For more information, see Callback.

Cause: The Callback parameter is not in JSON format.

Solution: The Callback parameter must be a Base64-encoded JSON string. Example:

{
"callbackUrl":"121.101.XX.XX/test.php",
"callbackHost":"oss-cn-hangzhou.aliyuncs.com",
"callbackBody":"{\"mimeType\":${mimeType},\"size\":${size}}",
"callbackBodyType":"application/json"
}

Cause: The callbackHost parameter is invalid and cannot be parsed as JSON.

Solution: The callbackHost parameter specifies the Host header of the callback request, for example, oss-cn-hangzhou.aliyuncs.com. If callbackHost is not configured, the URL in callbackUrl is parsed, and the Host parsed from the URL is used as the value of callbackHost.

Cause: The signature version is not supported.

Solution: Confirm that the current signature is version 1.0 or 2.0.

Cause: The server URL for the callback (callbackUrl) is not specified in the Callback parameter.

Solution: The Callback parameter must be a Base64-encoded JSON string. You must specify the server URL for the callback and the content of the callback.

Cause: The callback-var parameter is not in JSON format.

Solution: The callback-var parameter is used to configure custom parameters. Custom parameters are specified as key-value pairs. Keys must start with x: and be in lowercase. For example, to set two keys, x:var1 and x:var2, with the corresponding values value1 and value2, the JSON format is as follows:

{
"x:var1":"value1",
"x:var2":"value2"
}

Cause: The format of the custom header is incorrect.

Solution: The format of a custom header is x-oss-persistent-headers: key1:base64_encode(value1),key2:base64_encode(value2)..... In this format, key1 and key2 are custom headers, and value1 and value2 are their corresponding values. base64_encode indicates that the values of the custom headers are Base64-encoded. For example, if the custom headers are myheader1 and myheader2, and their values are myvalue1 and myvalue2, the custom request header should be x-oss-persistent-headers:myheader1:bXl2YWx1ZTE=,myheader2:bXl2YWx1ZTI=.

Cause: The key and value of the tag are not URL-encoded, and the key is duplicated.

Solution: Object tagging uses a set of key-value pairs to mark an object. The following rules apply to object tags:

• An object can have a maximum of 10 tags. Keys must be unique.

• Each key can be up to 128 characters in length, and each value can be up to 256 characters in length.

• Keys and values are case-sensitive.

• The valid character set for tags includes uppercase letters, lowercase letters, digits, spaces, and the following special characters: + - = . _ : / When you set tags using HTTP headers and the tags contain any of these characters, you must URL-encode the keys and values of the tags.

Cause: The custom header contains invalid characters.

Solution: OSS complies with the RFC 7230 specification and determines whether an HTTP header contains invalid characters based on this specification.

Cause: The custom header conflicts with a standard HTTP header.

Solution: Do not specify standard HTTP headers, such as Host, Content-MD5, Origin, or Range, in the custom header.

Cause: The value of the custom header contains a carriage return \r or a line feed \n.

Solution: Remove the carriage return \r and line feed \n from the value of the custom header.

Cause: The custom header has the same name as a request header, but their values are different.

Solution: If a custom header has the same name as a request header, their values must be the same.

Cause: The value of the custom header is invalid.

Solution: UTF-8 encode special characters, such as Chinese characters, in the value of the custom header.

Cause: The total length of the Base64-encoded callback parameter exceeds 5 KB.

Solution: The total length of the Base64-encoded callback parameter cannot exceed 5 KB.

Cause: The total length of the Base64-encoded callback-var parameter exceeds 5 KB.

Solution: The total length of the Base64-encoded callback-var parameter cannot exceed 5 KB.

Cause: The number of requested callback URLs exceeds 5.

Solution: OSS lets you configure a maximum of five URLs at the same time. Separate each URL with a semicolon (;).

Cause: The versioning status of the bucket is not specified in the <VersioningConfiguration> field.

Solution: Specify the versioning status of the bucket in the <VersioningConfiguration> field. Example:

PUT /?versioning HTTP/1.1
Host: bucket-versioning.oss-cn-hangzhou.aliyuncs.com
Date: Tue, 09 Apr 2019 02:20:12 GMT
Authorization: OSS qn6q**************:77Dv****************
<?xml version="1.0" encoding="UTF-8"?>
<VersioningConfiguration>
    <Status>Enabled</Status>
<VersioningConfiguration>

Cause: An unknown parameter is present in the Authorization header calculation method.

Solution: Complete the Authorization header calculation based on the parameter descriptions in the following table.

Cause: The VersionId field is not specified.

Solution: Specify the version ID of the object in the VersionId field. For more information, see ListObjectVersions (GetBucketVersions).

Cause: The value for single-connection bandwidth throttling is invalid.

Solution: The value for single-connection bandwidth throttling must be in the range of 819,200 to 838,860,800, which is equivalent to 100 KB/s to 100 MB/s.

Cause: The single-connection bandwidth throttling parameter x-oss-traffic-limit is included in both the request URL and the request header.

Solution: The single-connection bandwidth throttling parameter x-oss-traffic-limit can be included in either the request URL or the request header, but not both.

Cause: The bucket name does not comply with the naming conventions.

Solution: Check and make sure that the bucket name complies with the naming conventions. The following rules apply to bucket names:

• Can contain only lowercase letters, digits, and hyphens (-).

• Must start and end with a lowercase letter or a digit.

• Must be 3 to 63 characters in length.

Cause: The versioning status of the source bucket and the destination bucket for CRR are inconsistent.

Solution: For CRR, versioning must be either enabled or disabled for both the source and destination buckets.

Cause: The channel name field is missing.

Solution: Specify the channel name according to the naming conventions.

• Use UTF-8 encoding.

• Must be 1 to 64 characters in length.

• Cannot contain forward slashes (/) or backslashes (\).

Cause: The channel name contains a slash.

Solution: Make sure that the channel name does not contain a forward slash (/) or a backslash (\).

Cause: The encoding of the channel name is incorrect.

Solution: The channel name must be UTF-8 encoded.

Cause: The length of the channel name exceeds the limit.

Solution: Make sure that the channel name is 1 to 64 characters in length.

Cause: The locally calculated CRC-64 value does not match the CRC-64 value returned by the server.

Solution: For troubleshooting, see Use CRC-64 to verify data integrity.

Cause: The specified object encryption algorithm is invalid.

Solution: When the object is encrypted using KMS, only the SM4 encryption algorithm is supported. For more information, see Server-side encryption.

Cause: The Content-MD5 request header of the upload does not match the Content-MD5 hash of the message body calculated by OSS.

Solution: For troubleshooting, see Calculate a Content-MD5 hash.

Cause: The value specified for the x-oss-server-side-encryption parameter is invalid.

Solution: Valid values for x-oss-server-side-encryption are AES256, KMS, and SM4. For more information about server-side encryption methods, see PutObject.

Cause: The UploadPartCopy operation cannot be called on a source file that has been encrypted on the client.

Solution: You can call the UploadPartCopy operation only on a source file that has not been encrypted on the client to copy data from an existing object to upload a part. For more information, see UploadPartCopy.

Cause: A required parameter for client-based encryption is missing.

Solution: Make sure that you have specified all of the following required parameters.

Cause: The total file size or part size entered in the client-based encryption metadata is invalid.

Solution: When you perform a client-based multipart upload, you must pass the total size of the large file (x-oss-meta-client-side-encryption-data-size) and the part size (x-oss-meta-client-side-encryption-part-size) during the multipart upload initialization. The part size must be an integer multiple of 16. For more information, see Client-side encryption (Java SDK V1).

Cause: The part encryption information configured for client-based encryption is inconsistent with the encryption information set during multipart upload initialization.

Solution: Make sure that the part encryption information configured for the client is consistent with the encryption information set during multipart upload initialization. For more information, see Client-side encryption (Java SDK V1).

Cause: The number of parts actually uploaded is inconsistent with the number of parts specified during multipart upload initialization.

Solution: Make sure that the specified number of parts is consistent with the number of parts actually uploaded.

Cause: The total size of all parts actually uploaded is inconsistent with the total part size specified during multipart upload initialization.

Solution: After you upload the last part, make sure that the total size of all parts actually uploaded is consistent with the total part size specified during multipart upload initialization. For more information, see CompleteMultipartUpload.

Cause: The CopyObject operation is used to modify client-based encryption metadata.

Solution: After a file is uploaded with client-based encryption, the encryption metadata is protected and cannot be modified using the CopyObject operation to change the object metadata. For more information, see CopyObject.

Cause: The part ID is greater than the total number of parts (PartNumber).

Solution: Make sure that the part ID is less than or equal to the total number of parts. For more information, see UploadPart.

Cause: The number of parts entered in the client-based encryption metadata exceeds the limit.

Solution: Each object can be divided into a maximum of 10,000 parts.

Cause: The size of each part actually uploaded is inconsistent with the size of each part specified during multipart upload initialization.

Solution: Except for the last part, the size of all other parts must be consistent with the size of each part specified during multipart upload initialization. For more information, see UploadPart.

Cause: The Host parameter is incorrect.

Solution: Use a standard endpoint. For more information about endpoints and data centers, see Endpoints and data centers.

Cause: The length of the object name exceeds the limit.

Solution: Make sure that the object name is 1 to 1,023 characters in length.

Cause: The object name is not specified.

Solution: Specify the object name according to the object naming conventions.

Cause: The specified object name is invalid.

Solution: Check and make sure that the object name complies with the naming conventions. The following rules apply to object names:

• Use UTF-8 encoding.

• Must be 1 to 1,023 characters in length.

• Cannot start with a forward slash (/) or a backslash (\).

Cause: The specified CMK ID is invalid.

Solution: When an object is encrypted using KMS and a specified key is used, you must enter the CMK ID. Example CMK ID: 9468da86-3509-4f8d-a61e-6eab1eac****.

Cause: The part submitted by CompleteMultipartUpload is invalid due to an incorrect PartNumber or ETag.

Solution: The server verifies the PartNumber and ETag when the CompleteMultipartUpload operation is called.

• The PartNumber must be an integer from 1 to 10,000. The PartNumbers do not have to be consecutive, but they must be in ascending order. For example, the PartNumber of the first part can be 1, and the PartNumber of the second part can be 5.

• For an object created by a CompleteMultipartUpload request, the ETag value is the UUID of its content. The ETag value can be used to check whether the object content has changed.

Cause: The PartNumber is invalid.

Solution: Make sure that the PartNumber is an integer from 1 to 10,000. For more information, see CompleteMultipartUpload.

Cause: The parts submitted by CompleteMultipartUpload are not sorted in ascending order by part number.

Solution: The parts submitted by CompleteMultipartUpload must be sorted in ascending order by part number. For example, the PartNumber of the first part can be 1, and the PartNumber of the second part can be 5. For more information, see CompleteMultipartUpload.

Cause: The Policy in the request has an incorrect format.

Solution: Check whether the Policy is missing a , or ].

Cause: The Policy in the request has an incorrect format.

Solution: Check the Policy format. Check whether it is missing a " or whether an escape character is missing a \.

Cause: The request Policy does not contain conditions.

Solution: The request Policy must contain at least one conditions element.

Cause: The key or value of the bucket tag is invalid.

Solution: Ensure that the bucket tag complies with the following naming rules:

• The key and value must be UTF-8 encoded.

• The key can be up to 64 characters long, cannot start with http://, https://, or Aliyun, and cannot be empty.

• The value can be up to 128 characters long and can be empty.

Cause: The key of the object tag is invalid.

Solution: Object tagging uses a set of key-value pairs to mark an object. The following rules apply to object tags:

• A key can be up to 128 characters in length, and a value can be up to 256 characters in length.

• Keys and values are case-sensitive.

• The valid character set for tags includes uppercase letters, lowercase letters, digits, spaces, and the following special characters: +, -, =, ., _, :, and /. If you use HTTP headers to set tags that contain any of these special characters, you must URL-encode the tag keys and values.

Cause: The specified destination bucket is invalid for replication.

Solution: Call the GetBucketReplicationLocation operation to retrieve the valid destination regions for replication.

Cause: The destination bucket for storing logs does not exist.

Solution: Specify a valid destination bucket.

Cause: The bucket does not exist in the destination region.

Solution: Verify the region where the bucket is located.

Cause: The symbolic link points to another symbolic link.

Solution: Ensure that the target of the symbolic link is not another symbolic link.

Cause: The retention policy is invalid.

Solution: The following code shows an example of creating a retention policy using the InitiateBucketWorm operation:

POST /?worm HTTP/1.1
Date: Thu, 15 May 2014 11:18:32 GMT
Content-Length: 556
Content-Type: application/xml
Host: BucketName.oss.aliyuncs.com
Authorization: OSS qn6q**************:77Dv****************

<InitiateWormConfiguration>
  <RetentionPeriodInDays>365</RetentionPeriodInDays>
</InitiateWormConfiguration>

Cause: The request parameters are not in a valid XML format.

Solution: Ensure that the request parameters are in a valid XML format.

Cause: The number of inventory rules for a single bucket has reached the maximum limit of 1,000.

Solution: To increase the limit on the number of inventory rules, submit a ticket.

Cause: You attempted to use KMS for server-side encryption before activating the KMS service.

Solution: Activate the KMS service. For more information, see Activate Key Management Service.

Cause: A form field in the PostObject request is not correctly formatted.

Solution: Ensure that the form fields follow the required format. The format of a form field is as follows:

Content-Disposition: form-data;
        name="{key}"\r\n\r\n{value}\r\n--{boundary}

The following code provides an example of a PostObject request:

POST / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-CN; rv:1.9.2.6)
Content-Type: multipart/form-data; boundary=9431149156168
Host: xxxx-hz.oss-cn-hangzhou.aliyuncs.com
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
Content-Length: 5052
--9431149156168
Content-Disposition: form-data; name="key"
test-key
--9431149156168
Content-Disposition: form-data; name="Content-Disposition"
attachment;filename=D:\img\example.png
--9431149156168
Content-Disposition: form-data; name="OSSAccessKeyId"
2NeL********j2Eb

The requirements are as follows:

• The header must include Content-Type: multipart/form-data; boundary={boundary}.

• The header and body are separated by \r\n--{boundary}. The \r\n characters represent a line break.

• Form field names are case-sensitive, such as policy, key, file, OSSAccessKeyId, OSSAccessKeyId, and Content-Disposition.

• The file form field must be the last form field.

• If the bucket is public-read-write, you do not need to specify the OSSAccessKeyId, policy, and Signature form fields. If you specify one of these fields, you must specify the other two, regardless of whether the bucket is public-read-write.

For more information, refer to the following code examples:

• C#

• Java

• JavaScript

Cause: The XML format in the request is invalid.

Solution: To troubleshoot this error, refer to the documentation for the relevant request:

• DeleteMultipleObjects

• CompleteMultipartUpload

• PutBucketLogging

• PutBucketWebsite

• PutBucketLifecycle

• PutBucketReferer

• PutBucketCORS

Cause: The uploaded file is too large. The maximum size for a file uploaded using the Post method is 5 GB.

Solution: For more information, see Troubleshoot PostObject errors.

Cause: The AccessKey ID is missing.

Solution: Specify the correct AccessKey ID.

Cause: The API call is missing a required parameter.

Solution: Refer to the API documentation in the API overview and add all required parameters.

Cause: The data center of the source bucket does not have a paired data center for CRR.

Solution: To obtain a list of available destination regions for replication, see GetBucketReplicationLocation.

Cause: No CRR rule is configured for the requested bucket.

Solution: Configure a CRR rule for the bucket. For more information, see PutBucketReplication.

Cause: An incorrect or unsupported parameter was passed in the API request.

Solution: Refer to the corresponding API documentation in the API overview and use the correct and supported parameter format.

Cause: The target object is not a symbolic link.

Solution: Ensure that the PutSymlink or GetSymlink operations are performed only on symbolic links.

Cause: The requested operation is not supported for the specified resource. Possible scenarios include the following:

• You attempt to convert an Appendable object or a symbolic link to the Cold Archive or Deep Cold Archive storage class.

• You use the RestoreObject operation to restore an object that is not in the Archive Storage, Cold Archive, or Deep Cold Archive storage class.

Solution:

• You can call the PutObject operation to upload an object with the same name to overwrite the Appendable object with a Normal object. You can then convert the object to the Cold Archive or Deep Cold Archive storage class.

• When you use the RestoreObject operation to restore a file, ensure that the file is in the Archive Storage, Cold Archive, or Deep Cold Archive storage class.

For more information about the types of operations supported by various resources, see API overview.

Cause: The specified tag key already exists.

Solution: Call GetBucketTags to retrieve the existing tags for the bucket, and then call PutBucketTags to configure new tags.

Cause: The form submitted by the PostObject operation is not encoded as multipart/form-data.

Solution: The form submitted by a PostObject operation must be encoded as multipart/form-data. This requires the Content-Type in the header to be in the format multipart/form-data;boundary=xxxxxx, where boundary is the boundary string. For more information, see PostObject.

Cause: A network timeout occurred because of the network environment or a network configuration.

Solution: For troubleshooting, see Handle network timeouts.

Cause: The number of buckets created by a single Alibaba Cloud account in a region has reached the maximum limit of 100.

Solution:

• A bucket does not have a capacity limit. You can create folders in a bucket to organize your content. For more information about how to create a folder, see Create a folder.

• Delete buckets that you no longer need. For more information about how to delete a bucket, see Delete a bucket.

  Important

  Deleted buckets cannot be recovered. Proceed with caution.

• To increase the bucket quantity limit, submit a ticket.

Cause: The number of domain names that can be attached to a bucket has reached the maximum of 100.

Solution: You can submit a ticket to increase the limit on the number of domain names for a bucket.

Cause: The number of object tags configured in the CRR rule exceeds the limit.

Solution: You can add a maximum of 10 object tags to a CRR rule to filter objects for synchronization.

Cause: The number of CRR rules associated with the bucket has reached 100.

Solution: A single bucket supports up to 100 CRR rules. If your business requirements exceed this limit, you can submit a ticket.

Cause: The number of CRR rules associated with the bucket has reached the limit of 100.

Solution: A single bucket supports up to 100 CRR rules. If your business requirements exceed this limit, submit a ticket.

Cause: The request includes too many image operations.

Solution: Reduce the number of image operations in your request.

Cause: More than 10 prefixes are specified in the CRR rule.

Solution: For cross-region replication, you can specify up to 10 prefixes to sync only matching objects to the destination Bucket.

Cause: You configured more than one replication rule for a single bucket.

Solution: You can configure only one replication rule for a bucket.

Cause: The number of tags for the bucket exceeds the limit.

Solution: A bucket can have a maximum of 20 tags. For more information, see PutBucketTags.

Cause: An object name was not specified for the delete operation.

Solution: Specify the name of the object to delete. For more information, see DeleteMultipleObjects.

Cause: The number of objects in the bucket exceeds the limit for weekly manifest file exports.

Solution: The number of objects in a bucket must be less than 50 billion for a weekly manifest file export.

When a bucket contains 50 billion or more files:

• Export the objects in batches by matching prefixes.

• Submit a ticket to request an increase in the object export limit.