Skip to main content
Hay disponible una nueva versión de este producto.
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

OBJETO PUT

Colaboradores
PDF

Puede usar la solicitud PUT Object de S3 para añadir un objeto a un bloque.

Resolver conflictos

Las solicitudes de clientes en conflicto, como dos clientes que escriben en la misma clave, se resuelven en función de las "últimas victorias". El plazo para la evaluación de "logros más recientes" se basa en cuándo el sistema StorageGRID completa una solicitud determinada, y no en cuándo los clientes de S3 comienzan una operación.

Tamaño del objeto

El tamaño máximo recomendado para una única operación PUT Object es de 5 GIB (5,368,709,120 bytes). Si tiene objetos que sean mayores de 5 GIB, utilice la carga de varias partes en su lugar.

El tamaño máximo de soportado para una única operación PUT Object es de 5 TiB (5.497.558.138.880 bytes). Sin embargo, la alerta * S3 PUT Object size demasiado grande* se activará si intenta cargar un objeto que supere los 5 GIB.

Tamaño de los metadatos del usuario

Amazon S3 limita el tamaño de los metadatos definidos por el usuario dentro de cada encabezado de solicitud PUT a 2 KB. StorageGRID limita los metadatos de usuario a 24 KiB. El tamaño de los metadatos definidos por el usuario se mide tomando la suma del número de bytes de la codificación UTF-8 de cada clave y valor.

Caracteres UTF-8 en los metadatos de usuario

Si una solicitud incluye (no escapadas) valores UTF-8 en el nombre de clave o el valor de los metadatos definidos por el usuario, el comportamiento de StorageGRID no está definido.

StorageGRID no analiza ni interpreta los caracteres UTF-8 escapados incluidos en el nombre de clave o el valor de los metadatos definidos por el usuario. Los caracteres UTF-8 que se han escapado se tratan como caracteres ASCII:

  • LAS solicitudes PUT, PUT Object-Copy, GET y HEAD se realizan correctamente si los metadatos definidos por el usuario incluyen caracteres UTF-8 que se han escapado.

  • StorageGRID no devuelve el x-amz-missing-meta encabezado si el valor interpretado del nombre o valor de clave incluye caracteres no imprimibles.

Límites de etiqueta de objeto

Puede agregar etiquetas a nuevos objetos cuando los cargue o puede agregarlos a objetos existentes. Tanto StorageGRID como Amazon S3 admiten hasta 10 etiquetas por cada objeto. Las etiquetas asociadas a un objeto deben tener claves de etiqueta únicas. Una clave de etiqueta puede tener hasta 128 caracteres Unicode de longitud y los valores de etiqueta pueden tener hasta 256 caracteres Unicode de longitud. La clave y los valores distinguen entre mayúsculas y minúsculas.

Propiedad del objeto

En StorageGRID, todos los objetos son propiedad de la cuenta de propietario del bloque, incluidos los objetos creados por una cuenta que no sea propietaria o un usuario anónimo.

Encabezados de solicitud admitidos

Se admiten los siguientes encabezados de solicitud:

  • Cache-Control

  • Content-Disposition

  • Content-Encoding

    Al especificar aws-chunked para Content-EncodingStorageGRID no verifica los siguientes elementos:

    • StorageGRID no verifica el chunk-signature contra los datos del fragmento.

    • StorageGRID no verifica el valor indicado para x-amz-decoded-content-length contra el objeto.

  • Content-Language

  • Content-Length

  • Content-MD5

  • Content-Type

  • Expires

  • Transfer-Encoding

    La codificación de transferencia con chunked es compatible si aws-chunked también se utiliza la firma de carga útil.

  • x-amz-meta-, seguido de un par nombre-valor que contiene metadatos definidos por el usuario.

    Cuando especifique la pareja nombre-valor para los metadatos definidos por el usuario, utilice este formato general:

    x-amz-meta-name: value

    Si desea utilizar la opción Tiempo de creación definido por el usuario como Tiempo de referencia para una regla de ILM, debe utilizar creation-time como nombre de los metadatos que registran cuando se creó el objeto. Por ejemplo:

    x-amz-meta-creation-time: 1443399726

    Valor para creation-time Se evalúa como segundos desde el 1 de enero de 1970.

    Nota Una regla de ILM no puede usar un Tiempo de creación definido por el usuario para el Tiempo de referencia y las opciones equilibradas o estrictas para el comportamiento de ingesta. Se devuelve un error cuando se crea la regla de ILM.

  • x-amz-tagging

  • Encabezados de solicitud de bloqueo de objetos de S3

    • x-amz-object-lock-mode

    • x-amz-object-lock-retain-until-date

    • x-amz-object-lock-legal-hold

      Si se realiza una solicitud sin estas cabeceras, se utiliza la configuración de retención por defecto del depósito para calcular el modo de versión del objeto y retener hasta la fecha. Consulte "Use la API REST DE S3 para configurar el bloqueo de objetos de S3".

  • Encabezados de solicitud SSE:

Encabezados de solicitud no compatibles

No se admiten las siguientes cabeceras de solicitud:

  • La x-amz-acl no se admite el encabezado de la solicitud.

  • La x-amz-website-redirect-location el encabezado de la solicitud no es compatible y devuelve XNotImplemented.

Opciones para clase de almacenamiento

La x-amz-storage-class se admite el encabezado de la solicitud. El valor enviado para x-amz-storage-class Afecta la forma en que StorageGRID protege los datos de objetos durante el procesamiento y no cuántas copias persistentes del objeto se almacenan en el sistema StorageGRID (determinado por ILM).

Si la regla de ILM que coincide con un objeto ingerido utiliza la opción estricta para el comportamiento de la ingesta, la x-amz-storage-class el encabezado no tiene efecto.

Se pueden utilizar los siguientes valores para x-amz-storage-class:

  • STANDARD (Predeterminado)

    • Commit doble: Si la regla ILM especifica la opción COMMIT doble para el comportamiento de procesamiento, tan pronto como un objeto se ingiere una segunda copia de ese objeto se crea y se distribuye a un nodo de almacenamiento diferente (COMMIT doble). Cuando se evalúa el ciclo de vida de la información, StorageGRID determina si estas copias provisionales iniciales cumplen las instrucciones de colocación que se indican en la regla. Si no es así, es posible que deban realizarse copias de objetos nuevas en ubicaciones diferentes y es posible que las copias provisionales iniciales deban eliminarse.

    • Equilibrado: Si la regla de ILM especifica la opción Equilibrada y StorageGRID no puede hacer inmediatamente todas las copias especificadas en la regla, StorageGRID hace dos copias provisionales en diferentes nodos de almacenamiento.

      Si StorageGRID puede crear inmediatamente todas las copias de objeto especificadas en la regla de ILM (ubicación síncrona), la x-amz-storage-class el encabezado no tiene efecto.

  • REDUCED_REDUNDANCY

    • Commit doble: Si la regla ILM especifica la opción COMMIT doble para el comportamiento de la ingesta, StorageGRID crea una única copia provisional mientras se ingiere el objeto (COMMIT único).

    • Equilibrado: Si la regla de ILM especifica la opción Equilibrada, StorageGRID hace una sola copia provisional solo si el sistema no puede hacer inmediatamente todas las copias especificadas en la regla. Si StorageGRID puede realizar una colocación síncrona, este encabezado no tiene ningún efecto. La REDUCED_REDUNDANCY Se recomienda utilizar la opción cuando la regla de ILM que coincide con el objeto crea una única copia replicada. En este caso, utilizar REDUCED_REDUNDANCY elimina la creación y eliminación innecesarias de una copia de objetos adicional en cada operación de procesamiento.

    Con el REDUCED_REDUNDANCY la opción no se recomienda en otras circunstancias. REDUCED_REDUNDANCY aumenta el riesgo de pérdida de datos de objetos durante el procesamiento. Por ejemplo, puede perder datos si la única copia se almacena inicialmente en un nodo de almacenamiento que falla antes de que se pueda realizar la evaluación de ILM.

Importante Tener solo una copia replicada durante un periodo de tiempo pone los datos en riesgo de pérdida permanente. Si sólo existe una copia replicada de un objeto, éste se pierde si falla un nodo de almacenamiento o tiene un error importante. También perderá temporalmente el acceso al objeto durante procedimientos de mantenimiento, como las actualizaciones.

Especificando REDUCED_REDUNDANCY sólo afecta al número de copias que se crean cuando un objeto se ingiere por primera vez. No afecta al número de copias del objeto que se realizan cuando el objeto se evalúa mediante la política de ILM activa y no provoca que los datos se almacenen en niveles inferiores de redundancia en el sistema StorageGRID.

Nota Si va a procesar un objeto en un bloque con el bloqueo de objetos S3 habilitado, el REDUCED_REDUNDANCY opción ignorada. Si está ingiriendo un objeto en un bloque compatible heredado, el REDUCED_REDUNDANCY opción devuelve un error. StorageGRID siempre realizará una ingesta con doble confirmación para garantizar que se cumplan los requisitos de cumplimiento.

Solicitar encabezados para el cifrado del servidor

Puede utilizar los siguientes encabezados de solicitud para cifrar un objeto con cifrado del servidor. Las opciones SSE y SSE-C son mutuamente excluyentes.

  • SSE: Utilice el siguiente encabezado si desea cifrar el objeto con una clave única gestionada por StorageGRID.

    • x-amz-server-side-encryption

  • SSE-C: Utilice los tres encabezados si desea cifrar el objeto con una clave única que proporciona y administra.

    • x-amz-server-side-encryption-customer-algorithm: Especificar AES256.

    • x-amz-server-side-encryption-customer-key: Especifique la clave de cifrado para el nuevo objeto.

    • x-amz-server-side-encryption-customer-key-MD5: Especifique el resumen MD5 de la clave de cifrado del nuevo objeto.

Importante Las claves de cifrado que proporcione no se almacenan nunca. Si pierde una clave de cifrado, perderá el objeto correspondiente. Antes de utilizar las claves proporcionadas por el cliente para proteger los datos de objetos, revise las consideraciones para "utilizando cifrado del lado del servidor".
Nota Si un objeto está cifrado con SSE o SSE-C, se ignorará cualquier configuración de cifrado a nivel de bloque o de cuadrícula.

Creación de versiones

Si el control de versiones está habilitado para un bloque, un valor único versionId se genera automáticamente para la versión del objeto almacenado. Este versionId también se devuelve en la respuesta mediante el x-amz-version-id encabezado de respuesta.

Si se suspende el control de versiones, la versión del objeto se almacena con un valor nulo versionId y si ya existe una versión nula, se sobrescribirá.

Cálculos de firma para la cabecera de autorización

Cuando utilice la Authorization Encabezado Para autenticar solicitudes, StorageGRID difiere de AWS de las siguientes maneras:

  • StorageGRID no requiere host cabeceras que se incluirán en CanonicalHeaders.

  • StorageGRID no requiere Content-Type para ser incluido dentro de CanonicalHeaders.

  • StorageGRID no requiere x-amz-* cabeceras que se incluirán en CanonicalHeaders.

Importante Como práctica recomendada general, incluya siempre estos encabezados en él CanonicalHeaders Para asegurarse de que se verifican; sin embargo, si excluye estas cabeceras, StorageGRID no devuelve un error.

Para obtener más información, consulte "Cálculos de firma para la cabecera de autorización: Transferencia de carga útil en un solo fragmento (AWS Signature versión 4)".

Información relacionada

"Gestión de objetos con ILM"

"Operaciones en bloques"

"Se realizó un seguimiento de las operaciones de S3 en los registros de auditoría"

"Cómo se pueden configurar las conexiones de clientes"