:PostObject

Introducción

PostObject carga archivos a OSS mediante formularios. En PostObject, las entidades del mensaje se codifican en formato multipart/form-data. Para obtener más información, consulte RFC 2388. En PutObject, los parámetros se pasan mediante encabezados HTTP, mientras que en PostObject se transmiten como campos de formulario en el cuerpo del mensaje.

Un mensaje PostObject consta de un encabezado y un cuerpo, separados por

\r\n--{boundary}

. El cuerpo consiste en una serie de campos de formulario con el siguiente formato:

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

Los encabezados comunes incluyen Host, User-Agent, Content-Length, Content-Type y Content-MD5. Los campos de formulario incluyen key, OSSAccessKeyId, Signature, Content-Disposition, metadatos del objeto (x-oss-meta-*), x-oss-security-token, otros encabezados HTTP (Cache-Control/Content-Type/Cache-Control/Content-Type/Content-Disposition/Content-Encoding/Expires/Content-Encoding/Expires) y file. El campo file debe ser el último entre todos los campos del formulario.

Para obtener más información, consulte Post Object.

Errores comunes de PostObject

La siguiente tabla muestra los errores comunes de PostObject:

• Formato de campos de formulario de PostObject

  Tenga en cuenta los siguientes puntos sobre el formato de las solicitudes PostObject:

  • El encabezado debe incluir Content-Type: multipart/form-data; boundary={boundary}.

  • El encabezado y el cuerpo están separados por \r\n--{boundary}.

  • Formato del campo de formulario:

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

  • Los nombres de los campos de formulario distinguen entre mayúsculas y minúsculas, como policy, key, file, OSSAccessKeyId, OSSAccessKeyId y Content-Disposition.

    Importante

    El campo de formulario file debe ser el último campo del formulario.

  • Cuando el valor de bucket es public-read-write, no es necesario especificar los campos de formulario OSSAccessKeyId, policy y Signature. Si se especifica alguno de estos tres campos, los otros dos también deben especificarse, independientemente de si bucket tiene el valor public-read-write o no.

  A continuación se muestra un ejemplo de solicitud PostObject:

  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

  Nota

  • En la solicitud de ejemplo anterior, \r\n indica una nueva línea, es decir, un salto de línea. Esto también aplica a las siguientes solicitudes de ejemplo.

  • La solicitud de ejemplo anterior está incompleta. Para ver la solicitud completa, consulte Post Object.

  Si tiene alguna duda, consulte el código de ejemplo:

  • C#

  • Java

• Formato de directiva de PostObject

  En una solicitud PostObject, el campo de formulario policy se utiliza para verificar la validez de la solicitud y declara las condiciones que debe cumplir dicha solicitud. En concreto, estas condiciones son:

  • El texto JSON en UTF-8 debe codificarse con base64 antes de pasarse al campo de formulario policy.

  • La policy debe incluir expiration y conditions, donde conditions debe contener como mínimo un elemento.

  A continuación se muestra un ejemplo de policy antes de la codificación base64.

  
     {
      "expiration": "2018-01-01T12:00:00.000Z",
      "conditions": [
          ["content-length-range", 0, 104857600]
      ]
  }

  El elemento expiration especifica una hora de caducidad para la solicitud en formato de tiempo ISO8601 GMT. Por ejemplo, 2018-01-01T12:00:00.000Z indica que la solicitud debe realizarse antes de las 12:00 a.m. del 1 de enero de 2018.

  PostPolicy admite las siguientes "conditions":

  Nombre	Descripción	Ejemplo
  bucket	Nombre del bucket del archivo cargado. Se admite la coincidencia exacta.	{“bucket”: “johnsmith” } o [“eq”, “$bucket”, “johnsmith”]
  key	Nombre del archivo cargado. Se admiten coincidencias exactas y por prefijo.	[“starts-with”, “$key”, “user/etc/”]
  content-length-range	Tamaños máximo y mínimo permitidos para el archivo cargado.	[“content-length-range”, 0, 104857600]
  x-oss-meta-*	Metadatos del objeto especificados. Se admiten coincidencias exactas y por prefijo.	[“starts-with”, “$x-oss-meta-prop”, “prop-“]
  success_action_redirect	URL de redireccionamiento tras una carga exitosa. Se admiten coincidencias exactas y por prefijo.	[“starts-with”, “$success_action_redirect”, “http://www.aliyun.com”]
  success_action_status	Código de estado devuelto tras una carga exitosa si no se especifica success_action_redirect. Se admiten coincidencias exactas y por prefijo.	[“eq”, “$success_action_status”, “204”]
  Cache-Control, Content-Type, Content-Disposition, Content-Encoding, Expires, etc.	Encabezados HTTP pasados como campos de formulario. Se admiten coincidencias exactas y por prefijo.	[“eq”, “$Content-Encoding”, “ZLIB”]

  PostPolicy admite los siguientes caracteres de escape y utiliza \ para el escape.

  Carácter de escape	Descripción
  /	Barra diagonal
  \	Barra diagonal inversa
  “	Comillas dobles
  $	Signo de dólar
  \b	Espacio en blanco
  \f	Salto de página
  \n	Salto de línea
  \r	Retorno de carro
  \t	Tabulación horizontal
  \uxxxx	Carácter Unicode

  Para obtener más información sobre PostPolicy, consulte Post Policy.

• Firma de PostObject

  Para que se verifique una solicitud Post, esta debe incluir los campos de formulario AccessKeyID, policy y Signature. El proceso de cálculo de la firma es el siguiente:

  1. Cree una directiva codificada con UTF-8.

  2. Codifique la directiva con base64. El valor resultante es el que debe introducirse en el campo de formulario policy, y este valor se usa como la cadena que se firmará.

  3. Firme la cadena con AccessKeySecret. Específicamente, calcule el hash de la cadena con hmac-sha1 y luego codifíquela con base64. El método de firma es el mismo que para Header Signature.

  Es decir:

  Signature = base64(hmac-sha1(AccessKeySecret, base64(policy)))

  Especifique la firma calculada en el campo de formulario Signature de la siguiente manera:

  Content-Disposition: form-data; name="Signature"
  {signature}
  -- 9431149156168

  Si tiene alguna duda, consulte el código de ejemplo:

  • C#

  • Java

Preguntas frecuentes

• ¿Cómo especificar una clave?

  La clave es el nombre del objeto, que se especifica en el campo de formulario key. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="key"
  {key}
  --9431149156168

• ¿Cómo especificar el contenido del objeto?

  Especifique el contenido del objeto en el campo de formulario file. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="file"; filename="images.png"
  Content-Type: image/png
  {File-content}
  -- 9431149156168

  Nota

  • El campo de formulario file debe ser el último campo del formulario, es decir, debe colocarse después de cualquier otro campo.

  • filename es el nombre del archivo local cargado, no el nombre del objeto.

• ¿Cómo especificar el content-type del objeto?

  Especifique el content-type del objeto en el campo de formulario file, no en el content-type del encabezado. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="file"; filename="images.png"
  Content-Type: image/png
  {file-content}
  --9431149156168

• ¿Cómo especificar la verificación content-md5 para el contenido del objeto?

  Especifique content-md5 en el encabezado de la solicitud PostObject. Tenga en cuenta que el valor MD5 corresponde a todo el cuerpo, es decir, a todos los campos del formulario. A continuación se muestra un ejemplo de encabezado de solicitud:

  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

• ¿Cómo especificar una firma?

  Consulte PostObject signature para conocer el método de cálculo de la firma. La firma se transmite mediante el campo de formulario Signature.

• ¿Cómo implementar PostObject con el STS Token de un usuario temporal?

  El uso de AccessKeyID y AccessKeySecret de una clave de usuario temporal es el mismo que el de una clave de usuario principal o de subusuario. El Token se transmite mediante el campo de formulario x-oss-security-token. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="Signature"
  5L0+KaeugxYygfqWLJLoy0ehOmA=
  --9431149156168
  Content-Disposition: form-data; name="x-oss-security-token"
  {Token}
  --9431149156168

• ¿Cómo especificar una devolución de llamada?

  La devolución de llamada se transmite mediante el campo de formulario callback. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="callback"
  eyJjYWxsYmFja0JvZHlUeXBlIjogImFwcGxpY2F0aW9uL3gtd3d3LWZvcm0tdXJsZW5jb2RlZCIsICJjYWxsYmFja0JvZHkiOiAiZmlsZW5hbWU9JHtvYmplY3R9JnNpemU9JHtzaXplfSZtaW1lVHlwZT0ke21pbWVUeXBlfSIsICJjYWxsYmFja1VybCI6ICJodHRwOi8vb3NzLWRlbW8uYWxpeXVuY3MuY29tOjIzNDUwIn0=
  --9431149156168

  Los parámetros personalizados de la devolución de llamada también se transmiten mediante campos de formulario. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="x:var1"
  {var1-value}
  --9431149156168

• ¿Cómo especificar Content-Transfer-Encoding?

  Especifique Content-Transfer-Encoding en el campo de formulario file. A continuación se muestra un ejemplo del campo de formulario file:

  Content-Disposition: form-data; name="file"; filename="images.png"
  Content-Type: image/png
  Content-Transfer-Encoding: base64
  {file-content}
  --9431149156168

• ¿Cómo especificar la información de metadatos personalizados Object User Meta?

  Especifique la información de metadatos personalizados en los campos de formulario. A continuación se muestra un ejemplo:

  Content-Disposition: form-data; name="x-oss-meta-uuid"
  {uuid}
  --9431149156168
  Content-Disposition: form-data; name="x-oss-meta-tag"
  {tag}
  --9431149156168

  Nota

  Para obtener más información sobre los metadatos de archivos, consulte File Meta Information Object Meta.

• ¿Cómo especificar condiciones como caducidad, Key, Bucket, tamaño y encabezado?

  PostObject para OSS admite diversas condiciones y puede cumplir con requisitos de seguridad exigentes. Especifique las condiciones en el campo de formulario policy. A continuación se muestra un ejemplo de directiva:

  {
      "expiration": "2018-01-01T12:00:00.000Z",
      "conditions": [
          ["eq", "$bucket", "md-hz"],
          ["starts-with", "$key", "md/conf/"],
          ["content-length-range", 0, 104857600]
      ]
  }

  En la directiva anterior, las condiciones para las operaciones PostObject del usuario son las siguientes:

  • El bucket debe ser md-hz.

  • La key debe comenzar con md/conf/.

  • El tamaño del archivo cargado debe ser inferior a 100 MB.

  • La hora de la solicitud debe ser anterior a 2018-01-01T12:00:00.000Z.

• ¿Cómo especificar encabezados HTTP como Cache-Control, Content-Type, Content-Disposition, Content-Encoding y Expires?

  Especifique los encabezados HTTP, incluidos Cache-Control, Content-Type, Content-Disposition, Content-Encoding y Expires, en los campos de formulario. Para conocer el significado de estos encabezados HTTP, consulte RFC2616. Sin embargo, Content-MD5 debe especificarse en el encabezado Post.

Ejemplos de PostObject

Enlace de uso frecuente