HTTP 用の retrofit 有構造フィールド

1.1. ~retrofit有構造~fieldの利用-法

広く配備された既存の~HTTP~fieldに~data構造を~retrofitすることには、 相互運用能と~securityを確約するよう，注意深い取扱いが要求される。 この節では、 ~retrofit有構造~fieldを利用する応用~用に考慮点を強調する。 ◎ Retrofitting data structures onto existing and widely-deployed HTTP fields requires careful handling to assure interoperability and security. This section highlights considerations for applications that use Retrofit Structured Fields.

~HTTP流通~内で見られる~field値のうち大多数は，成功裡に［ 構文解析される／対応付けられる ］ことが可能になるはずだが、 そうでないものもある。 ~retrofit有構造~fieldを利用している応用は， そのような値をどう取扱うことになるかを定義する必要がある。 ◎ While the majority of field values seen in HTTP traffic should be able to be parsed or mapped successfully, some will not. An application using Retrofit Structured Fields will need to define how unsuccessful values will be handled.

例えば，`有構造~field$用の~data型を利用して~field値を公開する~APIは、 当の~fieldが成功裡に［ 構文解析され／対応付けられ ］なかった事例では，その値を文字列として可用にするかもしれない。 ◎ For example, an API that exposes field values using Structured Fields data types might make the field value available as a string in cases where the field did not successfully parse or map.

`対応付けられる~field＠#mapped§に述べられる~field値は、 各自の~fieldの元の構文とは互換でない — なので、［ それらを処理している各~主体が，その形を成す~field値~用に~supportを明示的に指示した場合 ］を除き，利用し得ない。 ~retrofit有構造~fieldを利用している応用は、 互いの~supportを折衝する方法を定義する必要がある。 ◎ The mapped field values described in Section 3 are not compatible with the original syntax of their fields, and so cannot be used unless parties processing them have explicitly indicated their support for that form of the field value. An application using Retrofit Structured Fields will need to define how to negotiate support for them.

例えば，`有構造~field$の利点をとるために各~fieldに代替な直列化を利用する場合、 その前に，［ 互いの端点が直列化を適切に取扱うことを確約するための折衝を仕組み ］を明示的に確立する必要がある。 ◎ For example, an alternative serialization of fields that takes advantage of Structured Fields would need to establish an explicit negotiation mechanism to assure that both peers would handle that serialization appropriately before using it.

`~securityの考慮点＠#security§も見よ。 ◎ See also the security considerations in Section 5.

1.2. 表記上の規約

この文書~内の~keyword "MUST" … 【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】 ◎ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.1. 但書き

互換性に関しては、 次に挙げる但書きにも注意： ◎ Note the following caveats regarding compatibility:

構文解析の相違点： ◎ Parsing differences:

一部の値は、 元々指定された構文に則って妥当であっても， `有構造~field$として構文解析することに失敗し得る。 例えば： ◎ Some values may fail to parse as Structured Fields, even though they are valid according to their originally specified syntax. For example,＼

• ~HTTPの~parameter名（ `parameter-name$p `HTTP$r ）は，文字大小無視であり、 `~sf辞書$に基づく多くの~field （例： `Cache-Control$h, `Expect-CT$h, `Pragma$h, `Prefer$h, `Preference-Applied$h, `Surrogate-Control$h ） でも，~keyは文字大小無視であるが、 `有構造~field$においては，すべて小文字にすることが要求される。 【`~sf~key$を見よ。】 ◎ HTTP parameter names are case-insensitive (per Section 5.6.6 of [HTTP]), but Structured Fields require them to be all-lowercase.＼ Likewise, many Dictionary-based fields (e.g., Cache-Control, Expect-CT, Pragma, Prefer, Preference-Applied, Surrogate-Control) have case-insensitive keys.＼
• ~HTTPの `parameters$p 規則（ `HTTP$r ）は，区切子 "`;^c" の前に空白を許容するが、 `有構造~field$においては，そうでない。 【`~sf~parameter群$を見よ。】 ◎ Similarly, the parameters rule in HTTP (see Section 5.6.6 of [HTTP]) allows whitespace before the ";" delimiter, but Structured Fields does not.＼
• ~HTTPの `quoted-string$p （ `HTTP$r ）は， ほとんどの文字に対し~backslashによる~escape法を許容するが、 `有構造~field$における文字列において~escapeできる文字は，［ "`\^c", `DQUOTE$P ］に限られる。 【`~sf文字列$を見よ。】 ◎ And, Section 5.6.4 of [HTTP] allows backslash-escaping most characters in quoted strings, whereas Structured Field Strings only escape "\" and DQUOTE.＼

典型的な流通にて見られる~fieldは、 これらの挙動【の相違】を呈さないものが大勢を占めている。 ◎ The vast majority of fields seen in typical traffic do not exhibit these behaviors.

~errorの取扱い ◎ Error handling:

現在の~HTTP~header用に指定された（または，単に広く実装された）構文解析~algoは、 ~errorの取扱いなど，詳細において`有構造~field$用のものと相違し得る。 例えば、 ~HTTPが［ `Cache-Control$h ~headerにて繰返された`~cache指令$ ］に対し指定する優先順位は，［ この~headerに対応付けられる，`~sf辞書$を値にとる有構造~field ］によりアテガわれるものとは異なる。 ◎ Parsing algorithms specified (or just widely implemented) for current HTTP headers may differ from those in Structured Fields in details such as error handling. For example, HTTP specifies that repeated directives in the Cache-Control header field have a different precedence than that assigned by a Dictionary structured field (which Cache-Control is mapped to).

`~sf~token$の制限 ◎ Token limitations:

`有構造~field$における~token（`~sf~token$）は，［ `ALPHA$P ／ "`*^c" ］から始まることが要求される一方で、 ~HTTPにおける~token（ `token$p ）は，より広い範囲の文字を許容する。 したがって、 対応付けられた値においては，前者以外の文字から始まる~tokenは利用できない。 例えば，［ `~MIME型$, `~field名$, `~method$, `範囲~単位$, 文字, `転送~符号法$ ］のうち［ `DIGIT$P ／ "`*^c" 以外の特殊~文字 ］から始まるものは、 ~HTTP~protocol要素としては妥当になり得るが， `~sf~token$としては表現-可能でない。 ◎ In Structured Fields, tokens are required to begin with an alphabetic character or "*", whereas HTTP tokens allow a wider range of characters. This prevents use of mapped values that begin with one of these characters. For example, media types, field names, methods, range-units, character and transfer codings that begin with a number or special character other than "*" might be valid HTTP protocol elements, but will not be able to be represented as Structured Field Tokens.

`~sf整数$の制限 ◎ Integer limitations:

`有構造~field$における整数（`~sf整数$）は、 15 桁までである — より大きい値は表現-可能でない。 ◎ Structured Fields Integers can have at most 15 digits; larger values will not be able to be represented in them.

~IPv6~literal ◎ IPv6 Literals:

~IPv6~literal~addressを値に包含する~field （ `CDN-Loop$h, `Host$h, `Origin$h など ） は、 `~sf~token$として表現-可能でない — それらを区切るために利用される角括弧は、 `~sf~token$においては許容されないので。 ◎ Fields whose values contain IPv6 literal addresses (such as CDN-Loop, Host, and Origin) are not able to be represented as Structured Fields Tokens, because the brackets used to delimit them are not allowed in Tokens.

空な`~field値$ ◎ Empty Field Values:

［ 空な／空白のみからなる ］`~field値$は、 `有構造~field$においては~errorと見なされる。 互換な~fieldにおいては、 これら空な~fieldは，当の~fieldを黙って無視するべきであることを指示する。 ◎ Empty and whitespace-only field values are considered errors in Structured Fields. For compatible fields, an empty field indicates that the field should be silently ignored.

`Alt-Svc$h ◎ Alt-Svc:

一部の~ALPN~token（例： `h3-Q43^c ）は、 `~sf~key$の構文に適合しないので，`~sf~token$として表現し得ない。 ~HTTP3の最終-~version【 ~RFC 9114 】は `h3^c ~tokenを利用するので、 これは，長期的な課題にはならないはずだが、 将来の~tokenは，この前提に再び違反し得る。 ◎ Some ALPN tokens (e.g., h3-Q43) do not conform to key's syntax, and therefore cannot be represented as a Token. Since the final version of HTTP/3 uses the h3 token, this shouldn't be a long-term issue, although future tokens may again violate this assumption.

`Content-Length$h ◎ Content-Length:

`Content-Length$h は、 `~sf~list$として定義されることに注意 — 実装が複数個の値を誤って送信することは珍しくないので。 その取扱い要件は、 `HTTP$r `Content-Length§h を見よ。 ◎ Note that Content-Length is defined as a List because it is not uncommon for implementations to mistakenly send multiple values. See Section 8.6 of [HTTP] for handling requirements.

`Retry-After$h ◎ Retry-After:

表現できる値は、 `delta-seconds$p に限られる — `HTTP-date$p【！http-date】 を包含している値は、 `有構造~field$用の値として伝達するためには， `delta-seconds$p に変換する必要がある。 ◎ Only the delta-seconds form of Retry-After can be represented; a Retry-After value containing a http-date will need to be converted into delta-seconds to be conveyed as a Structured Field Value.

3.1. ~URL

`表t 2＠#url-fields$ に挙げる`~field名$は、 その値を`~sf文字列$として扱うことにより， `有構造~field$用の値に対応付けれる。 ◎ The field names in Table 2 have values that can be mapped into Structured Field values by treating the original field's value as a String.

Location: https://example.com/foo

"https://example.com/foo"

3.2. 日時

`表t 3＠#date-fields$ に挙げる`~field名$ 【言い換えれば、 `HTTP-date$p を値にとる`単数~field$】 は、 その値を［ `HTTP$r `日時の形式＠~HTTPinfra#http.date§に則って構文解析した結果 ］を`~sf日時$として表現することにより，`有構造~field$用の値に対応付けれる。 ◎ The field names in Table 3 have values that can be mapped into Structured Field values by parsing their payload according to Section 5.6.7 of [HTTP] and representing the result as a Date.

@1659578233

3.3. `ETag^h

`ETag$h ~headerの値（ `entity-tag$p ）は、 次を伴う`~sf~item$で表現することにより， `有構造~field$用の値に対応付けれる： ◎ The field value of the ETag header field can be mapped into a Structured Field value by representing＼

• ~field値を成す `opaque-tag$p を`~sf文字列$として表現する （当の~itemの値を成す）。 ◎ the entity-tag as a String,＼
• ~field値を成す `weak$p の有無を`~sf真偽値$をとる "`w^c" ~parameterとして表現する （当の~itemの`~sf~parameter群$を成す）。 ここで、［ ~T は弱い`実体~tag$であること／ ~F また~parameterの不在は，強い`実体~tag$であること ］を指示する。 ◎ and the weakness flag as a Boolean "w" parameter on it, where true indicates that the entity-tag is weak; if 0 or unset, the entity-tag is strong.

ETag: W/"abcdef"

"abcdef"; w

同様に， `If-Match$h の`~field値$は、 同じ方式で`有構造~field$用の値に対応付けれる。 ◎ Likewise, If-Match's field value can be mapped into a Structured Field value in the same manner.

If-None-Match: W/"abcdef", "ghijkl", *

"abcdef"; w, "ghijkl", *

3.4. ~cookie

［ `Cookie$h ／ `Set-Cookie$h ］ `COOKIES$r ~fieldは、 それを成す~cookieたちが成す`~sf~list$で表現することにより，`有構造~field$用の値に対応付けれる。 ◎ The field values of the Cookie and Set-Cookie fields [COOKIES] can be mapped into Structured Fields Lists.

各~cookieは， 2 個の`~sf~item$ — ~cookie名と~cookie値 — を包含している`~sf内縁~list$として表現される。 ~cookie名は、 常に`~sf文字列$になる。 ~cookie値は、［ `~sf文字列$以外の`~sf裸~item$の~textな表現として成功裡に構文解析できるならば，それ （`~sf~byte列$／`~sf~decimal$／`~sf整数$／`~sf~token$／`~sf真偽値$）／ ~ELSE_ `~sf文字列$ ］になる。 ◎ In each case, a cookie is represented as an Inner List containing two Items; the cookie name and value. The cookie name is always a String; the cookie value is a String, unless it can be successfully parsed as the textual representation of another, bare Item structured type (e.g., Byte Sequence, Decimal, Integer, Token, or Boolean).

~cookie属性たちは、 各~parameterの名前を小文字に強制した上で， 当の`~sf内縁~list$の`~sf~parameter群$に対応付けられる。 ~cookie属性の値は、 当の属性~用に特有な型が定義される場合を除き，`~sf文字列$になる。 この仕様は、 `表t 4＠#cookie-params$ にて， 既存の~cookie属性~用の型を定義する。 ◎ Cookie attributes map to Parameters on the Inner List, with the parameter name being forced to lowercase. Cookie attribute values are Strings unless a specific type is defined for them. This specification defines types for existing cookie attributes in Table 4.

`Expires$a 属性は、 構文解析された `cookie-date＠~HTTPcookie#p.cookie-date$p （ `COOKIES$r `日付＠~HTTPcookie#cookie-date§ を見よ） を成す`~sf日時$による表現に対応付けられる。 ◎ The Expires attribute is mapped to a Date representation of parsed-cookie-date (see Section 5.1.1 of [COOKIES]).

Set-Cookie: Lang=en-US; Expires=Wed, 09 Jun 2021 10:18:14 GMT; samesite=Strict; secure

("Lang" "en-US"); expires=@1623233894; samesite=Strict; secure

Cookie: SID=31d4d96e407aad42; lang=en-US

("SID" "31d4d96e407aad42"), ("lang" "en-US")