すべてのプロダクト
Search
ドキュメントセンター

:Post Object のエラーとトラブルシューティング

最終更新日:Feb 27, 2025

このトピックでは、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 トークンが提供されていません。AccessKeyID

トラブルシューティングについては、「InvalidAccessKeyId エラーのトラブルシューティング」をご参照ください。

3

ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy expired.

ポリシーフォームフィールドの有効期限が過ぎています。expiration パラメーターは、アップロードされたファイルが廃止される日時を指定します。

ポリシーの有効期限を調整し、形式が ISO8601 GMT であることを確認します。expiration パラメーターは、生成されたトークンが有効な期間を指定します。

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

リクエストのポリシー形式が正しくありません。policy

ポリシー形式を確認し、欠落している引用符がないか確認し、エスケープ文字 "\ が正しく使用されていることを確認します。

7

ErrorCode: InvalidPolicyDocument ErrorMessage: Invalid Policy: Invalid JSON: , or ] expected

リクエストのポリシー形式が正しくありません。policy

ポリシーに , または ] が欠落しているかどうかを確認します。

8

ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“starts-with”, “$key”, “user/eric/“]

リクエストで指定されたキーがポリシーの制限と一致しません。key は、ストレージシステム内のオブジェクトの一意の識別子を表します。policy

リクエストのフォームフィールドの key 値を確認します。key

9

ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“eq”, “$bucket”, “mingdi-bjx”]

リクエストで指定されたバケットがポリシーの制限と一致しません。bucketpolicy

エンドポイントのバケット値を確認します。bucket

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

リクエストの x-oss-meta-prop 値を確認します。x-oss-meta-prop

11

ErrorCode: AccessDenied ErrorMessage: Invalid according to Policy: Policy Condition failed: [“eq”, “${field}”, “${value}”]

フォームフィールドで指定された {field} がポリシーの値と一致しないか、リクエストで指定されていません。{field}

リクエストの {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

key フォームフィールドを追加するか、file フィールドの前に来るように順序を調整します。key

  • 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 フォームフィールドを含める必要があります。 署名の計算プロセスは次のとおりです。

    1. UTF-8 エンコードのポリシーを作成します。UTF-8

    2. ポリシーを base64 でエンコードします。 このエンコードされた値は、policy フォームフィールドの値と署名する文字列です。Base64

    3. AccessKeySecret を使用して文字列に署名します。最初に 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-hz

    • key は md/conf/ で始まる必要があります。 key md/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-TypeContent-Disposition,Content-EncodingExpires などの HTTP ヘッダーは、フォームフィールドで指定する必要があります。 これらの HTTP ヘッダーの意味については、「RFC2616」をご参照ください。 ただし、Content-MD5 は Post ヘッダーで指定する必要があります。

Post Object の例

一般的なリンク