PUT Objekt
Sie können die S3 PUT-Objektanforderung verwenden, um einem Bucket ein Objekt hinzuzufügen.
Konflikte lösen
Widersprüchliche Clientanforderungen, wie z. B. zwei Clients, die in denselben Schlüssel schreiben, werden auf „latest-WINS“-Basis gelöst. Der Zeitpunkt für die Auswertung „latest-WINS“ basiert darauf, wann das StorageGRID System eine bestimmte Anfrage abschließt, und nicht auf, wenn S3-Clients einen Vorgang starten.
Objektgröße
StorageGRID unterstützt Objekte mit einer Größe von bis zu 5 TB.
Größe der Benutzer-Metadaten
Amazon S3 begrenzt die Größe der benutzerdefinierten Metadaten innerhalb jeder PUT-Anforderung-Kopfzeile auf 2 KB. StorageGRID begrenzt die Benutzermetadaten auf 24 KiB. Die Größe der benutzerdefinierten Metadaten wird gemessen, indem die Summe der Anzahl Bytes in der UTF-8-Codierung jedes Schlüssels und jeden Wert angegeben wird.
UTF-8 Zeichen in Benutzermetadaten
Wenn eine Anfrage UTF-8-Werte im Schlüsselnamen oder -Wert der benutzerdefinierten Metadaten enthält, ist das StorageGRID-Verhalten nicht definiert.
StorageGRID parst oder interpretiert keine entgangenen UTF-8-Zeichen, die im Schlüsselnamen oder -Wert der benutzerdefinierten Metadaten enthalten sind. Entgangenen UTF-8 Zeichen werden als ASCII-Zeichen behandelt:
- 
PUT-, PUT-Objekt-Copy-, GET- und HEAD-Anforderungen sind erfolgreich, wenn benutzerdefinierte Metadaten entgangenen UTF-8-Zeichen enthalten.
 - 
StorageGRID gibt den nicht zurück
x-amz-missing-metaKopfzeile, wenn der interpretierte Wert des Schlüsselnamens oder -Wertes undruckbare Zeichen enthält. 
Grenzwerte für Objekt-Tags
Sie können neue Objekte mit Tags hinzufügen, wenn Sie sie hochladen, oder Sie können sie zu vorhandenen Objekten hinzufügen. StorageGRID und Amazon S3 unterstützen bis zu 10 Tags für jedes Objekt. Tags, die einem Objekt zugeordnet sind, müssen über eindeutige Tag-Schlüssel verfügen. Ein Tag-Schlüssel kann bis zu 128 Unicode-Zeichen lang sein, und Tag-Werte können bis zu 256 Unicode-Zeichen lang sein. Bei den Schlüsseln und Werten wird die Groß-/Kleinschreibung beachtet.
Objekteigentümer
In StorageGRID sind alle Objekte Eigentum des Bucket-Besitzers-Kontos, einschließlich der Objekte, die von einem Konto ohne Eigentümer oder einem anonymen Benutzer erstellt wurden.
Unterstützte Anfrageheader
Die folgenden Anfragezeilen werden unterstützt:
- 
Cache-Control - 
Content-Disposition - 
Content-EncodingWenn Sie angeben
aws-chunkedFürContent-EncodingStorageGRID überprüft die folgenden Elemente nicht:- 
StorageGRID überprüft das nicht
chunk-signatureAuf die Chunk-Daten: - 
StorageGRID überprüft nicht den Wert, den Sie für angeben
x-amz-decoded-content-lengthGegen das Objekt. 
 - 
 - 
Content-Language - 
Content-Length - 
Content-MD5 - 
Content-Type - 
Expires - 
Transfer-EncodingDie Chunked-Übertragungscodierung wird unterstützt, wenn
aws-chunkedZudem wird das Nutzlastsignieren verwendet. - 
x-amz-meta-, Gefolgt von einem Name-Wert-Paar mit benutzerdefinierten Metadaten.Verwenden Sie bei der Angabe des Name-value-Paars für benutzerdefinierte Metadaten dieses allgemeine Format:
x-amz-meta-name: valueWenn Sie die Option benutzerdefinierte Erstellungszeit als Referenzzeit für eine ILM-Regel verwenden möchten, müssen Sie sie verwenden
creation-timeAls Name der Metadaten, die beim Erstellen des Objekts zeichnet. Beispiel:x-amz-meta-creation-time: 1443399726
Der Wert für
creation-timeWird seit dem 1. Januar 1970 als Sekunden ausgewertet.Eine ILM-Regel kann nicht sowohl eine benutzerdefinierte Erstellungszeit für die Referenzzeit als auch die ausgewogenen oder strengen Optionen für das Aufnahmeverhalten verwenden. Beim Erstellen der ILM-Regel wird ein Fehler zurückgegeben.  - 
x-amz-tagging - 
S3-Objektsperrungs-Anfrageheader
- 
x-amz-object-lock-mode - 
x-amz-object-lock-retain-until-date - 
x-amz-object-lock-legal-hold 
 - 
 
- 
SSE-Anfragezeilen:
- 
x-amz-server-side-encryption - 
x-amz-server-side-encryption-customer-key-MD5 - 
x-amz-server-side-encryption-customer-key - 
x-amz-server-side-encryption-customer-algorithm 
 - 
 
Nicht unterstützte Anforderungsheader
Die folgenden Anfragezeilen werden nicht unterstützt:
- 
Der
x-amz-aclDie Anforderungsüberschrift wird nicht unterstützt. - 
Der
x-amz-website-redirect-locationDie Anforderungsüberschrift wird nicht unterstützt und gibt zurückXNotImplemented. 
Optionen der Storage-Klasse
Der x-amz-storage-class Die Anfrageüberschrift wird unterstützt. Der Wert, der für eingereicht wurde x-amz-storage-class Beeinträchtigt, wie StorageGRID Objektdaten während der Aufnahme schützt und nicht die Anzahl der persistenten Kopien des Objekts im StorageGRID System (das durch ILM bestimmt wird)
Wenn die ILM-Regel, die zu einem aufgenommene Objekt passt, die strikte Option für das Aufnahmeverhalten verwendet, wird der aktiviert x-amz-storage-class Kopfzeile hat keine Wirkung.
Für können die folgenden Werte verwendet werden x-amz-storage-class:
- 
STANDARD(Standard)- 
Dual Commit: Wenn die ILM-Regel die Dual Commit-Option für das Aufnahmeverhalten angibt, sobald ein Objekt aufgenommen wird, wird eine zweite Kopie dieses Objekts erstellt und auf einen anderen Storage Node verteilt (Dual Commit). Nach der Bewertung des ILM bestimmt StorageGRID, ob diese anfänglichen vorläufigen Kopien den Anweisungen zur Platzierung in der Regel entsprechen. Andernfalls müssen möglicherweise neue Objektkopien an verschiedenen Standorten erstellt werden, wobei die anfänglichen vorläufigen Kopien unter Umständen gelöscht werden müssen.
 - 
Ausgewogen: Wenn die ILM-Regel die ausgewogene Option angibt und StorageGRID nicht sofort alle Kopien erstellen kann, die in der Regel angegeben sind, erstellt StorageGRID zwei Zwischenkopien auf unterschiedlichen Storage-Nodes.
Wenn StorageGRID sofort alle Objektkopien erstellen kann, die in der ILM-Regel (synchrone Platzierung) angegeben sind, wird der angezeigt
x-amz-storage-classKopfzeile hat keine Wirkung. 
 - 
 - 
REDUCED_REDUNDANCY- 
Dual Commit: Wenn die ILM-Regel die Dual Commit-Option für das Aufnahmeverhalten angibt, erstellt StorageGRID bei Aufnahme des Objekts eine einzelne Interimskopie (Single Commit).
 - 
Ausgewogen: Wenn die ILM-Regel die ausgewogene Option angibt, erstellt StorageGRID nur eine einzige Zwischenkopie, wenn das System nicht sofort alle in der Regel festgelegten Kopien erstellen kann. Wenn StorageGRID eine synchrone Platzierung durchführen kann, hat diese Kopfzeile keine Auswirkung. Der
REDUCED_REDUNDANCYAm besten eignet sich die Option, wenn die ILM-Regel, die mit dem Objekt übereinstimmt, eine einzige replizierte Kopie erstellt. In diesem Fall verwendenREDUCED_REDUNDANCYEine zusätzliche Objektkopie kann bei jedem Aufnahmevorgang nicht mehr erstellt und gelöscht werden. 
Verwenden der
REDUCED_REDUNDANCYUnter anderen Umständen wird eine Option nicht empfohlen.REDUCED_REDUNDANCYErhöhte das Risiko von Objektdatenverlusten bei der Aufnahme Beispielsweise können Sie Daten verlieren, wenn die einzelne Kopie zunächst auf einem Storage Node gespeichert wird, der ausfällt, bevor eine ILM-Evaluierung erfolgen kann. - 
 
Achtung: Nur eine Kopie für einen beliebigen Zeitraum zu haben bedeutet, dass Daten dauerhaft verloren gehen. Wenn nur eine replizierte Kopie eines Objekts vorhanden ist, geht dieses Objekt verloren, wenn ein Speicherknoten ausfällt oder einen beträchtlichen Fehler hat. Während Wartungsarbeiten wie Upgrades verlieren Sie auch vorübergehend den Zugriff auf das Objekt.
Angeben REDUCED_REDUNDANCY Wirkt sich nur darauf aus, wie viele Kopien erstellt werden, wenn ein Objekt zum ersten Mal aufgenommen wird. Er hat keine Auswirkungen auf die Anzahl der Kopien des Objekts, wenn das Objekt von der aktiven ILM-Richtlinie geprüft wird, und führt nicht dazu, dass Daten auf einer niedrigeren Redundanzebene im StorageGRID System gespeichert werden.
Hinweis: Wenn Sie ein Objekt in einen Eimer mit aktivierter S3-Objektsperre aufnehmen, wird der angezeigt REDUCED_REDUNDANCY Option wird ignoriert. Wenn Sie ein Objekt in einen Legacy-konformen Bucket aufnehmen, wird der REDUCED_REDUNDANCY Option gibt einen Fehler zurück. StorageGRID führt immer eine doppelte Einspeisung durch, um Compliance-Anforderungen zu erfüllen.
Anforderungsheader für serverseitige Verschlüsselung
Sie können die folgenden Anforderungsheader verwenden, um ein Objekt mit serverseitiger Verschlüsselung zu verschlüsseln. Die Optionen SSE und SSE-C schließen sich gegenseitig aus.
- 
SSE: Verwenden Sie den folgenden Header, wenn Sie das Objekt mit einem eindeutigen Schlüssel verschlüsseln möchten, der von StorageGRID verwaltet wird.
- 
x-amz-server-side-encryption 
 - 
 - 
SSE-C: Verwenden Sie alle drei dieser Header, wenn Sie das Objekt mit einem eindeutigen Schlüssel verschlüsseln möchten, den Sie bereitstellen und verwalten.
- 
x-amz-server-side-encryption-customer-algorithm: AngabeAES256. - 
x-amz-server-side-encryption-customer-key: Geben Sie Ihren Verschlüsselungsschlüssel für das neue Objekt an. - 
x-amz-server-side-encryption-customer-key-MD5: Geben Sie den MD5-Digest des Verschlüsselungsschlüssels des neuen Objekts an. 
 - 
 
Achtung: die von Ihnen zur Verfügung stellen Verschlüsselungsschlüssel werden nie gespeichert. Wenn Sie einen Verschlüsselungsschlüssel verlieren, verlieren Sie das entsprechende Objekt. Bevor Sie vom Kunden zur Sicherung von Objektdaten bereitgestellte Schlüssel verwenden, prüfen Sie die Überlegungen unter „serverseitige Verschlüsselung verwenden.“
Hinweis: Wenn ein Objekt mit SSE oder SSE-C verschlüsselt ist, werden alle Verschlüsselungseinstellungen auf Bucket-Ebene oder Grid-Ebene ignoriert.
Versionierung
Wenn die Versionierung für einen Bucket aktiviert ist, ist dies ein eindeutiger versionId Wird automatisch für die Version des zu speichernden Objekts generiert. Das versionId Wird auch in der Antwort mit zurückgegeben x-amz-version-id Kopfzeile der Antwort.
Wenn die Versionierung unterbrochen wird, wird die Objektversion mit einem Null gespeichert versionId Und wenn bereits eine Null-Version vorhanden ist, wird sie überschrieben.