Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Best Practice per gli errori Amazon S3

Molte risposte di errore contengono ulteriori dati strutturati destinati a essere letti e compresi da uno sviluppatore che tenti di diagnosticare gli errori di programmazione. Ad esempio, se invii un' Content-MD5 intestazione con una richiesta REST PUT che non corrisponde al digest calcolato sul server, ricevi un errore. BadDigest La risposta all'errore include anche come elementi di dettaglio il digest calcolato e il digest fornito in base alle aspettative. Durante lo sviluppo è possibile utilizzare queste informazioni per la diagnostica dell'errore. In produzione, un programma con un comportamento corretto probabilmente includerebbe queste informazioni in un registro di errore.

Quando si progetta un'applicazione da utilizzare con Amazon S3, è importante gestire correttamente gli errori Amazon S3. Questa sezione descrive i problemi da tenere in considerazione durante la progettazione dell'applicazione.

Riprova InternalErrors

Gli errori interni si verificano nell'ambiente Amazon S3.

Le richieste che ricevono una InternalError risposta potrebbero non essere state elaborate. Ad esempio, se viene restituita una richiesta PUT InternalError, un GET successivo potrebbe recuperare il valore precedente o il valore aggiornato.

Se Amazon S3 restituisce una InternalError risposta, riprova la richiesta.

Ottimizza l'applicazione in caso di errori ripetuti SlowDown

Come ogni sistema distribuito, S3 dispone di meccanismi di protezione che rilevano il consumo eccessivo di risorse, intenzionale o non intenzionale, e reagiscono di conseguenza. SlowDown possono verificarsi errori quando un elevato tasso di richieste attiva uno di questi meccanismi. La riduzione del tasso delle richieste porterà alla diminuzione o eliminazione degli errori di questo tipo. In generale, la maggior parte degli utenti non riscontra questi errori regolarmente; tuttavia, se desideri maggiori informazioni o riscontri SlowDown errori elevati o imprevisti, pubblica un messaggio nel nostro forum per sviluppatori di Amazon S3 o iscriviti a. Supporto https://aws.amazon.com/premiumsupport/

Errori isolati

Amazon S3 fornisce un insieme di codici di errori usati sia dall'API SOAP che dall'API REST. L'API SOAP restituisce codici di errore Amazon S3 standard. L'API REST è progettata per somigliare a un server HTTP standard e interagisce con i client HTTP esistenti (browser, librerie del client HTTP, proxy, cache e così via). Per garantire che i client HTTP gestiscano correttamente gli errori, Amazon S3 associa ogni errore di Amazon S3 a un codice di stato HTTP.

I codici di stato HTTP sono meno intuitivi dei codici di errore Amazon S3 e contengono un minor numero di informazioni sull'errore. Ad esempio, gli errori di Amazon S3 NoSuchKey e NoSuchBucket sono mappati entrambi sul codice di stato HTTP 404 Not Found.

Sebbene i codici di stato HTTP contengano un minor numero di informazioni sull'errore, i client che comprendono l'HTTP ma non l'API di Amazon S3 in genere gestiscono l'errore correttamente.

Per questo motivo, quando si gestiscono o si riportano errori di Amazon S3 agli utenti finali, è opportuno utilizzare il codice di errore di Amazon S3 anziché il codice di stato HTTP, perché contiene il maggior numero possibile di informazioni sull'errore. Inoltre, quando si esegue il debug dell'applicazione, è bene consulta l'elemento <Details> della risposta di errore XML, che può essere letto da un interlocutore umano.