Comment empêcher le remplacement d'objets par des écritures conditionnelles

Avec les écritures conditionnelles, vous pouvez ajouter un en-tête supplémentaire à votre demande d'écriture afin de spécifier les conditions préalables à votre opération S3. Cela peut empêcher le remplacement de données existantes en validant qu'aucun objet portant le même nom de clé ne se trouve déjà dans votre compartiment. Les écritures conditionnelles fonctionnent pour les API demandes adressées à des compartiments à usage général et à des compartiments de répertoire.

Lorsque vous chargez un objet sur Amazon S3, vous spécifiez le nom de la clé. Le nom de clé est un identifiant unique, distinguant majuscules et minuscules, d'un objet dans un compartiment. Si vous chargez un objet avec un nom de clé identique dans un bucket non versionné ou suspendu, l'objet est remplacé. Dans un bucket versionné, l'objet le plus récemment chargé deviendra la version actuelle de l'objet.

Les écritures conditionnelles vérifieront l'existence d'un objet pendant l'WRITEopération. Si un nom de clé identique est trouvé dans le compartiment, l'WRITEopération échouera. Avec les écritures conditionnelles, plusieurs clients peuvent écrire dans le même compartiment sans avoir à remplacer les objets existants.

Pour effectuer des écritures conditionnelles, vous devez avoir l's3:PutObjectautorisation. Cette autorisation permet à l'appelant de vérifier la présence d'objets dans le compartiment. Vous pouvez utiliser des écritures conditionnelles présignées URLs avec le AWS SDKs.

Soutenu APIs

Les S3 suivants APIs prennent en charge l'utilisation d'écritures conditionnelles :

Vous pouvez utiliser les en-têtes suivants pour écrire un objet en fonction du nom de la clé de l'objet. Pour plus d'informations sur les noms de clés d'objets, voir,Dénomination des objets Amazon S3.

PutObject

aws s3api put-object --bucket amzn-s3-demo-bucket --key dir-1/my_images.tar.bz2 --body my_images.tar.bz2 --if-none-match "*"    

Pour plus d'informations sur ces en-têtes, voir PutObjectdans le Amazon Simple Storage Service API Reference.

CompleteMultipartUpload

aws s3api complete-multipart-upload --multipart-upload file://mpustruct --bucket amzn-s3-demo-bucket --key dir-1/my_images.tar.bz2 --upload-id uploadID --if-none-match "*"      

Pour plus d'informations sur ces en-têtes, voir CompleteMultipartUploaddans le Amazon Simple Storage Service API Reference.

Comportement d'écriture conditionnel

Les écritures conditionnelles sont évaluées par rapport aux objets existants dans un compartiment. S'il n'existe aucun objet portant le même nom de clé dans le compartiment, l'opération d'écriture réussit, ce qui entraîne une 200 réponse. S'il existe un objet, l'opération d'écriture échoue, ce qui entraîne une 412 Precondition Failed réponse. Pour les buckets dont le versionnement est activé, S3 vérifie la présence d'une version d'objet actuelle portant le même nom dans le cadre de l'évaluation conditionnelle. S'il n'existe aucune version de l'objet portant le même nom, ou si la version actuelle de l'objet est un marqueur de suppression, l'opération d'écriture réussit. Dans le cas contraire, cela entraîne l'échec de l'opération d'écriture avec une 412 Precondition Failed réponse.

Si plusieurs écritures conditionnelles ont lieu pour le même nom d'objet, la première opération d'écriture terminée aboutira. Amazon S3 échouera alors aux écritures suivantes avec une 412 Precondition Failed réponse.

Vous pouvez également recevoir une 409 Conflict réponse en cas de demandes simultanées, si une demande de suppression d'un objet aboutit avant la fin d'une opération d'écriture conditionnelle sur cet objet. Cela est dû au fait que la demande de suppression a priorité sur l'opération d'écriture conditionnelle initiée précédemment. Lorsque vous utilisez des écritures conditionnelles avecPutObject, les téléchargements peuvent être réessayés après réception d'une 409 erreur. Lors de l'utilisationCompleteMultipartUpload, le téléchargement partitionné doit être relancé afin de CreateMultipartUpload télécharger à nouveau l'objet après réception d'une 409 erreur.

Considérez les scénarios suivants dans lesquels deux clients exécutent des opérations sur le même compartiment.

4.1.2 Condition préalable : échec de la réponse

Les écritures conditionnelles ne prennent pas en compte les demandes de téléchargement partitionné en cours, car il ne s'agit pas encore d'objets entièrement écrits. Prenons l'exemple suivant où le client 1 télécharge un objet à l'aide du téléchargement partitionné. Pendant le téléchargement partitionné, le client 2 est capable d'écrire avec succès le même objet grâce à l'opération d'écriture conditionnelle. Par la suite, lorsque le client 1 essaie de terminer le téléchargement partitionné à l'aide d'une écriture conditionnelle, le téléchargement échoue car l'objet existe déjà.

409 Réponse aux conflits

Si une demande de suppression aboutit avant qu'une demande d'écriture conditionnelle ne puisse être terminée, Amazon S3 renvoie une 409 Conflict réponse pour l'opération d'écriture. Cela est dû au fait que la demande de suppression initiée précédemment a priorité sur l'opération d'écriture conditionnelle. Prenons l'exemple suivant où un fichier puppy.txt existe dans un compartiment. Le client 1 lance un téléchargement partitionné pour un autre fichier également nommé dans le puppy.txt but de terminer le téléchargement partitionné par une écriture conditionnelle. Pendant le téléchargement, le client 2 supprime puppy.txt du compartiment. Lorsque le client 1 CompleteMultipartUpload essaie de télécharger son propre puppy.txt fichier avec une écriture conditionnelle, il échoue avec une 409 Conflict réponse. Dans ce cas, vous devez lancer un nouveau téléchargement partitionné.