Skip to main content
Eine neuere Version dieses Produkts ist erhältlich.
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Operationen auf Buckets

Beitragende
PDFs

Das StorageGRID System unterstützt für jedes S3-Mandantenkonto maximal 1,000 Buckets.

Einschränkungen für Bucket-Namen folgen den regionalen Beschränkungen für AWS US Standard. Sie sollten sie jedoch noch weiter auf DNS-Namenskonventionen beschränken, um Anfragen im Stil von virtuellen S3-Hosted-Style zu unterstützen.

"Amazon Web Services (AWS) Dokumentation: Bucket-Einschränkungen und -Einschränkungen"

"Endpoint-Domain-Namen für S3-Anforderung"

Operationen „GET Bucket“ (Listenobjekte) und „GET Bucket-Versionen“ unterstützen die StorageGRID-Konsistenzkontrollen.

Sie können überprüfen, ob für einzelne Buckets Updates zur letzten Zugriffszeit aktiviert oder deaktiviert wurden.

In der folgenden Tabelle wird beschrieben, wie StorageGRID S3-REST-API-Bucket-Operationen implementiert Um einen dieser Vorgänge durchzuführen, müssen die erforderlichen Anmeldedaten für den Zugriff für das Konto bereitgestellt werden.

Betrieb Implementierung

Bucket LÖSCHEN

Wird mit dem gesamten Amazon S3-REST-API-Verhalten implementiert.

Bucket-Cors LÖSCHEN

Durch diesen Vorgang wird die CORS-Konfiguration für den Bucket gelöscht.

Bucket-Verschlüsselung LÖSCHEN

Bei diesem Vorgang wird die Standardverschlüsselung aus dem Bucket gelöscht. Vorhandene verschlüsselte Objekte bleiben verschlüsselt, neue dem Bucket hinzugefügte Objekte werden jedoch nicht verschlüsselt.

Bucket-Lebenszyklus LÖSCHEN

Bei diesem Vorgang wird die Lebenszyklukonfiguration aus dem Bucket gelöscht.

Bucket-Richtlinie LÖSCHEN

Bei diesem Vorgang wird die Richtlinie gelöscht, die dem Bucket zugeordnet ist.

Bucket-Replizierung LÖSCHEN

Bei diesem Vorgang wird die an den Bucket angeschlossene Replizierungskonfiguration gelöscht.

Bucket-Tagging LÖSCHEN

Dieser Vorgang verwendet das tagging unterressource, um alle Tags aus einem Bucket zu entfernen

Get Bucket (Listenobjekte), Version 1 und Version 2

Dieser Vorgang gibt einige oder alle (bis zu 1,000) Objekte in einem Bucket zurück. Die Speicherklasse für Objekte kann einen von zwei Werten haben, auch wenn das Objekt mit aufgenommen wurde REDUCED_REDUNDANCY Option für Storage-Klasse:

  • STANDARD, Die angibt, dass das Objekt in einem Speicherpool gespeichert wird, der aus Storage-Nodes besteht.

  • GLACIER, Dies bedeutet, dass das Objekt in den vom Cloud-Speicherpool angegebenen externen Bucket verschoben wurde.

Wenn der Bucket eine große Anzahl von gelöschten Schlüsseln enthält, die dasselbe Präfix haben, kann die Antwort einige enthalten CommonPrefixes Die keine Schlüssel enthalten.

Bucket-acl ABRUFEN

Dieser Vorgang gibt eine positive Antwort und die ID, DisplayName und die Erlaubnis des Bucket-Besitzers zurück, was darauf hinweist, dass der Besitzer vollen Zugriff auf den Bucket hat.

Bucket-Cors ABRUFEN

Dieser Vorgang gibt den zurück cors Konfiguration für den Bucket.

Get Bucket-Verschlüsselung

Dieser Vorgang gibt die Standardverschlüsselungskonfiguration für den Bucket zurück.

BUCKET-Lebenszyklus ABRUFEN

Dieser Vorgang gibt die Lifecycle-Konfiguration für den Bucket zurück.

Bucket-Speicherort ABRUFEN

Dieser Vorgang gibt die Region zurück, die mit dem festgelegt wurde LocationConstraint Element in DER PUT Bucket Anforderung. Wenn der Eimer-Bereich ist us-east-1, Eine leere Zeichenfolge wird für die Region zurückgegeben.

Bucket-Benachrichtigung ABRUFEN

Dieser Vorgang gibt die Benachrichtigungskonfiguration an den Bucket zurück.

Get Bucket-Objektversionen

Mit LESEZUGRIFF auf einen Bucket erfolgt dieser Vorgang mit dem versions unterressource listet Metadaten aller Versionen von Objekten im Bucket auf.

Get Bucket-Richtlinie

Dieser Vorgang gibt die Richtlinie zurück, die dem Bucket zugeordnet ist.

GET Bucket-Replizierung

Dieser Vorgang gibt die am Bucket angeschlossene Replizierungskonfiguration zurück.

Get Bucket-Tagging

Dieser Vorgang verwendet das tagging unterressource, um alle Tags für einen Bucket zurückzugeben

Get Bucket-Versionierung

Diese Implementierung verwendet das versioning subressource zur Rückgabe des Versionierungsstatus eines Buckets. Der zurückgegebene Versionierungsstatus gibt an, ob der Bucket die Version „Unversioniert“ oder die Version „Enabled“ oder „Suspended“ lautet.

Konfiguration der Objektsperre ABRUFEN

Dieser Vorgang legt fest, ob die S3-Objektsperre für einen Bucket aktiviert ist. "Verwenden der S3-Objektsperre"

EIMER

Dieser Vorgang bestimmt, ob ein Bucket vorhanden ist und Sie über die Berechtigung zum Zugriff auf ihn verfügen.

Put Bucket

Durch diesen Vorgang wird ein neuer Bucket erstellt. Mit dem Erstellen des Buckets werden Sie zum Bucket-Eigentümer.

  • Bucket-Namen müssen die folgenden Regeln einhalten:

    • Jedes StorageGRID System muss eindeutig sein (nicht nur innerhalb des Mandantenkontos).

    • Muss DNS-konform sein.

    • Darf mindestens 3 und nicht mehr als 63 Zeichen enthalten.

    • Kann eine Reihe von einer oder mehreren Etiketten sein, wobei angrenzende Etiketten durch einen Zeitraum getrennt sind. Jedes Etikett muss mit einem Kleinbuchstaben oder einer Zahl beginnen und enden. Es können nur Kleinbuchstaben, Ziffern und Bindestriche verwendet werden.

    • Darf nicht wie eine Text-formatierte IP-Adresse aussehen.

    • Perioden sollten nicht in Anforderungen im virtuellen gehosteten Stil verwendet werden. Perioden verursachen Probleme bei der Überprüfung des Server-Platzhalterzertifikats.

  • Standardmäßig werden Buckets im erstellt us-east-1 Region; jedoch können Sie die verwenden LocationConstraint Anforderungselement im Anforderungskörper, um eine andere Region anzugeben. Bei Verwendung des LocationConstraint Element, Sie müssen den genauen Namen einer Region angeben, die mit dem Grid Manager oder der Grid Management API definiert wurde. Wenden Sie sich an Ihren Systemadministrator, wenn Sie den Namen der zu verwendenden Region nicht kennen. Hinweis: Ein Fehler tritt auf, wenn Ihre PUT Bucket-Anforderung eine Region verwendet, die nicht in StorageGRID definiert wurde.

  • Sie können die einschließen x-amz-bucket-object-lock-enabled Kopfzeile zum Erstellen eines Buckets anfordern, wobei S3-Objektsperre aktiviert ist.

    Sie müssen die S3-Objektsperre aktivieren, wenn Sie den Bucket erstellen. Sie können S3 Object Lock nicht hinzufügen oder deaktivieren, nachdem ein Bucket erstellt wurde. Für die S3-Objektsperre ist eine Bucket-Versionierung erforderlich. Diese wird bei der Erstellung des Buckets automatisch aktiviert.

    "Verwenden der S3-Objektsperre"

Bucket-Cors EINGEBEN

Mit diesem Vorgang wird die CORS-Konfiguration für einen Bucket festgelegt, damit der Bucket die Cross-Origin-Requests bedienen kann. CORS (Cross-Origin Resource Sharing) ist ein Sicherheitsmechanismus, mit dem Client-Webanwendungen in einer Domäne auf Ressourcen in einer anderen Domäne zugreifen können. Angenommen, Sie verwenden einen S3-Bucket mit dem Namen images Zum Speichern von Grafiken. Durch Festlegen der CORS-Konfiguration für das images Bucket: Sie können zulassen, dass die Bilder in diesem Bucket auf der Website angezeigt werden http://www.example.com.

Bucket-Verschlüsselung

Dieser Vorgang legt den Standardverschlüsselungsstatus eines vorhandenen Buckets fest. Bei aktivierter Verschlüsselung auf Bucket-Ebene sind alle neuen dem Bucket hinzugefügten Objekte verschlüsselt.StorageGRID unterstützt serverseitige Verschlüsselung mit von StorageGRID gemanagten Schlüsseln. Wenn Sie die Konfigurationsregel für die serverseitige Verschlüsselung angeben, legen Sie die fest SSEAlgorithm Parameter an AES256, Und verwenden Sie nicht die KMSMasterKeyID Parameter.

Die Standardverschlüsselungskonfiguration von Buckets wird ignoriert, wenn in der Anfrage für das Hochladen von Objekten bereits eine Verschlüsselung angegeben ist (d. h., wenn die Anforderung den umfasst x-amz-server-side-encryption-* Kopfzeile der Anfrage).

PUT Bucket-Lebenszyklus

Dieser Vorgang erstellt eine neue Lifecycle-Konfiguration für den Bucket oder ersetzt eine vorhandene Lifecycle-Konfiguration. StorageGRID unterstützt in einer Lebenszykluskonfiguration bis zu 1,000 Lebenszyklusregeln. Jede Regel kann die folgenden XML-Elemente enthalten:

  • Ablauf (Tage, Datum)

  • NoncurrentVersionExpiration (NoncurrentDays)

  • Filter (Präfix, Tag)

  • Status

  • ID

StorageGRID bietet folgende Maßnahmen nicht:

  • AbortInsetteMultipartUpload

  • ExpiredObjectDeleteMarker

  • Übergang

Informationen dazu, wie die Aktion zum Ablauf in einem Bucket-Lebenszyklus mit den Anweisungen zur ILM-Platzierung interagiert, finden Sie unter „wie ILM während der gesamten Lebensdauer eines Objekts funktioniert“ in den Anweisungen für das Management von Objekten mit Information Lifecycle Management.

Hinweis: Die Konfiguration des Bucket-Lebenszyklus kann für Buckets verwendet werden, für die S3-Objektsperre aktiviert ist. Die Bucket-Lebenszykluskonfiguration wird jedoch für ältere kompatible Buckets nicht unterstützt.

PUT Bucket-Benachrichtigung

Mit diesem Vorgang werden Benachrichtigungen für den Bucket mithilfe der im Anfraentext enthaltenen XML-Benachrichtigungskonfiguration konfiguriert. Sie sollten folgende Implementierungsdetails kennen:

  • StorageGRID unterstützt SNS-Themen (Simple Notification Service) als Ziele. Simple Queue Service (SQS)- oder Amazon Lambda-Endpunkte werden nicht unterstützt.

  • Das Ziel für Benachrichtigungen muss als URN eines StorageGRID-Endpunkts angegeben werden. Endpunkte können mit dem Mandanten-Manager oder der Mandanten-Management-API erstellt werden.

    Der Endpunkt muss vorhanden sein, damit die Benachrichtigungskonfiguration erfolgreich ausgeführt werden kann. Wenn der Endpunkt nicht vorhanden ist, A 400 Bad Request Der Code gibt einen Fehler zurück InvalidArgument.

  • Sie können keine Benachrichtigung für die folgenden Ereignistypen konfigurieren. Diese Ereignistypen werden nicht unterstützt.

    • s3:ReducedRedundancyLostObject

    • s3:ObjectRestore:Completed

  • Von StorageGRID gesendete Ereignisbenachrichtigungen verwenden das Standard-JSON-Format, mit der Ausnahme, dass sie einige Schlüssel nicht enthalten und bestimmte Werte für andere verwenden, wie in der folgenden Liste gezeigt:

  • EventSource

    sgws:s3

  • AwsRegion

    Nicht enthalten

  • * X-amz-id-2*

    Nicht enthalten

  • arn

    urn:sgws:s3:::bucket_name

Bucket-Richtlinie

Dieser Vorgang legt die Richtlinie fest, die an den Bucket gebunden ist.

PUT Bucket-Replizierung

Dieser Vorgang konfiguriert die StorageGRID CloudMirror-Replikation für den Bucket mithilfe der im Anforderungsgremium bereitgestellten Replikationskonfigurations-XML. Für die CloudMirror-Replikation sollten Sie die folgenden Implementierungsdetails beachten:

  • StorageGRID unterstützt nur V1 der Replizierungskonfiguration. Das bedeutet, dass StorageGRID die Verwendung von nicht unterstützt Filter Element für Regeln und folgt V1-Konventionen zum Löschen von Objektversionen. Details finden Sie in der Amazon Dokumentation zur Replizierungskonfiguration.

  • Die Bucket-Replizierung kann für versionierte oder nicht versionierte Buckets konfiguriert werden.

  • Sie können in jeder Regel der XML-Replikationskonfiguration einen anderen Ziel-Bucket angeben. Ein Quell-Bucket kann auf mehrere Ziel-Bucket replizieren.

  • Ziel-Buckets müssen als URN der StorageGRID-Endpunkte angegeben werden, wie im Mandantenmanager oder der Mandantenmanagement-API angegeben.

    Der Endpunkt muss vorhanden sein, damit die Replizierungskonfiguration erfolgreich ausgeführt werden kann. Wenn der Endpunkt nicht vorhanden ist, schlägt die Anforderung als a fehl 400 Bad Request. In der Fehlermeldung steht: Unable to save the replication policy. The specified endpoint URN does not exist: URN.

  • Sie müssen kein angeben Role In der Konfigurations-XML. Dieser Wert wird von StorageGRID nicht verwendet und wird bei der Einreichung ignoriert.

  • Wenn Sie die Storage-Klasse aus der XML-Konfiguration weglassen, verwendet StorageGRID das STANDARD Standardmäßig Storage-Klasse.

  • Wenn Sie ein Objekt aus dem Quell-Bucket löschen oder den Quell-Bucket selbst löschen, sieht das Verhalten der regionsübergreifenden Replizierung wie folgt aus:

    • Wenn Sie das Objekt oder Bucket vor der Replizierung löschen, wird das Objekt/Bucket nicht repliziert, und Sie werden nicht benachrichtigt.

    • Wenn Sie das Objekt oder Bucket nach der Replizierung löschen, befolgt StorageGRID das standardmäßige Löschverhalten von Amazon S3 für die V1 der regionsübergreifenden Replizierung.

PUT Bucket-Tagging

Dieser Vorgang verwendet das tagging unterressource, um einen Satz von Tags für einen Bucket hinzuzufügen oder zu aktualisieren Beachten Sie beim Hinzufügen von Bucket-Tags die folgenden Einschränkungen:

  • StorageGRID und Amazon S3 unterstützen für jeden Bucket bis zu 50 Tags.

  • Tags, die einem Bucket zugeordnet sind, müssen eindeutige Tag-Schlüssel haben. Ein Tag-Schlüssel kann bis zu 128 Unicode-Zeichen lang sein.

  • Die Tag-Werte können bis zu 256 Unicode-Zeichen lang sein.

  • Bei den Schlüsseln und Werten wird die Groß-/Kleinschreibung beachtet.

PUT Bucket-Versionierung

Diese Implementierung verwendet das versioning unterressource, um den Versionierungsstatus eines vorhandenen Buckets festzulegen. Sie können den Versionierungsstatus mit einem der folgenden Werte festlegen:

  • Aktiviert: Versionierung für die Objekte im Bucket Alle dem Bucket hinzugefügten Objekte erhalten eine eindeutige Version-ID.

  • Suspendiert: Deaktiviert die Versionierung für die Objekte im Bucket. Alle dem Bucket hinzugefügten Objekte erhalten die Version-ID null.
Verwandte Informationen

"Amazon Web Services (AWS) Dokumentation: Regionsübergreifende Replizierung"

"Konsistenzkontrollen"

"Anforderung der Uhrzeit des letzten Bucket-Zugriffs ABRUFEN"

"Bucket- und Gruppenzugriffsrichtlinien"

"Verwenden der S3-Objektsperre"

"S3-Vorgänge werden in den Audit-Protokollen protokolliert"

"Objektmanagement mit ILM"

"Verwenden Sie ein Mandantenkonto"

Erstellen einer S3-Lebenszykluskonfiguration

Sie können eine S3-Lebenszyklukonfiguration erstellen, um zu steuern, wann bestimmte Objekte aus dem StorageGRID System gelöscht werden.

Das einfache Beispiel in diesem Abschnitt veranschaulicht, wie eine S3-Lebenszykluskonfiguration das Löschen bestimmter Objekte aus bestimmten S3-Buckets kontrollieren kann. Das Beispiel in diesem Abschnitt dient nur zu Illustrationszwecken. Alle Details zum Erstellen von S3-Lebenszykluskonfigurationen finden Sie im Abschnitt zum Lifecycle Management von Objekten im Amazon Simple Storage Service Developer Guide. Beachten Sie, dass StorageGRID nur Aktionen nach Ablauf unterstützt. Es werden keine Aktionen zur Transition unterstützt.

"Amazon Simple Storage Service Developer Guide: Lifecycle Management von Objekten"

Was für eine Lebenszykluskonfiguration ist

Eine Lifecycle-Konfiguration ist ein Satz von Regeln, die auf die Objekte in bestimmten S3-Buckets angewendet werden. Jede Regel gibt an, welche Objekte betroffen sind und wann diese Objekte ablaufen (an einem bestimmten Datum oder nach einigen Tagen).

StorageGRID unterstützt in einer Lebenszykluskonfiguration bis zu 1,000 Lebenszyklusregeln. Jede Regel kann die folgenden XML-Elemente enthalten:

  • Ablauf: Löschen eines Objekts, wenn ein bestimmtes Datum erreicht wird oder wenn eine bestimmte Anzahl von Tagen erreicht wird, beginnend mit dem Zeitpunkt der Aufnahme des Objekts.

  • NoncurrentVersionExpiration: Löschen Sie ein Objekt, wenn eine bestimmte Anzahl von Tagen erreicht wird, beginnend ab dem Zeitpunkt, an dem das Objekt nicht mehr aktuell wurde.

  • Filter (Präfix, Tag)

  • Status

  • ID

Wenn Sie eine Lifecycle-Konfiguration auf einen Bucket anwenden, überschreiben die Lifecycle-Einstellungen für den Bucket immer die StorageGRID-ILM-Einstellungen. StorageGRID verwendet die Verfallseinstellungen für den Bucket und nicht ILM, um zu bestimmen, ob bestimmte Objekte gelöscht oder aufbewahrt werden sollen.

Aus diesem Grund kann ein Objekt aus dem Grid entfernt werden, obwohl die Speicheranweisungen in einer ILM-Regel noch auf das Objekt gelten. Alternativ kann ein Objekt auch dann im Grid aufbewahrt werden, wenn eine ILM-Platzierungsanleitung für das Objekt abgelaufen ist. Weitere Informationen finden Sie unter „Funktionsweise von ILM während der gesamten Lebensdauer eines Objekts“ in den Anweisungen zum Verwalten von Objekten mit Information Lifecycle Management.

Hinweis Die Bucket-Lifecycle-Konfiguration kann für Buckets verwendet werden, für die S3-Objektsperre aktiviert ist. Die Bucket-Lifecycle-Konfiguration wird jedoch für ältere Buckets, die Compliance verwenden, nicht unterstützt.

StorageGRID unterstützt den Einsatz der folgenden Bucket-Operationen zum Management der Lebenszykluskonfigurationen:

  • Bucket-Lebenszyklus LÖSCHEN

  • BUCKET-Lebenszyklus ABRUFEN

  • PUT Bucket-Lebenszyklus

Erstellen der Lebenszykluskonfiguration

Als erster Schritt beim Erstellen einer Lebenszykluskonfiguration erstellen Sie eine JSON-Datei mit einem oder mehreren Regeln. Diese JSON-Datei enthält beispielsweise drei Regeln:

  1. Regel 1 gilt nur für Objekte, die mit dem Präfix übereinstimmen category1/ Und das hat ein key2 Der Wert von tag2. Der Expiration Der Parameter gibt an, dass Objekte, die dem Filter entsprechen, um Mitternacht am 22. August 2020 ablaufen.

  2. Regel 2 gilt nur für Objekte, die mit dem Präfix übereinstimmen category2/. Der Expiration Parameter gibt an, dass Objekte, die dem Filter entsprechen, 100 Tage nach der Aufnahme ablaufen.

    Wichtig Regeln, die eine Anzahl von Tagen angeben, sind relativ zu dem Zeitpunkt, an dem das Objekt aufgenommen wurde. Wenn das aktuelle Datum das Aufnahmedatum plus die Anzahl der Tage überschreitet, werden einige Objekte möglicherweise aus dem Bucket entfernt, sobald die Lebenszykluskonfiguration angewendet wird.

  3. Regel 3 gilt nur für Objekte, die dem Präfix entsprechen category3/. Der Expiration Parameter gibt an, dass nicht aktuelle Versionen übereinstimmender Objekte 50 Tage nach deren Nichtstrom ablaufen.

{
	"Rules": [
        {
		    "ID": "rule1",
			"Filter": {
                "And": {
                    "Prefix": "category1/",
                    "Tags": [
                        {
                            "Key": "key2",
							"Value": "tag2"
                        }
                    ]
                }
            },
			"Expiration": {
                "Date": "2020-08-22T00:00:00Z"
            },
            "Status": "Enabled"
        },
		{
            "ID": "rule2",
			"Filter": {
                "Prefix": "category2/"
            },
			"Expiration": {
                "Days": 100
            },
            "Status": "Enabled"
        },
		{
            "ID": "rule3",
			"Filter": {
                "Prefix": "category3/"
            },
			"NoncurrentVersionExpiration": {
                "NoncurrentDays": 50
            },
            "Status": "Enabled"
        }
    ]
}

Anwenden einer Lebenszykluskonfiguration auf einen Bucket

Nachdem Sie die Lifecycle-Konfigurationsdatei erstellt haben, wenden Sie sie durch Ausgabe einer PUT Bucket Lifecycle-Anforderung auf einen Bucket an.

Diese Anforderung wendet die Lebenszykluskonfiguration in der Beispieldatei auf Objekte in einem Bucket mit dem Namen an testbucket:Eimer

aws s3api --endpoint-url <StorageGRID endpoint> put-bucket-lifecycle-configuration
--bucket testbucket --lifecycle-configuration file://bktjson.json

Um zu überprüfen, ob eine Lifecycle-Konfiguration erfolgreich auf den Bucket angewendet wurde, geben Sie eine ANFORDERUNG FÜR DEN GET Bucket-Lebenszyklus aus. Beispiel:

aws s3api --endpoint-url <StorageGRID endpoint> get-bucket-lifecycle-configuration
 --bucket testbucket

Eine erfolgreiche Antwort zeigt die Konfiguration des Lebenszyklus, die Sie gerade angewendet haben.

Überprüfung, ob der Bucket-Lebenszyklus für ein Objekt gilt

Sie können feststellen, ob eine Ablaufregel in der Lebenszykluskonfiguration auf ein bestimmtes Objekt angewendet wird, wenn Sie eine PUT-Objekt-, HEAD-Objekt- oder GET-Objektanforderung ausgeben. Wenn eine Regel zutrifft, enthält die Antwort ein Expiration Parameter, der angibt, wann das Objekt abläuft und welche Ablaufregel übereinstimmt.

Hinweis Da der Bucket-Lebenszyklus ILM überschreibt, wird der expiry-date Hier wird das tatsächliche Datum angezeigt, an dem das Objekt gelöscht wird. Weitere Informationen finden Sie unter „wie die Aufbewahrung von Objekten bestimmt wird“ in den Anweisungen zur Durchführung der StorageGRID-Administration.

Zum Beispiel, diese PUT Objekt Anfrage wurde am 22. Juni 2020 und platziert ein Objekt in der testbucket Eimer.

aws s3api --endpoint-url <StorageGRID endpoint> put-object
--bucket testbucket --key obj2test2 --body bktjson.json

Die Erfolgsreaktion zeigt an, dass das Objekt in 100 Tagen (01. Oktober 2020) abläuft und dass es mit Regel 2 der Lebenszykluskonfiguration übereinstimmt.

{
      *"Expiration": "expiry-date=\"Thu, 01 Oct 2020 09:07:49 GMT\", rule-id=\"rule2\"",
      "ETag": "\"9762f8a803bc34f5340579d4446076f7\""
}

Diese HEAD Object-Anfrage wurde beispielsweise verwendet, um Metadaten für dasselbe Objekt im Testbucket zu erhalten.

aws s3api --endpoint-url <StorageGRID endpoint> head-object
--bucket testbucket --key obj2test2

Die Erfolgsreaktion umfasst die Metadaten des Objekts und gibt an, dass das Objekt in 100 Tagen abläuft und dass es mit Regel 2 übereinstimmt.

{
      "AcceptRanges": "bytes",
      *"Expiration": "expiry-date=\"Thu, 01 Oct 2020 09:07:48 GMT\", rule-id=\"rule2\"",
      "LastModified": "2020-06-23T09:07:48+00:00",
      "ContentLength": 921,
      "ETag": "\"9762f8a803bc34f5340579d4446076f7\""
      "ContentType": "binary/octet-stream",
      "Metadata": {}
}
Verwandte Informationen

"Operationen auf Buckets"

"Objektmanagement mit ILM"