[26] HTTP および関連仕様は、いくつかの ABNF の派生版を使っています。
[1] RFC 1945 (HTTP/1.0), RFC 2068 / RFC 2616 (HTTP/1.1) で使われている ABNF です。
RFC 822のABNF を元にしていますが、選択 (or) は "/" ではなく "|" を使います。
or
"/"
"|"
[36] また、リストを表す # 記法が定義されています。
#
[2] RFC 1945, RFC 2068, RFC 2616 2.1節で規定されています。
[4] HTTP RFC では、 *LWS の挿入可能箇所を構文では明記せずに、 本文で説明しています。
*LWS
[14] 右辺が < 自然言語文 > のような形で定義されることがあります。 (がそのことは ABNF の定義に明記はされていません。)
< 自然言語文 >
[34] いくつかの HTTP 系の RFC などがこの ABNF を参照しています。
[35] RFC 2616 の改訂版である RFC 7230 は、この ABNF を引き継がず、 IETF の ABNF (RFC 822 から派生したもの) をベースにしています (後述)。
[37] RFC 1738 は、 RFC 822 の ABNF のバリエーションとして、[38] 選択は / ではなく |[39] グループ化は ( ... ) ではなく [ ... ] ... としたものを使っていました。
/
|
( ... )
[ ... ]
*
[41] RFC 2056 は RFC 1738 と同じもの >>40 を採用していました。
[13] RFC 3875 (CGI/1.1) は「RFC 822 のものと似た ABNF」を定義しています。 実態としては HTTP の ABNF と同じものです。
[15] ただし # や ; は定義されておらず使ってもいません。
;
[16] また LWS の挿入に関しては言及がありません (が実際には HTTP 同様特定の箇所で認められています)。
[19] CGI では ABNF は特定のビット列、バイト列を定義するものではなく、 文字列を表しており、その具体的な表現はシステム定義または文脈依存であるとされています >>12 2.2.。
[20] CGI の仕様では空文字列を明示するために "" と記述していることがよくあります。
""
[21] 明確に説明されていませんが、反復回数を変数のように表現することがあります。
[22] 例えば
request-body = <CONTENT_LENGTH>OCTET
OCTET
CONTENT_LENGTH
[23] 一部の構造では、 ABNF 上で順序が定義されていても、実際には任意の順序で構わないと定義されています。
[24] Digest認証を規定する RFC 2068 は、 HTTPのABNF を使うと述べていますが、 実際には FOO(...) のような関数の表記を使っています。これは1個以上の引数に対して関数を適用した結果が生成規則の項として使われることを表しています。
[3] RFC 2295 (3.) は HTTPのABNFに更に追加の記法 % >>5 を定義しています。
%
1%rule
rule *(FWS rule)
[25] RFC 3229 は RFC 2616 の ABNF を使っているようですが (明記はされていません)、 既存の定義に更に新たな定義を付け加えることを表すために「...」を使っています。
...
[10] RFC 5023 は Slug: 頭欄の定義に RFC 2616のABNF を使っているとしています。
Slug:
[11] しかし、実際には RFC 4234のABNF にある %20-7E という表現が混在しています。
%20-7E
[27] HTTP/1.1 の第3次仕様である RFC 7230 他では、 RFC 5234 を拡張した ABNF を用いています。
[32] RFC 2616 以前と同様なリスト記法 (#) が定義されています。
[30] RFC 2822 と同様に、 obs-* という生成規則が廃止された構文を表す >>28 ことになっています。
obs-*
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [7] [9] . Implementors Implementers Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
この文書で規定するすべての機構は、文章および RFC 822 で使われているものに似た増補 Backus・Naur 式 (BNF) で記述します。実装者は、この視湯所を理解するためにこの記法に精通する必要があります。 増補 BNF には、次の構造が含まれます。
name = definition The name of a rule is simply the name itself (without any enclosing "<" and ">") and is separated from its definition by the equal character "=" "=" character. White space {2616} is only significant in that indentation of continuation lines is used to indicate a rule definition that spans more than one line. Certain basic rules are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions whenever their presence will facilitate discerning the use of rule names.
規則の名前は、単に名前自体 (< や > で囲まない。) であり、 その定義とは = 文字で分離します。 空白は、規則定義が複数行にまたがっていることを示すための、 継続行標識として使われるときのみ意味を持ちます。 幾つかの基本規則は、 SP, LWS, HT, CRLF, DIGIT, ALPHA などのように大文字です。 角括弧は、定義中で規則名を使っていることをわかりやすくできるのであれば使用します。
<
>
=
SP
LWS
HT
CRLF
DIGIT
ALPHA
"literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
引用符は表記文を囲みます。特に言及されていない限り、 文は大文字・小文字を区別しません。
rule1 | rule2 Elements separated by a bar ("I""|") are alternatives, e.g., "yes | no" will accept yes or no.
棒線 (|) で分離した要素群は、代替選択肢で、 例えば yes | no は yes または no を受け入れます。
(rule1 rule2) Elements enclosed in parentheses are treated as a single element. Thus, "(elem (foo | bar) elem)" allows the token sequences "elem foo elem" and "elem bar elem".
括弧で囲まれた要素群は、単一の要素として扱います。 従って、 (elem (foo | bar) elem) は字句列 elem foo elem および elem bar elem を認めます。
*rule The character "*" preceding an element indicates repetition. The full form is "<n>*<m>element" indicating at least <n> and at most <m> occurrences of element. Default values are 0 and infinity so that "*(element)" allows any number, including zero; "1*element" requires at least one; and "1*2element" allows one or two.
要素の前の文字 * は、反復を示します。 完全形は <n>*<m>element で、 最低 <n> 個、最高 <m> 個の element が現れることを示しています。既定値は 0 と∞ですから、 *(element) は零個を含む任意個を認めます。 1*element は最低1つ必要です。 1*2element は1つか2つ認めます。
<n>*<m>element
0
[rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
四角括弧は任意選択要素を囲みます。 [foo bar] は *1(foo bar) と同等です。
N rule Specific repetition: "<n>(element)" is equivalent to "<n>*<n>(element)"; that is, exactly <n> occurrences of (element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three alphabetic characters.
特定反復: <n>(element) は <n>*<n>(element) と同等です。 つまり、丁度 <n> 回の element の出現です。 従って、 2DIGIT は2桁の数字で、 3ALPHA は3文字の英数字の文字列です。
<n>(element)
<n>*<n>(element)
#rule A construct "#" is defined, similar to "*", for defining lists of elements. The full form is "<n>#<m>element " indicating at least <n> and at most <m> elements, each separated by one or more commas (",") and optional {2616} OPTIONAL linear white space {2616} (LWS). This makes the usual form of lists very easy; a rule such as "( *LWS element *( *LWS "," *LWS element )) " can be shown as "1#element" {削除部 = 1945,2068}. Wherever this construct is used, null elements are allowed, but do not contribute to the count of elements present. That is, "(element), , (element)" is permitted, but counts as only two elements. Therefore, where at least one element is required, at least one non-null element must {2616} MUST be present. Default values are 0 and infinity so that {1945} "#(element)" "#element" allows any number, including zero; "1#element" requires at least one; and "1#2element" allows one or two.
構造 # は、要素の並びを定義するために、 * と同様に定義します。完全形は <n>#<m>element で、最低 <n> 個、最高 <m> 個の element であり、それぞれは一つ以上の読点 (,) と任意選択で線形空白 (LWS) で分離します。これは並びの通常形を非常に容易とします。 ( *LWS element *( *LWS "," *LWS element )) のような規則は 1#element と示すことができます。 個の構造が使われているときはいつでも空の要素が認められますが、出現要素の数に入れません。つまり、 (element), , (element) は認められますが、 2つだけの要素と数えます。従って、最低一つの要素が必要なところでは、最低一つの空でない要素が現れなければなりません。既定値は 0 と無限大ですので、 #element は零個を含む任意個を認めます。 1#element は最低一個必要です。 1#2element は1個か2個認めます。
<n>#<m>element
,
; comment A semi-colon, set off some distance to the right of rule text, starts a comment that continues to the end of line. This is a simple way of including useful notes in parallel with the specifications.
セミコロンは、規則文の右端と少し離して、注釈のはじめとします。 注釈は行の終わりまで続きます。これは、仕様書と並行に有用な注記を含める簡単な方法です。
implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space {2616} (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent tokens and delimiters (tspecials) {2616} words and separators, without changing the interpretation of a field. At least one delimiter (tspecials {2616} LWS and/or separators) must {2616} MUST exist between any two tokens {2616} (for the definition of "token" below), since they would otherwise be interpreted as a single token. However, applications should attempt to follow "common form" when generating HTTP constructs, since there exist some implementations that fail to accept anything beyond the common forms.
token
quoted-string
注意 : 注記のない修正箇所は、 RFC 1945 → RFC 2068 での変更点です。
→HTTP//メッセージ
[18]
element
char-val
repeat "(" char-val ")"
<">
"<" / ">"
rule-name
chunk-data = chunk-size(OCTET)
[29] RFC 2616 の改訂版である RFC 7230 その他では、従来の独自 ABNF にかわって、 RFC 5234 を採用しています。ただしリストを表す # 記法は引き続き独自に定義しています。
Some names of the rules correspond to names of the correspondingheader fields. Such rules express values of the corresponding headerfields, for example, the Sec-WebSocket-Key ABNF rule describes syntaxof the |Sec-WebSocket-Key| header field value. ABNF rules with the"-Client" suffix in the name are only used in requests sent by theclient to the server; ABNF rules with the "-Server" suffix in thename are only used in responses sent by the server to the client.
Some names of the rules correspond to names of the corresponding
header fields. Such rules express values of the corresponding header
fields, for example, the Sec-WebSocket-Key ABNF rule describes syntax
of the |Sec-WebSocket-Key| header field value. ABNF rules with the
"-Client" suffix in the name are only used in requests sent by the
client to the server; ABNF rules with the "-Server" suffix in the
name are only used in responses sent by the server to the client.
[42] BNF Notation for syntax (1995-02-02 05:07:04 +09:00) https://www.w3.org/Notation.html
[43] Clarify the ABNF flavor in use (annevk著, 2017-02-14 23:34:56 +09:00) https://github.com/whatwg/fetch/commit/406f86052d37f9318efe4a3c6844d04ea38d5ae3
[44] Add some infrastructure notes. (@annevk著, 2017-03-08 17:52:36 +09:00) https://github.com/w3c/webappsec-csp/commit/40d2e607855b91f91cfb0f1a183be1b3ce209553
[45] Relax ABNF for invalid policy tokens (#102) (@annevk著, 2017-03-28 20:31:35 +09:00) https://github.com/w3c/webappsec-referrer-policy/commit/380d752a0194aaa95be1784c3cf27e4a54233822
[46] Merge pull request #109 from w3c/abnf (plehegar著, 2017-04-19 06:31:44 +09:00) https://github.com/w3c/resource-timing/commit/e73e3677bd9b5a66fbd8c82a10dd681eded76ef3
[47] Feedback from @reschke. (@reschke著, 2017-06-29 20:47:29 +09:00) https://github.com/w3c/webappsec-clear-site-data/commit/9f20dcc7580e241636c4787b6cf852a7e6258d63
[48] address w3ctag review feedback (#31) (cvazac著, 2017-09-02 10:22:54 +09:00) https://github.com/w3c/server-timing/commit/7e195cdb533ffb23307278163a9c50b279e71868
*
は RFC 822 と同義です。)