Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Bonnes pratiques concernant les erreurs Amazon S3

Beaucoup de réponses d'erreur contiennent des données structurées complémentaires destinées à être lues et comprises par un développeur diagnostiquant des erreurs de programmation. Par exemple, si vous envoyez un Content-MD5 en-tête avec une requête REST PUT qui ne correspond pas au résumé calculé sur le serveur, vous recevez un BadDigest message d'erreur. La réponse d'erreur inclut également comme éléments de détail le résumé qui a été calculé et le résumé que vous avez indiqué comme prévu. Pendant le développement, vous pouvez utiliser ces informations pour diagnostiquer l'erreur. En production, un programme performant doit comprendre ces informations dans son journal des erreurs.

Lors de la conception d'une application devant être utilisée avec Amazon S3, il est important de gérer les erreurs Amazon S3 de façon appropriée. Cette section décrit les erreurs à prendre en compte lors de la conception de votre application.

Réessayez InternalErrors

Les erreurs internes sont des erreurs qui se produisent au sein de l'environnement Amazon S3.

Les demandes qui reçoivent une InternalError réponse n'ont peut-être pas été traitées. Par exemple, si une requête PUT est InternalError renvoyée, un GET suivant peut récupérer l'ancienne valeur ou la valeur mise à jour.

Si Amazon S3 renvoie une InternalError réponse, réessayez la demande.

Réglez l'application pour éviter les SlowDown erreurs répétées

Comme tout système distribué, S3 possède des mécanismes de protection qui détectent la surconsommation intentionnelle ou non intentionnelle des ressources et réagissent en conséquence. SlowDown des erreurs peuvent survenir lorsqu'un taux de demandes élevé déclenche l'un de ces mécanismes. Réduire le taux de demande diminuera ou éliminera des erreurs de ce type. D'une manière générale, la plupart des utilisateurs ne rencontrent pas ces erreurs régulièrement. Toutefois, si vous souhaitez obtenir plus d'informations ou si vous rencontrez des SlowDown erreurs importantes ou inattendues, veuillez publier un message sur notre forum des développeurs Amazon S3 ou vous inscrire à Support https://aws.amazon.com/premiumsupport/.

Isoler les erreurs

Amazon S3 fournit un ensemble de codes d'erreur qui sont utilisés par les deux API SOAP et REST. L'API SOAP renvoie des codes d'erreur Amazon S3 standard. L'API REST est conçue pour fonctionner comme un serveur HTTP standard et interagir avec les clients HTTP existants (par exemple, les navigateurs, les bibliothèques client HTTP, les serveurs proxy, les mémoires cache, etc.). Pour garantir que les clients HTTP gèrent correctement les erreurs, Amazon S3 associe chaque erreur Amazon S3 à un code d'état HTTP.

Les codes de statut HTTP sont moins parlants que les codes d'erreur Amazon S3 et contiennent moins d'informations sur l'erreur. Par exemple, les erreurs Amazon S3 NoSuchKey et NoSuchBucket sont toutes les deux liées au code de statut HTTP 404 Not Found.

Même si les codes de statut HTTP contiennent moins d'informations sur l'erreur, les clients qui comprennent les codes HTTP, mais pas l'API Amazon S3, sont généralement à même de gérer l'erreur correctement.

Par conséquent, lors de la gestion d'erreurs ou du signalement des erreurs Amazon S3 aux utilisateurs finaux, utilisez le code d'erreur Amazon S3 à la place du code de statut HTTP, car il contient plus d'informations sur l'erreur. De même, lors du débogage de votre application, vous devrez également consulter l'élément lisible <Details> de la réponse d'erreur XML.