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
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.
Errori interni
Gli errori interni si verificano nell'ambiente Amazon S3.
Le richieste che ricevono una risposta di InternalError potrebbero non essere state elaborate. Ad esempio, se una richiesta PUT restituisce InternalError, una GET successiva potrebbe recuperare o il vecchio valore o quello aggiornato.
Se Amazon S3 restituisce una risposta di InternalError, provare a inviare di nuovo la richiesta.
Regolare l'applicazione in caso di errore di rallentamento ripetuto
Come con ogni sistema distribuito, S3 è dotato di meccanismi di protezione che rilevano il consumo eccessivo di risorse, voluto o accidentale, e rispondono di conseguenza. Gli errori di SlowDown possono verificarsi quando un tasso elevato 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 riscontrerà questi errori regolarmente; tuttavia, se desideri maggiori informazioni o stai riscontrando errori di SlowDown numerosi o imprevisti, pubblica una richiesta sul nostro forum degli sviluppatori di Amazon S3
Errori isolati
Nota
Il supporto di SOAP su HTTP non viene più utilizzato ma è ancora disponibile su HTTPS. Le nuove funzioni di Amazon S3 non sono supportate per SOAP. Invece di utilizzare SOAP, si consiglia di utilizzare REST API o gli SDK AWS.
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 assicurarci che i client HTTP gestiscano correttamente gli errori, mappiamo ogni errore di Amazon S3 su 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.
