Swift メタデータ
一般に、メタデータはリソースに関連付けられたリソースに関する情報ですが、リソース自体に含まれるデータではありません。メタデータは HTTP ヘッダーを通じて設定および取得されます。(たとえば、Swift オブジェクトの「Content-Type」は HTTP 応答ヘッダーで返されます)
Swift のすべてのユーザー リソース (つまり、アカウント、コンテナー、オブジェクト) は、それらに関連付けられたユーザー メタデータを持つことができます。ミドルウェアはシステム メタデータを使用して、カスタム メタデータをアカウントやコンテナに安全に保存することもできます。sysmeta より前の一部のコア Swift 機能には、カスタムの非ユーザー メタデータ ヘッダー ( ACL、ラージ オブジェクトのサポートなど) の例外が追加されています。
ユーザーメタデータ
ユーザー メタデータの形式は でありX-<type>-meta-<key>:<value>、<type>リソース タイプ (つまり、アカウント、コンテナ、オブジェクト) に依存し、<key>クライアント<value>によって設定されます。
ユーザー メタデータは通常、クライアントまたはクライアント アプリケーションで使用するために予約されている必要があります。ユーザー メタデータの完璧な使用例はpython-swiftclientです。これは、前回のアップロード以降に変更されたファイルのみをアップロードするオプションをX-Object-Meta-Mtime実装するために、アップロードするオブジェクトにメタデータを保存します。--changed
新しいミドルウェアは、新しいメタデータ キーが導入されたときに既存のユーザー メタデータと競合する可能性を避けるために、ユーザー メタデータ名前空間にメタデータを保存しないようにする必要があります。ユーザー メタデータ名前空間から借用する古いミドルウェアの例としては、TempURL があります。ユーザー メタデータの名前空間を回避するためにカスタムの非ユーザー メタデータを使用するミドルウェアの例は、静的ラージ オブジェクトです。
X-<type>-Meta-<key>PUT または POST リクエストによってコンテナーまたはアカウント リソースに保存されたユーザー メタデータは、値のないヘッダーまたは値のないヘッダーを含む後続の PUT または POST リクエストによって明示的に削除されるまで保持されますX-Remove-<type>-Meta-<key>: <ignored-value>。後者の場合、何も保存されません<ignored-value>。アカウントまたはコンテナを削除すると、アカウントまたはコンテナ リソースに保存されているすべてのユーザー メタデータが削除されます。
オブジェクト リソースに保存されているユーザー メタデータには異なるセマンティクスがあります。オブジェクト ユーザー メタデータは、同じオブジェクトに対して後続の PUT または POST リクエストが行われるまで存続します。その時点で、オブジェクトに保存されているすべてのユーザー メタデータは一括で削除され、含まれているユーザー メタデータに置き換えられます。 PUT または POST リクエストで。したがって、一部の項目を変更せずに、オブジェクトとともに保存されているユーザー メタデータ項目のサブセットを更新することはできません。
システムメタデータ
システム メタデータは、リソース タイプ (つまり、アカウント、コンテナ、オブジェクト) に応じたX-<type>-Sysmeta-<key>: <value>形式をとり、Swift WSGI サーバー上で実行される信頼できるコードによって設定されます。<type><key><value>
フォーム内のクライアント要求のすべてのヘッダーは、ミドルウェアによって処理される前にX-<type>-Sysmeta-<key>要求から削除されます。X-<type>-Sysmeta-<key>バックエンド システムからの応答の の形式のすべてのヘッダーは、すべてのミドルウェアが応答を処理した後、応答がクライアントに送信される前に削除されます。詳細については、「Gatekeeperミドルウェア」を参照してください。
システム メタデータは、カスタム メタデータを確認するためにコア Swift サーバーを経由することなく、関連する Swift リソースとともに潜在的にプライベートなカスタム メタデータを安全かつセキュアな方法で保存する方法を提供します。受信フィルターは、クライアント要求によって名前空間が直接変更できないことを保証し、送信フィルターは、特定のシステム メタデータ キーを使用するミドルウェアが削除されて無害になることを保証します。新しいミドルウェアはシステム メタデータを活用する必要があります。
PUT または POST リクエストにヘッダーを含めることで、システム メタデータをアカウントとコンテナに設定できます。ヘッダー名がシステム メタデータの既存の項目の名前と一致する場合、既存の項目の値が更新されます。それ以外の場合は、既存のプロジェクトが保持されます。NULL 値を持つシステム メタデータ ヘッダーにより、同じ名前を持つ既存のアイテムが削除されます。
システム メタデータは、PUT リクエストを使用してオブジェクトにのみ設定できます。既存のシステム メタデータのすべての項目は削除され、PUT リクエストに含まれるシステム メタデータ ヘッダーによって一括で置き換えられます。システム メタデータは、POST リクエスト経由で更新されることも、POST リクエスト経由で削除されることもありません。ユーザー メタデータの個々の項目の更新がサポートされていないのと同様に、POST リクエストによるシステム メタデータの個々の項目の更新もサポートされていません。ミドルウェアが POST リクエストを介して独自のメタデータを保存する必要がある場合、Object Transient-Sysmeta を使用できます。
オブジェクトトランジェント-Sysmeta
ミドルウェアがオブジェクトのメタデータを POST リクエストに保存する必要がある場合は、X-Object-Transient-Sysmeta-<key>: <value>フォーム ヘッダーを使用して保存できます。
フォームに表示されるすべてのX-Object-Transient-Sysmeta-<key>クライアント要求ヘッダーは、ミドルウェアによって処理される前に要求から削除されます。すべてのミドルウェアが応答を処理した後、応答がクライアントに送信される前に、X-Object-Transient-Sysmeta-<key>バックエンド システム応答の形式のすべてのヘッダーが削除されます。詳細については、「Gatekeeperミドルウェア」を参照してください。
オブジェクトの Transient-sysmeta 更新は、オブジェクトのユーザー メタデータ更新と同じセマンティクスを持ちます (ユーザー メタデータを参照)。つまり、オブジェクトに対して PUT または POST リクエストが行われるたびに、既存のすべての Transient-sysmeta アイテムが一括削除され、次のものに置き換えられます。 PUT または POST リクエストに含まれる任意の Transient-sysmeta。したがって、ミドルウェアがすべての POST に Transient-sysmeta を含めるように注意しない限り、ミドルウェアによって設定された Transient-sysmeta は、後続のクライアント生成の POST 要求によって簡単に削除されます。同様に、クライアントによって設定されたユーザー メタデータは、ミドルウェアによって生成される後続の POST リクエストによって簡単に削除される可能性があるため、ミドルウェアはクライアント リクエストとは独立して POST リクエストを生成することを避ける必要があります。
Transient-sysmeta は、ミドルウェアがユーザー メタデータ キーとの潜在的な競合を回避できるように、ユーザー メタデータとは異なるヘッダー プレフィックスを意図的に使用します。
Transient-sysmeta は、システム メタデータに意図的に異なるヘッダー プレフィックスを使用して、データは後続の POST まで変更されないだけであるという事実を強調します。