構造化実体札

構造化実体タグ (HTTP)

[2] 構造化実体タグ (structured entity tag) は、異体リスト検証子を含んだ実体タグです。

仕様書

構文

[3] 構造化実体タグは、最後の ; とそれ以降末尾の " の直前までを除去する (とともに W/ を無視する) と異体リスト検証子となるような実体タグです。

[8] 起源鯖は通常の実体タグを次のように生成するべきです >>1

文脈

[7] 透過的に折衝された応答実体タグを含む場合は、 構造化実体タグでなければなりません >>1。 またその異体リスト検証子部分は当該応答Alternates: ヘッダーキャッシュ検証子となるものでなければなりません。 通常の実体タグの部分は応答payload body および Alternates: 以外の実体ヘッダーキャッシュ検証子となるものでなければなりません >>1

処理モデル

[5] 透過内容折衝に対応したは、構造化実体タグの構造を使ってキャッシュを最適化できます >>1

[6] 構造を使った最適化を行わない時は、通常の実体タグとして処理するべきです >>1

歴史

[42] RFC 2295 (HTTP 透過内容折衝) 9.2 Structured entity tags

A structured entity tag consists of a normal entity tag of which the opaque string is extended with a semicolon followed by the text (without the surrounding quotes) of a variant list validator:

構造化実体札は、通常の実体札である不透明文字列の後にセミコロンと変種目録検証子の文を (囲んでいる引用符なしで) 続けたものです。

        normal      |  variant list  |   structured
        entity tag  |  validator     |   entity tag
       -------------+----------------+-----------------
         "etag"     |     "vlv"      |   "etag;vlv"
        W/"etag"    |     "vlv"      |  W/"etag;vlv"

Note that a structured entity tag is itself also an entity tag. The structured nature of the tag allows caching proxies capable of transparent content negotiation to perform some optimizations defined in section 10. When not performing such optimizations, a structured tag SHOULD be treated as a single opaque value, according to the general rules in HTTP/1.1. Examples of structured entity tags are:

構造化実体札自体も実体札であることに注意してください。 札の構造化性により、10章で定義する最適化が行えます。 その最適化を行わない時は、構造化札は HTTP/1.1 の一般規則に従った単一の不透明値として扱うべきです。 構造化実体札の例 :

      "xyzzy;1234"  W/"xyzzy;1234"  "gonkxxxx;1234"  "a;b;c;;1234"

In the last example, the normal entity tag is "a;b;c;" and the variant list validator is "1234".

最後の例では、通常の実体札は a;b;c; で変種目録検証子は 1234 です。

If a transparently negotiated response includes an entity tag, it MUST be a structured entity tag. The variant list validator in the structured tag MUST act as a validator for the variant list contained in the Alternates header. The normal entity tag in the structured tag MUST act as a validator of the entity body in the response and of all entity headers except Alternates.

透過折衝可能資源が実体札を含む場合、それは構造化実体札でなければなりません。 構造化札の変種目録検証子は Alternates 頭に含まれる変種目録検証子として働かなければなりません。 構造化札の通常の実体札は応答の実体本体及び Alternates 以外のすべての実体札の検証子として働かなければなりません

[41] RFC 2295 (HTTP 透過内容折衝) 9.3 Assigning entity tags to variants

To allow for correct revalidation of transparently negotiated responses by clients, origin servers SHOULD generate all normal entity tags for the neighboring variant resources of the negotiable resource in such a way that

クライアントが透過折衝応答を正しく再検証することができるように、 起源サーバーは折衝可能資源の隣接変種資源についてのすべての通常の実体札を

  • 1. the same tag is never used by two different variants, unless this tag labels exactly the same entity on all occasions,
  • 2. if one normal tag "X" is a prefix of another normal tag "XY", then "Y" must never be a semicolon followed by a variant list validator.
  • 2つの異なる変種について同じ札は絶対に使用しない。 但しこの札がすべての場合に本当に同じ実体を札付けする場合を除く。
  • 通常の札 X が他の通常の札 XY の接頭辞であるなら、 Y はセミコロンとそれに続く変種目録検証子には決してならない。

となるように生成するべきです