%

HTTP の ABNF

[26] HTTP および関連仕様は、いくつかの ABNF の派生版を使っています。

RFC 1945, RFC 2068, RFC 2616 の ABNF

[1] RFC 1945 (HTTP/1.0), RFC 2068 / RFC 2616 (HTTP/1.1) で使われている ABNF です。

RFC 822のABNF を元にしていますが、選択 (or) は "/" ではなく "|" を使います。

[36] また、リストを表す # 記法が定義されています。

[2] RFC 1945, RFC 2068, RFC 2616 2.1節で規定されています。

[4] HTTP RFC では、 *LWS の挿入可能箇所を構文では明記せずに、 本文で説明しています。

[14] 右辺が < 自然言語文 > のような形で定義されることがあります。 (がそのことは ABNF の定義に明記はされていません。)

[34] いくつかの HTTP 系の RFC などがこの ABNF を参照しています。

[35] RFC 2616 の改訂版である RFC 7230 は、この ABNF を引き継がず、 IETFABNF (RFC 822 から派生したもの) をベースにしています (後述)。

RFC 1738 の ABNF

[37] RFC 1738 は、 RFC 822ABNF のバリエーションとして、

... としたものを使っていました。

単なる [ ... ] は RFC 822 と同じく省略を表します。 *[ ... ] は0個以上を表します。 1*[ ... ] は1個以上を表します。 (*RFC 822 と同義です。)

[41] RFC 2056RFC 1738 と同じもの >>40 を採用していました。

CGI の ABNF

[13] RFC 3875 (CGI/1.1) は「RFC 822 のものと似た ABNF」を定義しています。 実態としては HTTPABNF と同じものです。

[15] ただし #; は定義されておらず使ってもいません。

[16] また LWS の挿入に関しては言及がありません (が実際には HTTP 同様特定の箇所で認められています)。

[19] CGI では ABNF は特定のビット列バイト列を定義するものではなく、 文字列を表しており、その具体的な表現はシステム定義または文脈依存であるとされています >>12 2.2.

[20] CGI の仕様では空文字列を明示するために "" と記述していることがよくあります。

[21] 明確に説明されていませんが、反復回数を変数のように表現することがあります。

[22] 例えば

      request-body   = <CONTENT_LENGTH>OCTET
... は、 OCTET の長さが CONTENT_LENGTH であることを表します。

[23] 一部の構造では、 ABNF 上で順序が定義されていても、実際には任意の順序で構わないと定義されています。

RFC 2069 の ABNF

[24] Digest認証を規定する RFC 2068 は、 HTTPのABNF を使うと述べていますが、 実際には FOO(...) のような関数の表記を使っています。これは1個以上の引数に対して関数を適用した結果が生成規則として使われることを表しています。

RFC 2295 の ABNF

[3] RFC 2295 (3.) は HTTPのABNFに更に追加の記法 % >>5 を定義しています。

RFC 3229 の ABNF

[25] RFC 3229RFC 2616ABNF を使っているようですが (明記はされていません)、 既存の定義に更に新たな定義を付け加えることを表すために「...」を使っています。

AtomPub の ABNF

[10] RFC 5023Slug: 頭欄の定義に RFC 2616のABNF を使っているとしています。

[11] しかし、実際には RFC 4234のABNF にある %20-7E という表現が混在しています。

| を使っているので、 RFC 4234のABNF ではありません。

RFC 7230 の ABNF

[27] HTTP/1.1 の第3次仕様である RFC 7230 他では、 RFC 5234 を拡張した ABNF を用いています。

[32] RFC 2616 以前と同様なリスト記法 (#) が定義されています。

[33] 詳しくはリスト (HTTP)の項を参照してください。

[30] RFC 2822 と同様に、 obs-* という生成規則廃止された構文を表す >>28 ことになっています。

歴史

RFC 1945 (HTTP/1.0) 2.; RFC 2068・2616 (HTTP/1.1) 2 Notational Conventions and Generic Grammar

2.1 Augmented BNF

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 などのように大文字です。 角括弧は、定義中で規則名を使っていることをわかりやすくできるのであれば使用します。

"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 | noyes または 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つ認めます。

[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文字の英数字の文字列です。

#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個認めます。

; 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.
暗黙の *LWS
個の仕様書で記述する文法は語を基にしたものです。 別途注記の無い限り、線形空白 (LWS) を二つの隣接する語 (tokenquoted-string) の間ならびに隣接する語と分離子の間に欄の解釈を変えてしまうことなく入れることができます。 二つの字句の間には、最低一つの区切子 (LWS 及び/又は分離子) がなければなりません。そうでないと、一つの字句として解釈されてしまいます。しかしながら、応用は HTTP 構造を生成する時には「共通形」に従うように試みるべきです。共通形以外のものを受け入れてくれない実装もあります。

注意 : 注記のない修正箇所は、 RFC 1945 → RFC 2068 での変更点です。

2.2 Basic Rules

HTTP//メッセージ

[18]

  • rule = rule-name defined-as elements [CFWS] ;; name = definition
  • defined-as = [CFWS] "=" [CFWS]
  • rule-name = ALPHA *(ALPHA / DIGIT / "-") ;; 名前文字の規定なし。
  • elements = alternation
  • alternation = concatenation *([CFWS] "|" [CFWS] concatenation) ;; rule1 | rule2
  • concatenation = repetition *([CFWS] repetition)
  • repetition = [repeat] element
  • element = rule-name / group / option / char-val / prose-val / csv
  • repeat = number / [number] "*" [number] ;; *rule / N rule
  • group = "(" alternation ")" ;; (rule1 rule2)
  • option = "[" alternation "]" ;; [rule]
  • char-val = <"> 1*(CHAR - <">) <"> ;; "literal"
  • prose-val = "<" 1*(CHAR / FWS) ">" ;; <"> 又は自由文。
    • ;; "<" / ">" が文中に入ることもある。
  • csv = ( [number] "#" [number] ) element ;; #rule
    • ;; 1#element == ([FWS] [element] *([FWS] "," [FWS] [element]))
    • ;; ただし element は最低1つ必要。
  • number = 1*DIGIT / rule-name
  • CFWS = FWS *([comment] FWS)
  • comment = ";" 1*CHAR CRLF 1*WSP ;; ; comment

RFC 7230

[29] RFC 2616 の改訂版である RFC 7230 その他では、従来の独自 ABNF にかわって、 RFC 5234 を採用しています。ただしリストを表す # 記法は引き続き独自に定義しています。

[6] RFC 6455 - The WebSocket Protocol ( 版) <http://tools.ietf.org/html/rfc6455#section-4.3>

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 () <https://www.w3.org/Notation.html>

[43] Clarify the ABNF flavor in use (annevk著, ) <https://github.com/whatwg/fetch/commit/406f86052d37f9318efe4a3c6844d04ea38d5ae3>

[44] Add some infrastructure notes. (@annevk著, ) <https://github.com/w3c/webappsec-csp/commit/40d2e607855b91f91cfb0f1a183be1b3ce209553>

[45] Relax ABNF for invalid policy tokens (#102) (@annevk著, ) <https://github.com/w3c/webappsec-referrer-policy/commit/380d752a0194aaa95be1784c3cf27e4a54233822>

[46] Merge pull request #109 from w3c/abnf (plehegar著, ) <https://github.com/w3c/resource-timing/commit/e73e3677bd9b5a66fbd8c82a10dd681eded76ef3>

[47] Feedback from @reschke. (@reschke著, ) <https://github.com/w3c/webappsec-clear-site-data/commit/9f20dcc7580e241636c4787b6cf852a7e6258d63>

[48] address w3ctag review feedback (#31) (cvazac著, ) <https://github.com/w3c/server-timing/commit/7e195cdb533ffb23307278163a9c50b279e71868>