Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Bewährte Methoden für Amazon-S3-Fehler

Viele Fehlermeldungen enthalten zusätzliche strukturierte Daten, die von einem Entwickler gelesen und interpretiert werden, der Programmfehler diagnostiziert. Wenn Sie beispielsweise einen Content-MD5 Header mit einer REST-PUT-Anfrage senden, die nicht mit dem auf dem Server berechneten Digest übereinstimmt, erhalten Sie eine BadDigest Fehlermeldung. Die Fehlerantwort enthält als Detailelemente auch den berechneten Digest und den Digest, den Sie zu erwarten bereitgestellt haben. Während der Entwicklung können Sie diese Informationen nutzen, um den Fehler zu diagnostizieren. In der Produktion könnte ein ordnungsgemäß funktionierendes Programm diese Informationen in seinem Fehlerprotokoll enthalten.

Wenn Sie eine Anwendung für Amazon S3 entwerfen, sollten Sie darauf achten, dass Amazon-S3-Fehler auf geeignete Weise verarbeitet werden. Dieser Abschnitt beschreibt Aspekte, die Sie beim Entwurf Ihrer Anwendung berücksichtigen sollten.

Versuchen Sie es erneut InternalErrors

Interne Fehler sind Fehler, die innerhalb der Amazon-S3-Umgebung auftreten.

Anfragen, die eine InternalError Antwort erhalten, wurden möglicherweise nicht bearbeitet. Wenn beispielsweise eine PUT-Anforderung zurückkehrt InternalError, kann ein nachfolgendes GET den alten oder den aktualisierten Wert abrufen.

Wenn Amazon S3 eine InternalError Antwort zurückgibt, versuchen Sie es erneut mit der Anfrage.

Optimieren Sie die Anwendung für wiederholte Fehler SlowDown

Wie jedes verteilte System verfügt S3 über Schutzmechanismen, die einen vorsätzlichen oder unbeabsichtigten Ressourcenüberverbrauch erkennen und entsprechend reagieren. SlowDown Fehler können auftreten, wenn eine hohe Anforderungsrate einen dieser Mechanismen auslöst. Eine Reduzierung Ihrer Anfragerate verringert oder eliminiert Fehler dieses Typs. Im Allgemeinen treten diese Fehler bei den meisten Benutzern nicht regelmäßig auf. Wenn Sie jedoch weitere Informationen wünschen oder häufig oder unerwartete SlowDown Fehler auftreten, posten Sie dies bitte in unserem Amazon S3-Entwicklerforum oder registrieren Sie sich für Support https://aws.amazon.com/premiumsupport/.

Isolieren von Fehlern

Amazon S3 unterstützt verschiedene Fehlercodes, die sowohl von der SOAP, als auch von der REST-API verwendet werden. Die SOAP API gibt Amazon-S3-Standardfehlercodes zurück. Die REST-API ist darauf ausgelegt, wie ein HTTP-Standardserver auszusehen und mit vorhandenen HTTP-Clients zu interagieren (z. B. Browsern, HTTP-Clientbibliotheken, Proxies, Caches usw.). Um sicherzustellen, dass die HTTP-Clients Fehler ordnungsgemäß behandeln, ordnet Amazon S3 jeden Amazon S3-Fehler einem HTTP-Statuscode zu.

HTTP-Statuscodes sind weniger ausdrucksstark als Amazon-S3-Fehlercodes und enthalten weniger Informationen über den Fehler. Beispielsweise werden die Amazon-S3-Fehler NoSuchKey und NoSuchBucket auf den Statuscode HTTP 404 Not Found abgebildet.

Obwohl HTTP-Statuscodes weniger Informationen über den Fehler enthalten, können Clients, die HTTP verstehen, aber nicht die Amazon-S3-API, den Fehler normalerweise korrekt verarbeiten.

Wenn Sie also Fehler verarbeiten oder Amazon-S3-Fehler an Endbenutzer melden, verwenden Sie den Amazon-S3-Fehlercode statt des HTTP-Statuscodes, weil dieser die meisten Informationen über den Fehler enthält. Beim Debuggen Ihrer Anwendung sollten Sie außerdem das lesbare Element <Details> der XML-Fehlerantwort heranziehen.