Recomendaciones para ETags y hash

Cloud Storage anima a los usuarios a que validen los datos que transfieren hacia sus buckets y desde ellos con sumas de verificación CRC32C o MD5. En esta sección, se describen las recomendaciones para realizar estas validaciones.

Usa hash para verificar la integridad

Las siguientes son algunas maneras en las que los datos se pueden corromper cuando los subes o los descargas de la nube:

  • Vínculos de red contaminados
  • Errores de memoria en computadoras del cliente o del servidor, o routers a lo largo de la ruta
  • Errores de software (p. ej., en una biblioteca que usen los clientes)

Para protegerse de la corrupción de datos, Cloud Storage es compatible con dos tipos de hash: CRC32C y MD5. CRC32C es el método de validación recomendado. Los clientes que prefieren MD5 pueden usar ese hash, pero no es compatible con los objetos compuestos ni con los objetos creados a partir de una carga multiparte de la API de XML.

CRC32C

Todos los objetos de Cloud Storage tienen un hash CRC32C. Entre las bibliotecas para procesar CRC32C se incluyen las siguientes:

CRC32C codificado en Base64 está en el orden de bytes big-endian.

MD5

Cloud Storage admite un hash MD5 para los objetos que cumplen con los siguientes criterios:

  • El objeto no es un objeto compuesto.
  • El objeto no se subió mediante una carga multiparte de la API de XML.

Este hash solo se aplica en un objeto completo, por lo que no se puede usar para verificar la integridad de descargas parciales generadas por la realización de un rango GET.

ETag

En el caso de los objetos no compuestos que no se subieron con una carga multiparte de la API de XML, la API de XML muestra el MD5 del objeto para el valor del encabezado de ETag. En todos los demás casos, los usuarios no deben hacer suposiciones sobre el valor usado en una ETag, excepto que cambia cada vez que cambian los datos subyacentes, según la especificación.

El mismo objeto puede tener un valor de ETag diferente cuando se solicita desde la API de XML en comparación con la API de JSON.

Validación

Se puede realizar una verificación de integridad mediante la generación de un hash de datos descargados en el momento y comparar tus resultados con los hash proporcionados por el servidor. Debes descartar datos descargados con valores de hash incorrectos y usar la lógica de reintento para evitar potenciales repeticiones infinitas y costosas.

Cloud Storage realiza una validación del lado del servidor en los siguientes casos:

  • Cuando realizas una solicitud de copia o reescritura dentro de Cloud Storage.

  • Cuando se proporciona el hash MD5 o CRC32C esperado de un objeto en una solicitud de carga Cloud Storage solo crea el objeto si el hash que proporcionas coincide con el valor que calcula Cloud Storage.

De forma alternativa, los usuarios pueden optar por realizar una validación del cliente de sus cargas mediante la emisión de una solicitud para los metadatos del objeto subido, la comparación del valor de hash informado y la eliminación del objeto en caso de que no coincidan. Este método es útil si no se conoce el hash MD5 o CRC32C del objeto al inicio de la carga. Para evitar las condiciones de carrera en las que los procesos independientes borran o reemplazan los datos de cada uno, recomendamos que uses generaciones de objetos y condiciones previas.

En el caso de las cargas compuestas paralelas, los usuarios deben realizar una verificación de integridad para cada carga de componente y, luego, usar las condiciones previas del componente con las solicitudes de composición a fin de protegerse de las condiciones de carrera. La composición de objetos no ofrece una validación de MD5 del servidor, por lo que los usuarios que deseen realizar una verificación completa de integridad deben aplicar una validación del cliente al objeto de composición nuevo.

Al final de cada operación de copia, los comandos de gsutil cp y rsync validan que la suma de verificación del archivo local coincida con la suma de verificación del objeto almacenado en Cloud Storage. Si no es así, gsutil borra la copia no válida y, luego, muestra un mensaje de advertencia. Eso no suele suceder. Si coincide, puedes intentar de nuevo la operación.

API de XML

En la API de XML, los hash MD5 y CRC32C codificados en base64 se exponen y aceptan a través del encabezado x-goog-hash. Antes, los MD5 se usaban como objetos de ETag, pero los usuarios deben evitar suponer que esto se debe a que algunos objetos usan valores de ETag opacos que no garantizan más que un cambio cuando el objeto cambia.

La validación de carga del lado del servidor se puede realizar si se proporcionan hash calculados de manera local a través del encabezado de solicitud x-goog-hash. Además, el MD5 se puede proporcionar mediante el encabezado Content-MD5 HTTP estándar (consulta la especificación).

API de JSON

En la API de JSON, las propiedades md5Hash y crc32c del recurso de objetos contienen los hash MD5 y CRC32C codificados en base64, respectivamente. Proporcionar cualquiera de las propiedades de metadatos es opcional. Proporcionar cualquiera de las propiedades como parte de una carga reanudable o carga de varias partes de la API de JSON activa la validación del servidor para el objeto nuevo. Si Cloud Storage calcula un valor para cada propiedad que no coincide con el valor proporcionado, el objeto no se crea. Si las propiedades no se proporcionan en una carga, Cloud Storage calcula los valores y los escribe en los metadatos del objeto.