メインコンテンツまでスキップ

2. Notational Conventions and Generic Grammar (表記規則と汎用文法)

2.1 Augmented BNF (拡張BNF)

本文書で指定されるすべてのメカニズムは、散文と拡張バッカス・ナウア記法 (Backus-Naur Form, BNF) の両方で記述されており、RFC 822 [9] で使用される形式に類似しています。実装者は、この仕様を理解するためにこの表記法に精通している必要があります。拡張BNFには以下の構成要素が含まれます。

name = definition 規則の名前は名前そのものであり(<> で囲まれていない)、等号 = 文字でその定義から区切られます。空白は、複数行にわたる規則定義を示すための継続行のインデントにおいてのみ意味を持ちます。いくつかの基本規則は大文字で表されます(例:SP、LWS、HT、CRLF、DIGIT、ALPHAなど)。山括弧の存在が規則名の使用を区別するのに役立つ場合は、定義内で山括弧が使用されます。

"literal" 引用符で囲まれたテキストはリテラルテキストです。特に明記されていない限り、テキストは大文字小文字を区別しません。

rule1 | rule2 縦線 ("|") で区切られた要素は代替です。例えば、"yes | no" は yes または no を受け入れます。

(rule1 rule2) 括弧内の要素は単一の要素として扱われます。したがって、"(elem (foo | bar) elem)" は、トークン列 "elem foo elem" と "elem bar elem" を許可します。

*rule 要素の前にある文字 "*" は繰り返しを示します。完全な形式は "<n>*<m>element" であり、少なくとも <n> 回、最大 <m> 回の要素の出現を示します。デフォルト値は 0 と無限大であるため、"*(element)" は 0 を含む任意の数を許可します。"1*element" は少なくとも 1 つを必要とします。"1*2element" は 1 つまたは 2 つを許可します。

[rule] 角括弧はオプション要素を囲みます。"[foo bar]" は "*1(foo bar)" と等価です。

N rule 特定の繰り返し:"<n>(element)" は "<n>*<n>(element)" と等価です。つまり、(element) のちょうど <n> 回の出現です。したがって、2DIGIT は 2 桁の数字であり、3ALPHA は 3 つの英字からなる文字列です。

#rule 要素のリストを定義するために、"*" に類似した構成要素 "#" が定義されています。完全な形式は "<n>#<m>element" であり、少なくとも <n> 個、最大 <m> 個の要素を示し、各要素は 1 つ以上のカンマ (",") とオプションの線形空白 (Linear White Space, LWS) で区切られます。これにより、リストの通常の形式が非常に簡単になります。次のような規則:

( *LWS element *( *LWS "," *LWS element ))

は次のように表示できます:

1#element

この構成要素が使用される場所では、空の要素が許可されますが、存在する要素の数にはカウントされません。つまり、"(element), , (element)" は許可されますが、2 つの要素としてのみカウントされます。したがって、少なくとも 1 つの要素が必要な場合、少なくとも 1 つの非空要素が存在しなければなりません (MUST)。デフォルト値は 0 と無限大であるため、"#element" は 0 を含む任意の数を許可します。"1#element" は少なくとも 1 つを必要とします。"1#2element" は 1 つまたは 2 つを許可します。

; comment セミコロンは、行のどこにあっても、その行の終わりまで続くコメントを開始します。これは、仕様に含めるための簡単な方法であり、拡張BNFの正式な部分ではありません。

implied *LWS 特に明記されていない限り、文法内の線形空白 (LWS) は、任意の 2 つの隣接するトークン(token、区切り文字)の間に含めることができます。また、いくつかの規則(例:"*"、"|"、"#")の区切り文字の間にも含めることができます。この暗黙の *LWS 規則は、HTTP 構成要素内に余分な空白を生成すべきではありません。多くの実装は、メッセージを迅速に解析できるように、空白をリクエスト行と汎用ヘッダーフィールドの区切り文字として使用するためです。

2.2 Basic Rules (基本規則)

以下の規則は、基本的な解析構成要素を記述するために仕様全体で使用されます。US-ASCII 文字セットは ANSI X3.4-1986 [21] によって定義されています。

OCTET          = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>

HTTP/1.1 は、プロトコル要素の基本的な解析単位としてオクテットシーケンスを定義します。プロトコルパラメータの構文規則は、セクション 2.1 で説明されているように ABNF の形式で与えられ、以下のコアルールを使用します。

CRLF           = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs,
but including LWS>

LWS 規則は線形空白 (Linear White Space) を定義します。これは、フィールドコンテンツと区切り文字の間に現れる可能性があります。これは、フィールドセマンティクスを壊すことなく複数行にわたって折り畳むために使用されます。すべての HTTP/1.1 ヘッダーフィールド値は、任意の LWS の前に少なくとも 1 つの SP または HT を配置することで、複数行に折り畳むことができます。

多くの HTTP/1.1 ヘッダーフィールド値は、単語(tokens)、区切り文字、および引用符付き文字列で構成されます。これらの要素は SP または HT 文字で区切られます。

token          = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT

コメントは、一部の HTTP ヘッダーフィールドに含めることができます。コメント内で許可されるテキストは comment 規則によって定義されます。

comment        = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">

引用符付き文字列 (quoted-string) は単一の単語として扱われます。引用符付き文字列内で許可されるテキストは qdtext 規則によって定義されます。

quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>

単一文字の引用メカニズムにより、引用符付き文字列とコメント構成要素内に任意の CHAR を含めることができます。

quoted-pair    = "\" CHAR