Prácticas recomendadas para ETags y hash

Cloud Storage te recomienda validar los datos que transfieres a tus buckets y desde ellos. En esta página, se describen las prácticas recomendadas para realizar validaciones mediante sumas de comprobación CRC32C o MD5.

Protege contra la corrupción de datos mediante hashes

Existen varias maneras en las que los datos se pueden corromper cuando los subes o los descargas de la nube:

  • 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)
  • Cambios en el archivo fuente cuando se realiza una carga durante un período prolongado

Cloud Storage admite dos tipos de hash que puedes usar para verificar la integridad de tus datos: CRC32C y MD5. CRC32C es el método de validación recomendado para realizar verificaciones de integridad. 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.

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. Si no coincide, la solicitud se rechaza con un error BadRequestException: 400.

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, usa 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.

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 ETags, 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.

Google Cloud CLI

Para Google Cloud CLI, se validan los datos copiados desde y hacia un bucket de Cloud Storage. Esto se aplica a los comandos cp, mv y rsync. Si la suma de comprobación de los datos de origen no coincide con la suma de verificación de los datos de destino, gcloud CLI 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.

Esta validación automática se produce después de que se completa el objeto, por lo que los objetos no válidos son visibles durante 1 o 3 segundos antes de que se identifiquen y se borren. Además, existe la posibilidad de que la gcloud CLI se interrumpa después de que se complete la carga, pero antes de que realice la validación, lo que deja el objeto no válido en su lugar. Estos problemas se pueden evitar cuando se suben archivos únicos a Cloud Storage con la validación del servidor, que ocurre cuando se usan las siguientes marcas --content-md5=MD5.

¿Qué sigue?