このトピックでは、Post Object を使用するときの一般的なエラーとその解決策について説明します。
Post Object の概要
Post Object を使用すると、フォームを介して OSS にファイルをアップロードできます。 メッセージエンティティは multipart/form-data 形式でエンコードされます。 詳細については、「RFC 2388」をご参照ください。 HTTP リクエストヘッダーを介してパラメーターを渡す PutObject とは異なり、Post Object はメッセージ本文内のフォームフィールドとしてパラメーターを送信します。
Post Object メッセージは、メッセージヘッダー(Header)とメッセージ本文(Body)で構成され、\r\n--{boundary} で区切られます。 Body には、次のようにフォーマットされた一連のフォームフィールドが含まれています。
Content-Disposition: form-data; name="{key}"\r\n\r\n{value}\r\n--{boundary}
一般的なヘッダーは、Host、User-Agent、Content-Length、Content-Type、Content-MD5 などで構成されます。 フォームフィールドには、key、OSSAccessKeyId、Signature、Content-Disposition、オブジェクトのメタデータ(x-oss-meta-*)、x-oss-security-token、および Cache-Control、Content-Type、Content-Disposition、Content-Encoding、Expires などの追加の HTTP ヘッダーが含まれます。 file は、最後のフォームフィールドとして配置する必要があります。
詳細については、「Post Object」をご参照ください。
Post Object での一般的なエラー
次の表に、Post Object で発生する一般的なエラーを示します。
序数 | エラー | 原因 | 解決策 |
1 | ErrorCode: MalformedPOSTRequest ErrorMessage: The body of your POST request is not well-formed multipart/form-data. | フォームフィールドの形式が要件を満たしていません。 | 表の後に記載されている Post Object フォームフィールドの形式のガイドラインを参照してください。 |
2 | ErrorCode: InvalidAccessKeyId ErrorMessage: The OSS Access Key Id you provided does not exist in our records. | AccessKeyIDが無効、存在しない、一時ユーザーの期限切れ、または STS トークンが提供されていません。 | トラブルシューティングについては、「InvalidAccessKeyId エラーのトラブルシューティング」をご参照ください。 |
3 | ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy expired. | ポリシーフォームフィールドの有効期限が過ぎています。 | ポリシーの有効期限を調整し、形式が ISO8601 GMT であることを確認します。 |
4 | ErrorCode: AccessDenied ErrorMessage: SignatureDoesNotMatch The request signature we calculated does not match the signature you provided. Check your key and signing method. | 署名不一致が発生しました。 | 以下の Post Object 署名セクションで詳しく説明されている署名方法を確認してください。 |
5 | ErrorCode: InvalidPolicyDocument ErrorMessage: Invalid Policy: Invalid Simple-Condition: Simple-Conditions must have exactly one property specified. | リクエストのポリシーには、少なくとも 1 つの条件が含まれている必要があります。 | フォームフィールドの形式セクションの後の表で詳しく説明されている Post Object ポリシーの形式を参照してください。 |
6 | ErrorCode: InvalidPolicyDocument ErrorMessage: Invalid Policy: Invalid JSON: unknown char e | リクエストのポリシー形式が正しくありません。 | ポリシー形式を確認し、欠落している引用符がないか確認し、エスケープ文字 |
7 | ErrorCode: InvalidPolicyDocument ErrorMessage: Invalid Policy: Invalid JSON: , or ] expected | リクエストのポリシー形式が正しくありません。 | ポリシーに |
8 | ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“starts-with”, “$key”, “user/eric/“] | リクエストで指定されたキーがポリシーの制限と一致しません。 | リクエストのフォームフィールドの key 値を確認します。 |
9 | ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“eq”, “$bucket”, “mingdi-bjx”] | リクエストで指定されたバケットがポリシーの制限と一致しません。 | エンドポイントのバケット値を確認します。 |
10 | ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“starts-with”, “$x-oss-meta-prop”, “prop-“] | リクエストで指定されたオブジェクトのメタデータ x-oss-meta-prop がポリシーの制限と一致しません。 | リクエストの x-oss-meta-prop 値を確認します。 |
11 | ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“eq”, “${field}”, “${value}”] | フォームフィールドで指定された {field} がポリシーの値と一致しないか、リクエストで指定されていません。 | リクエストの {field} 値を確認します。 |
12 | ErrorCode: AccessDenied ErrorMessage: You have no right to access this object because of bucket acl. | 現在のユーザーに必要な権限がありません。 | 詳細については、「OSS 権限の問題とトラブルシューティング」をご参照ください。 |
13 | ErrorCode: InvalidArgument ErrorMessage: The bucket POST must contain the specified ‘key’. If it is specified, please check the order of the fields | フォームフィールドで key が省略されているか、file フォームフィールドの後に配置されています。 | key フォームフィールドを追加するか、file フィールドの前に来るように順序を調整します。 |
Post Object フォームフィールドの形式
Post Object リクエスト形式に関して、以下の点に注意してください。
Header には、
Content-Type: multipart/form-data; boundary={boundary}が含まれている必要があります。Header と Body は、
\r\n--{boundary}で区切られます。フォームフィールドの形式は、次のコードブロックで詳しく説明されています。
Content-Disposition: form-data; name="{key}"\r\n\r\n{value}\r\n--{boundary}フォームフィールド名では大文字と小文字が区別されます(policy、key、file、OSSAccessKeyId、Content-Disposition など)。
重要file フォームフィールドは最後のフォームフィールドである必要があります。
fileバケットが公開読み書きの場合、OSSAccessKeyId、policy、および Signature フォームフィールドを指定しないことを選択できます。 これらのいずれかが指定されている場合、バケットの権限に関係なく、他の 2 つも提供する必要があります。
public-read-write
Post Object リクエストの例を次に示します。
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: mingdi-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\1.png --9431149156168 Content-Disposition: form-data; name="OSSAccessKeyId" 2NeL********j2Eb説明上記の例では、
\r\nは改行を表します。 この形式は、後続の例でも使用されます。この例はリクエストコンテンツの一部です。 完全なリクエストについては、「Post Object」をご参照ください。
さらに質問がある場合は、サンプルコードを参照してください。
Post Object ポリシーの形式
Post Object リクエストでは、
policyフォームフィールドでリクエストの有効性を検証し、満たす必要のある条件を指定します。UTF-8 形式の JSON テキスト。Base64 でエンコードされ、policy フォームフィールドに配置されます。
ポリシーには、expiration と conditions が含まれている必要があり、conditions 配列には少なくとも 1 つの条件が含まれている必要があります。
Base64 エンコード前のポリシーの例を次に示します。
{ "expiration": "2018-01-01T12:00:00.000Z", "conditions": [ ["content-length-range", 0, 104857600] ] }expirationフィールドは、リクエストの有効期限を ISO8601 GMT 形式で定義します。 たとえば、2018-01-01T12:00:00.000Zは、リクエストを 2018 年 1 月 1 日 12:00 前に行う必要があることを示します。Post ポリシーでは、次の条件がサポートされています。
名前
説明
例
bucket
ファイルをアップロードするバケットの名前。 完全一致をサポートします。
{“bucket”: “johnsmith” } または [“eq”, “$bucket”, “johnsmith”]
key
アップロードするファイルの名前。 完全一致とプレフィックス一致をサポートします。
[“starts-with”, “$key”, “user/etc/]”
content-length-range
アップロードされたファイルに許可される最小長と最大長。
[“content-length-range”, 0, 104857600]
x-oss-meta-*
指定されたオブジェクトのメタデータ。 完全一致とプレフィックス一致をサポートします。
[“starts-with”, “$x-oss-meta-prop”, “prop-“]
success_action_redirect
オブジェクトのアップロード後にクライアントがリダイレクトされる URL。 完全一致とプレフィックス一致をサポートします。
[“starts-with”, “$success_action_redirect”, “http://www.aliyun.com”]
success_action_status
success_action_redirect が指定されていない場合に、オブジェクトのアップロード後に返される HTTP ステータスコード。 完全一致とプレフィックス一致をサポートします。
[“eq”, “$success_action_status”, “204”]
Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires など
HTTP リクエストヘッダー。フォームフィールドとして渡されます。 完全一致とプレフィックス一致をサポートします。
[“eq”, “$Content-Encoding”, “ZLIB”]
Post ポリシーでは、
\の後に続く次のエスケープ文字を使用してエスケープします。エスケープ文字
説明
/
スラッシュ
\
バックスラッシュ
“
二重引用符
$
ドル記号
\b
バックスペース
\f
フォームフィード
\n
改行
\r
キャリッジリターン
\t
水平タブ
\uxxxx
Unicode 文字
Post ポリシーの包括的な概要については、「Post ポリシー」をご参照ください。
Post Object 署名
認証付き Post リクエストには、AccessKeyID、policy、および Signature フォームフィールドを含める必要があります。 署名の計算プロセスは次のとおりです。
UTF-8 エンコードのポリシーを作成します。
UTF-8ポリシーを base64 でエンコードします。 このエンコードされた値は、policy フォームフィールドの値と署名する文字列です。
Base64AccessKeySecret を使用して文字列に署名します。最初に hmac-sha1 ハッシュを使用し、次に base64 エンコードを使用します。 署名方法は、ヘッダー署名と一致しています。
AccessKeySecretヘッダー署名
署名は次のように計算されます。
Signature = base64(hmac-sha1(AccessKeySecret, base64(policy)))以下に示すように、計算された署名を
Signatureフォームフィールドで指定できます。Content-Disposition: form-data; name="Signature" {signature} --9431149156168さらに質問がある場合は、サンプルコードを参照してください。
FAQ
key を指定する方法
このコンテキストでは、「key」という用語はオブジェクト名を参照し、
keyフォームフィールドで指定されます。次に例を示します。Content-Disposition: form-data; name="key" {key} --9431149156168オブジェクトコンテンツを指定する方法
次の例に示すように、
fileフォームフィールドでオブジェクトコンテンツを指定します。Content-Disposition: form-data; name="file"; filename="images.png" Content-Type: image/png {file-content} --9431149156168説明file フォームフィールドは、フォームの最後のフィールドである必要があります。つまり、他のすべてのフォームフィールドの後にある必要があります。
filefileファイル名は、オブジェクト名ではなく、アップロードされるローカルファイルの名前です。
filename
オブジェクトタイプ content-type を指定する方法
Header の
Content-Typeではなく、fileフォームフィールドContent-Typeでオブジェクトタイプを指定します。次に例を示します。Content-Disposition: form-data; name="file"; filename="images.png" Content-Type: image/png {file-content} --9431149156168オブジェクトコンテンツ md5 チェックサム content-md5 を指定する方法
Post Object リクエストヘッダーに
Content-MD5を含めます。 MD5 ハッシュは本文全体のハッシュ、つまりすべてのフォームフィールドのハッシュを表すことに注意することが重要です。 リクエストヘッダーの例を次に示します。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 Content-MD5: tdqHe4hT/TuKb7Y4by+nJg== Host: mingdi-hz.oss-cn-hangzhou.aliyuncs.com Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Content-Length: 5246 --9431149156168署名 Signature を指定する方法
署名の計算方法の詳細については、
PostObject の Signatureを参照してください。 署名はSignatureフォームフィールドに含まれています。一時ユーザー STS トークンを使用して Post Object を実行する方法
一時ユーザーの AccessKeyID と AccessKeySecret は、プライマリユーザーとサブユーザーの場合と同じ方法で使用されます。 トークンは、次の例に示すように、
x-oss-security-tokenフォームフィールドに含まれています。Content-Disposition: form-data; name="Signature" 5L0+KaeugxYygfqWLJLoy0ehOmA= --9431149156168 Content-Disposition: form-data; name="x-oss-security-token" {Token} --9431149156168アップロードコールバック(callback)を指定する方法
アップロードコールバック機能は、次の例に示すように、
callbackフォームフィールドで指定されます。Content-Disposition: form-data; name="callback" eyJjYWxsYmFja0JvZHlUeXBlIjogImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIsICJjYWxsYmFja0JvZHkiOiAiZmlsZW5hbWU9JHtvYmplY3R9JnNpemU9JHtzaXplfSZtaW1lVHlwZT0ke21pbWVUeXBlfSIsICJjYWxsYmFja1VybCI6ICJodHRwOi8vb3NzLWRlbW8uYWxpeXVuY3MuY29tOjIzNDUwIn0= --9431149156168コールバックのカスタムパラメーターも、フォームフィールドを介して含められます。 次の例はこれを示しています。
Content-Disposition: form-data; name="x:var1" {var1-value} --9431149156168説明コールバックの詳細については、「アップロードコールバック」をご参照ください。
Content-Transfer-Encoding を指定する方法
fileフォームフィールドで、Content-Transfer-Encodingを指定します。fileフォームフィールドの例を次に示します。Content-Disposition: form-data; name="file"; filename="images.png" Content-Type: image/png Content-Transfer-Encoding: base64 {file-content} --9431149156168ユーザーメタデータ Object User Meta を指定する方法
ユーザーメタデータは、フォームフィールドを介して指定されます。 次の例はこれを示しています。
Content-Disposition: form-dataname="x-oss-meta-uuid" {uuid} --9431149156168 Content-Disposition: form-data; name="x-oss-meta-tag" {tag} --9431149156168説明オブジェクトメタデータの詳細については、「オブジェクトメタデータ」をご参照ください。
expiration、Key、Bucket、size、header などの条件を指定する方法
OSS Post Object は、厳格なセキュリティ要件を満たすために、幅広い条件付き制限を提供します。 これらの条件は、
policyフォームフィールドを使用して定義できます。 詳細については、前述の Post Object ポリシーの形式を参照してください。 そのようなポリシーの例を次に示します。{ "expiration": "2018-01-01T12:00:00.000Z", "conditions": [ ["eq", "$bucket", "md-hz"], ["starts-with", "$key", "md/conf/"], ["content-length-range", 0, 104857600] ] }上記のポリシーの例では、ユーザーの Post Object 操作の条件は次のとおりです。
バケットは md-hz である必要があります。
bucketmd-hzkey は md/conf/ で始まる必要があります。
keymd/conf/アップロードされるファイルのサイズは 100 MB 未満である必要があります。
リクエストは 2018-01-01T12:00:00.000Z より前に行う必要があります。
2018-01-01T12:00:00.000Z
Cache-Control、Content-Type、Content-Disposition、Content-Encoding、Expires などの HTTP ヘッダーを指定する方法
Cache-ControlContent-Type、Content-Disposition,Content-EncodingExpiresなどの HTTP ヘッダーは、フォームフィールドで指定する必要があります。 これらの HTTP ヘッダーの意味については、「RFC2616」をご参照ください。 ただし、Content-MD5は Post ヘッダーで指定する必要があります。