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
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.
Wiederholung bei InternalErrors
Interne Fehler sind Fehler, die innerhalb der Amazon-S3-Umgebung auftreten.
Anfragen, die eine InternalError-Antwort erhalten, wurden möglicherweise nicht verarbeitet. Gibt eine PUT-Anfrage beispielsweise einen InternalError zurück, ruft ein nachfolgendes GET möglicherweise den alten Wert oder den aktuellen Wert ab.
Wenn Amazon S3 eine InternalError-Antwort zurückgibt, wiederholen Sie die Anforderung.
Optimieren der Anwendung für wiederholte SlowDown-Fehler
Wie jedes verteilte System besitzt S3 Schutzmechanismen, die einen beabsichtigten oder nicht beabsichtigten übermäßigen Ressourcenverbrauch erkennen und entsprechend reagieren. SlowDown-Fehler können auftreten, wenn eine hohe Anfragerate einen dieser Mechanismen auslöst. Eine Reduzierung Ihrer Anfragerate verringert oder eliminiert Fehler dieses Typs. Im Allgemeinen werden die meisten Benutzer diese Fehler nicht regelmäßig sehen. Wenn Sie jedoch weitere Informationen wünschen oder viele oder unerwartete SlowDown-Fehler sehen, posten Sie bitte in unserem Amazon-S3-Entwicklerforum
Isolieren von Fehlern
Anmerkung
Die SOAP-Unterstützung über HTTP ist veraltet, SOAP steht über HTTPS aber noch zur Verfügung. Neue Amazon-S3-Funktionen werden unter SOAP nicht unterstützt. Wir empfehlen, statt SOAP entweder die REST-API oder die AWS-SDKs zu verwenden.
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äß verarbeiten, bilden wir jeden Amazon-S3-Fehler auf einen HTTP-Statuscode ab.
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.
