[27] メッセージは、 HTTP における情報伝達の単位 (アプリケーション層のパケット) です。
[28] メッセージには、要求メッセージと応答メッセージがあります。
[65] HTTP/1.0 と HTTP/1.1 は、 RFC 822 に由来するテキスト形式のメッセージ構文を採用していました。 HTTP/0.9 はそれよりも更に単純な形式でした。
[29] メッセージは、開始行、ヘッダー、メッセージ本体の3つの部分で構成されます >>30。
[46] HTTP/0.9 応答以外のすべてのHTTPメッセージには、 開始行が存在します。
[31] ヘッダーは、任意の個数使用することができ、必ず直後に CRLF が来ます。 >>30 ただし HTTP/0.9 ではヘッダーを使うことができません。
[32] 開始行およびヘッダーとメッセージ本体の間には、必ず1つ CRLF が来ます。 >>30 最後のヘッダーの後の CRLF (ヘッダーが無い場合は開始行の最後の CRLF) とあわせて、 CRLF CRLF と2回連続することになります。 なお HTTP/0.9 ではこの CRLF は存在しません。
[34] メッセージ本体は省略することもできます >>30。 HTTP/0.9 要求ではメッセージ本体を使えません。
[36] HTTP/1.x では、メッセージ本体がなくても、区切りの CRLF は必要です。
[42] HTTPメッセージはストリームとして構文解析して漸進的処理に供したり、 下流へ転送したりできます。しかし、実装によっては転送するメッセージをバッファリングしたり遅延させたりして調整したり何らかの処理を行ったりすることがありますから、 受信者は、メッセージを漸進的に受信できることに依存できません。 >>30
[41] 受信者は、HTTPメッセージを US-ASCII の超集合のオクテット列として構文解析しなければなりません。 >>30
[37] 通常は HTTPメッセージを次のように構文解析します >>30。
[513] 鯖は、少なくても1つは要求行の前の CRLF を無視するべきです >>514。
[44] 送信者は開始行と最初のヘッダーの間に空白を送信してはなりません >>30。受信者は、開始行とヘッダーの間に空白があれば、 メッセージを非妥当であるとして拒絶するか、 空白で始まる行を消費して無視するかのいずれかとしなければなりません >>30。
[516] HTTP 要求メッセージのみを受け付ける鯖は、
HTTPメッセージの文法に沿わないオクテット列を受け取った場合、
(他に規定がなければ) 400 応答を送るべきです >>514。
[55] Apache はヘッダー部にヘッダーでないもの (:
が含まれない行) が混じっていると 400
を返します。 nginx は無視するようです。
[53] メッセージは、不完全なことがあります。 詳しくは不完全メッセージを参照してください。
[59] HTTP/1.0 要求に対して HTTP/0.9 応答が返された場合、
payload body の先頭が状態行のような文字列の時、
HTTP/1.0 応答と誤認されることとなります。しかし HTTP/0.9
鯖のほとんどは text/html なので、
そのようなことはあまりないとされています >>58。
[93] ヘッダー部が不完全な場合 (状態行の途中で終わっていた場合、 ヘッダーの後に改行がない場合、 ヘッダーの後の空行がない場合) には、接続が閉じられたところまでについて通常通り処理が行われるようです。 ただし、 Firefox は状態行の改行がなく終わっている時は、ネットワークエラーとみなします (IE と Chrome はエラーにしません)。 ヘッダーが改行で終わっていないと、 Firefox はネットワークエラーとみなし、 IE はその前の行までだけ処理します (Chrome はそのヘッダーまで含めて処理します)。
[95] HTTPS の場合、 Chrome はヘッダー部の途中で接続が閉じられるとネットワークエラーにします。 Firefox と IE は HTTP と同じくエラーにはしません。
[105] Chrome も Firefox も、ヘッダー部の途中での RST
はネットワークエラーとします。
[106] Apache は要求本体が Content-Length: に満たずに要求が閉じられると、
400 応答を返します。 nginx は通常通り処理を続けます。
[107] nginx は継続行の処理がおかしく、ネットワークからのデータの到着のタイミングによっても結果が変わったりするようです。
[108] (標準設定では) Apache も nginx も、ヘッダー部の各行は改行を含めて
8192 バイト以下でなければ 400 応答を返します。
Apache は継続行を連結して、ヘッダー名、:、ヘッダー値、改行で
8192 バイト以下でなければ 400 応答を返します。
nginx は継続行を含めた検査を行わないように見えます。
[109] Apache は要求ヘッダーを 100 個まで受け付け、それを超えると
400 応答を返します。 nginx は 8438 個まで受け付け、それを超えると
400 応答を返します。
[33] HTTPメッセージのうち、メッセージ本体よりも前の部分で区切りに使われる改行は、 CRLF です。 CR 単体や LF 単体ではありません。
[515] 開始行やヘッダーの後の改行である CRLF について、 LF を改行とみなし、直前に CR があれば無視することとしても構いません >>514。
[92] nginx も Apache も、LF を改行とみなし、直前の CR を無視するようです。
Server: Fujitsu-InfoProvider-Pro/V12L10 (UXP/DS) というサーバーは LF で出力します。 Mozilla や WinIE を含めた多くの UA はこれでも扱えるようですが、問題が出ることもあるみたいです。[4] W3C の古い記述 (Note: Client tolerance of bad HTTP servers http://www.w3.org/Protocols/HTTP/OldServers.html) は、クライアントは改行を LF と考えて、その前の CR を無視しなさい、と言っています。
まあ [HTTP92] でも改行は CRLF と規定しているのですが...
[5] >>4 もっと昔の TimBL が (たぶん) 最初に書いた仕様書には LF で、 CR を無視と書いてありましたです。
[6] もっとも、 >>5 は今で言う HTTP/0.9 の話なので、影響するのは要求の最初の行の末だけです。
[94] herokuapp.com のサーバー (Cowboy?) は LF のみの要求を正しく扱えず、
505 応答を返します。
[67] メッセージは、同一ストリーム中のフレームの列として表されます。
[68] HTTPメッセージは、次のもので構成されます >>66。
HEADERS
フレームのかわりに PUSH_PROMISE フレームを使います。
PUSH_PROMISE フレームとそれに続く CONTINUATION
フレームは、親ストリームで送信されます。[83] HEADERS フレームと CONTINUATION
フレームの間や CONTINUATION フレーム間に、
他のフレームがあってはなりません >>66。
[81] 最後の HEADERS か DATA のフレームは、
END_STREAM フラグが設定されます >>66。
[88] DATA フレームが存在しない場合、
ヘッダーリストが2つ連続することになります。
[99] 1xx ヘッダーの後 DATA
を受信したらどうするべきかは定かではありません。
[100] Chrome は 200 として扱うようです。 (逆に仕様通り
1xx ヘッダーの後に次の HEADERS
が現れるとストリームエラー PROTOCOL_ERROR とします。)
Firefox は DATA フレームを受信したら接続を閉じます。
[90] payload body を持たない種別のメッセージで DATA
フレームが存在する場合や、 payload body を持つ種別のメッセージで
DATA フレームが存在しない場合にどうなるのかは謎です。
Content-Length の項も参照。[101] Chrome も Firefox も、長さ0の DATA はエラーとはしません。
Chrome は長さが非0でもエラーにせず、 XHR からアクセスできます。
Firefox は長さが非0だとストリームエラー CANCEL
とします。
[103] Chrome は trailer に対応していないようで、
ストリームエラー PROTOCOL_ERROR とします。
[84] trailer の header block に END_STREAM
が設定されてストリームが閉じられなかったとしても、
その後の header block は本メッセージの一部ではありません >>66。
[85] 最終的な状態符号を受信した後に END_STREAM
が設定されていない HEADERS フレームを受信したら、
そのメッセージは奇形として扱わなければなりません >>66。
[102] Firefox はその場合接続エラー PROTOCOL_ERROR
とするようです。
[104] Chrome も Firefox も、 END_STREAM より前に
GOAWAY を受信しても、エラーとはしないで接続を閉じる
(Firefox は NO_ERROR の GOAWAY を送信して閉じる)
ようです。要求に対する応答はネットワークエラーとします。
[98] クライアントが要求を送信していないストリームでサーバーから
HEADERS を受信した時どうしたらいいのかは定かではありません。
[96] 要求を送信していないストリームで HEADERS
を受信した時、 Chrome も Firefox も接続エラー PROTOCOL_ERROR
とし、送信中の要求についてはネットワークエラーとするようです。
[2053] メッセージには要求メッセージと応答メッセージがあり、 それぞれ定義されている文脈で用いられます。 (それぞれの項とHTTP接続の項を参照してください。)
[16] 送信者は、 ABNF 生成規則により定義される文法に一致しないプロトコル要素を生成してはなりません >>13。
obs- から始まるものがありますが、
RFC 5322 とは違って obs- から始まるとしてもただちに不適合になるわけではないようです。
個別に不適合と規定されているものもあれば、何も言及がないものもあります。[17] 送信者は、送信者の役割に応じて、その役割の送信者が用いることを認められていないプロトコル要素や構文上の選択肢を用いてはなりません >>13。
[15] 送信者は、偽であるとわかっていることを表しているプロトコル要素を生成してはなりません >>13。
[18] 受信者は、その役割に適用され、 ABNF 生成規則により定義される文法に一致するような値を構文解析することができなければなりません >>13。
[19] すべての受信者がすべてのプロトコル要素の構文解析を義務付けられているわけではありません。 串などメッセージを転送する中間器は、ヘッダー一般の構文解析を行って名前と値の組として認識はするでしょうが、 個々の値まで更に構文解析はしないで転送してしまいます。
[23] 受信者は、受信したプロトコル要素を適当な仕様書に従い解釈しなければなりません。 >>13
[24] ただし受信者が (経験や設定により) 送信者が誤って実装していると判定できるときは、 この限りではありません。 >>13
[25] 例えば、ある実装が特定の内容符号化の実装を誤っているとわかっており、
User-Agent: から受信者がその実装であると推測できるときは、
Accept-Encoding: を無視することができます。 >>13
[26] HTTPのエラー処理も参照してください。
[20] ほとんどのプロトコル要素には特定の長さの制限は設けられていません。 これは、利用される文脈や実装の目的により適切な長さが様々であるためとされています。 >>13
[21] 受信者は少なくても自身が同じプロトコル要素で生成し得る値と同じ長さは構文解析して処理できなければなりません >>13。
[519] テキスト形式のHTTPメッセージに完全に対応するMIME型はありませんが、 近い型は2つあります。
[520] application/http は、要求メッセージの列、
または応答メッセージの列を表します。
application/http を参照してください。[521] message/http は、
HTTPメッセージ1つを表すMIME型ですが、 MIME
の message/* の制限が課される他、
いくつかの要件が本来のHTTPメッセージと異なっています。
[529] message/http には省略可能な引数が2つ定義されています >>517。
[526] message/http の CTE としては、 7bit, 8bit,
binary だけが認められます >>517。
[51] message/http をどのように処理するべきかは規定されていません。
唯一使われる場面が TRACE 要求に対する応答ですが、
このメソッドもデバッグ用だからか特に処理は規定されていません。
[524] message/http のHTTPメッセージは、
行長に関する MIME の制限に従う必要があります >>517。
[530] message/http のHTTPメッセージに関しては、
折り畳みの禁止に関する制約が緩和されます。詳しくは行折り畳みを参照してください。
message/http による利用を定義しているのか謎です。。。
電子メールでの転送を想定しているのかもしれませんが、唯一の用法である
TRACE は電子メールではありません。[522] HTTPメッセージと RFC 822 メッセージの類似性から、必然的に
message/http と message/rfc822
はよく似ています。
[523] 一般に HTTP メッセージの CTE
は binary です。7bit や
8bit の旧来の SMTP や NNTP
の如き転送路では転送することができません。他のMIME型であれば
Base64 や Quoted-Printable のような CTE で符号化するべきところですが、
MIME の規定により、 message/*
の符号化は一切禁止されているので、仕様に従いつつ転送する術はありません。
message/http の代わりに application/http
として札付けすることでこの制約を回避できます。
- message
- The basic unit of HTTP communication, consisting of a structured sequence of octets matching the syntax defined in
{1945] Sectionsection 4 and transmitted via the connection.
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への応答 から構成されます。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-ResponseFull-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).
Full-Request と Full-Response は実体の転送に RFC 822 の一般メッセージ形式を使います。両メッセージは省略可能な頭欄 (「頭達」とも呼ばれる) と実体本文を含んでも構いません。 実体本文は頭達と空行 (つまり CRLF の前に何も無い行) で区切ります。
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2 Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET).
Simple-Request と Simple-Response はいかなる頭情報の使用も 認められませんし、単一要求方式 (GET) に制限されます。
Simple-Request = "GET" SP Request-URI CRLF
Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity.
Simple-Request 形式の使用は非推奨です。 この形式では返される実体の媒体型を識別できないからです。
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは顧客からサーバーへの要求とサーバーから顧客への 応答で構成されます。
HTTP-message = Request | Response ; HTTP/1.1 messages
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and possibly a message-body.
Request, Response 両メッセージは実体 (メッセージの弾頭) の転送に RFC 822 の一般メッセージ形式を使います。両メッセージ型は star-line, 0個以上の頭欄 (「頭達」とも呼ばれる), 頭欄の終わりを示す空行 (つまり CRLF の前に何も無い行), それとあれば message-body から構成されます。
generic-message = start-line
*(message-header CRLF)
CRLF
[ message-body ]
start-line = Request-Line | Status-LineIn the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
頑強性の点から、サーバーは Request-Line が来るはずのところで 受け取った空行を無視するべきです。他の言葉でいえば、サーバーが メッセージの始めのプロトコル列を読んで最初に CRLF を受け取ったなら、 その CRLF は無視するべきです。
Certain buggy HTTP/1.0 client implementations generate extra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an extra CRLF.
イかれた HTTP/1.0 の顧客実装は余計な CRLF 達を POST 要求の後に生成します。 BNF で明示的に禁止されていることを 繰り返しますが、 HTTP/1.1 顧客は要求の前や後に余計な CRLF をつけてはいけません。
In addition to defining the
{1945} HTTP/1.0HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" {2616} and "application/http". {2616} The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered with IANA{1945} [13]{2616} [17] .
この文書は、 HTTP プロトコルを定義するのに加えて、インターネット媒体型
message/http および application/http
の仕様を給仕します。message/http 型は、単一の HTTP 要求メッセージまたは応答メッセージを、すべての message 型についての行長と符号化に関する MIME の制限に従うものとして囲むために使うことができます。 application/http 型は、一つ以上の HTTP 要求メッセージ群または応答メッセージ群 (非混合。) のパイプ線を囲むために使うことができます。
次は、 IANA に登録されます。
- Media Type name
- message
- Media subtype name
- http
- Required parameters
- none
- Optional parameters
- version, msgtype
- version
- The HTTP-Version number of the enclosed message (e.g.,
{1945} "1.0""1.1"). If not present, the version can be determined from the first line of the body.
囲まれたメッセージの HTTP-Version 番号
(例えば 1.0 や 1.1。)
存在しなければ、版は本体の最初の行から決定できます。
- msgtype
- The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
メッセージ型 — request 又は response。
存在しなければ、型は本体の最初の行から決定できます。
- Encoding considerations
- only "7bit", "8bit", or "binary" are permitted
- Security considerations
- none
{2616}
- Media Type name
- application
- Media subtype name
- http
- Required parameters
- none
- Optional parameters
- version, msgtype
- version
- The HTTP-Version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body.
囲まれたメッセージの HTTP-Version 番号
(例えば 1.1。)
存在しなければ、版は本体の最初の行から決定できます。
- msgtype
- The message type -- "request" or "response". If not present, the type can be determined from the first line of the body.
メッセージ型 — request 又は response。
存在しなければ、型は本体の最初の行から決定できます。
- Encoding considerations
- HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via E-mail.
この型で囲まれた HTTP メッセージは binary 書式です。
電子メイルを介して転送するときには適切な Content-Transfer-Encoding
が必要です。
- Security considerations
- none
HTTP messages consist of requests from client to server and responses from server to client.
HTTP メッセージは、クライアントからサーバーへの要求とサーバーからクライアントへの応答から成ります。
HTTP-message = Simple-Request ; HTTP/0.9 messages | Simple-Response | Full-Request ; HTTP/1.0 messages | Full-Response
- HTTP-message = Request | Response ; HTTP/1.1 messages
Full-RequestRequest (section 5) andFull-ResponseResponse (section 6) messages use the generic message format of RFC 822[7][9] for transferring entities (the payload of the message).Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).Both types of message consist of a start-line,onezero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, andan optionalpossibly a message-body.
(完全)要求メッセージと(完全)応答メッセージは、実体 (メッセージの積荷)
を転送するために RFC822 の一般メッセージ書式を使います。
メッセージのどちらの型も、 start-line (開始行)、一つ零個以上の頭欄
(頭とも)、頭欄並びの終わりを示す空行 (つまり CRLF の前に何も無い行)、
それにもしかすると message-body (メッセージ本体)
から成ります。
Full-Request = Request-Line ; Section 5.1 *( General-Header ; Section 4.3 | Request-Header ; Section 5.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2Full-Response = Status-Line ; Section 6.1 *( General-Header ; Section 4.3 | Response-Header ; Section 6.2 | Entity-Header ) ; Section 7.1 CRLF [ Entity-Body ] ; Section 7.2
generic-message = start-line*message-header*(message-header CRLF) CRLF [ message-body ]- start-line = Request-Line | Status-Line
Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET).
Simple-Request (単純要求) と Simple-Response
は頭情報の使用を認めず、要求方式も1つ (GET)
に限定します。
- Simple-Request = "GET" SP Request-URI CRLF
- Simple-Response = [ Entity-Body ]
Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity.
Simple-Request 書式は、サーバーから返される実体の媒体型を識別することができませんから、
その使用は非推奨とします。
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
頑強性の観点から、サーバーは Request-Line
が期待されるところで受取った空行(並び)を無視するべきです。
言い換えると、サーバーがメッセージのはじめでプロトコル流を読んでいて最初に
CRLF を受取ったら、この CRLF は無視するべきです。
Note: certainCertain buggy HTTP/1.0 client implementations generateanextra CRLF's after a POST request. To restate what is explicitly forbidden by the BNF, an HTTP/1.1 clientmust notMUST NOT preface or follow a request with an extra CRLF.
ある蝕まれた HTTP/1.0 クライアント実装は POST
要求の後に余分な CRLF を生成します。 BNF で陽に禁止されていることを繰り返しますが、
HTTP/1.1 クライアントは要求の前や後に余分な CRLF を入れてはいけません。
注: 追加・削除は 1945→2068 のもの。追加中の追加・削除は 2068→2616 のもの。
→一般頭欄
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by
{1945} [17]{2068,2616} ANSI X3.4-1986 [21] .
次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。
- 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.0HTTP/1.1 defines the{1945} octetsequence CR LF as the end-of-line marker for all protocol elements except the{1945} Entity-Bodyentity-body (see{1945} Appendix Bappendix 19.3 for tolerant applications). The end-of-line marker within an{1945} Entity-Bodyentity-body is defined by its associated media type, as described in{1945} Section 3.6section 3.7.
HTTP は実体本体を除くすべてのプロトコル要素で列 CR LF を行末の印と定義します。 実体本体中の行末の印はその関連付けられた媒体型により定義されます。
- CRLF = CR LF
HTTP/1.0HTTP/1.1{1945,2068} headers{2616} header field values{1945} maycan be folded onto multiple lines if{1945} eachthe continuation line begins with a space or horizontal tab. All linear{1945} whitespacewhite space, including folding, has the same semantics as SP. {2616} A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
HTTP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。
すべての線形空白は、折畳みも含み、 SP
と同じ意味を持ちます。受信者は、欄値を解釈したり下流にメッセージを転送する前に任意の線形空白を単一の SP に置換しても構いません。
- LWS = [CRLF] 1*( SP | HT )
{1945} However, folding of header lines is not expected by some applications, and should not be generated by HTTP/1.0 applications.
しかし、頭行の折畳みを予期していない応用もありますので、 HTTP/1.0 応用は生成するべきではありません。
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT
{1945,2068} may{2616} MAY contain{1945} octetscharacters from character sets other than{1945} US-ASCII{2068,2616}ISO 8859-1ISO-8859-1 [22] only when encoded according to the rules of RFC15222047 [14] .
TEXT 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。
*TEXT の語は US-ASCII RFC 2047 の規則に従って符号化するときのみ ISO-8859-1
以外の文字集合のオクテット文字を含んでも構いません。
- TEXT = <any OCTET except CTLs, but including LWS>
{1945} Recipients of header field TEXT containing octets outside the US-ASCII character set may assume that they represent ISO-8859-1 characters.
US-ASCII 文字集合の外のオクテットを含んだ頭欄 TEXT の受信者は、
それが ISO-8859-1 文字を表現するものと仮定しても構いません。
{2616} A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.
CRLF は、 TEXT の定義の中では、
頭欄継続の一部としてのみ認められています。
折畳み LWS は TEXT 値の解釈の前に単一の
SP に置換されることを意図定しています。
Hexadecimal numeric characters are used in several protocol elements.
十六進数文字は幾つかのプロトコル要素で使います。
- HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
Many
HTTP/1.0HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters{1945} mustMUST be in a quoted string to be used within a parameter value {2616} (as defined in section 3.6).
多くの HTTP 頭欄値は、 LWS または特殊文字で分離される語で構成されます。
特殊文字は引数値中で使うためには引用文字列中にいれなければなりません。
{1945}
- word = token | quoted-string
{1945,2068}
- token = 1*<any CHAR except CTLs or tspecials>
- tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
{2616}
- token = 1*<any CHAR except CTLs or separators>
- separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT
Comments
{1945} maycan be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
注釈は、注釈文を括弧で囲むことで幾つかの HTTP 頭欄中に含めることができます。
注釈は、欄値定義の一部に comment を含んでいる欄でのみ認められます。
他のすべての欄では、括弧は欄値の一部とみなされます。
{1945,2068} comment = "(" *( ctext | comment ) ")"- {2616} comment = "(" *( ctext | quoted-pair | comment ) ")"
- ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
二重引用符を使って引用されている文字列は単一の語として解析します。
{1945,2068} quoted-string = ( <"> *(qdtext) <"> )- {2616} quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
{1945} qdtext = <any CHAR except <"> and CTLs, but including LWS>- {2068,2616} qdtext = <any TEXT except <">>
{1945} Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0.
HTTP/1.0 では逆斜線 (\) 文字を使った単一文字引用は認められていません。
{2068,2616} The backslash character ("\")
mayMAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
逆斜線文字 (\) は、 quoted-string 構造体および
comment 構造体の中でのみ、
単一文字引用機構として使って構いません。
- quoted-pair = "\" CHAR
The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used in RFC 2068 [2].
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)>
CRLF = CR LF
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
>
token = 1*<any CHAR except CTLs or tspecials>
quoted-string = ( <"> *(qdtext) <"> )
qdtext = <any TEXT except <">>
quoted-pair = "\" CHAR
>
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or
combinations of token, tspecials, and
quoted-string>
>
safe = "\$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "$'$" | "(" | ")" | ","
>
hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "\%" hex hex
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
>
unreserved = alpha | digit | safe | extra
xchar = unreserved | reserved | escape訳注 : 編集上の誤りっぽいところがありますが、原文通りにしておきます。
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986.
次の規則はこの仕様書を通じて基本解析構造体を記述するために使用します。 US-ASCII 符号化文字集合は ANSI X 3.4‐1986 で定義されています。
- OCTET = <any 8-bit sequence of data>
- CHAR = <any US-ASCII character (octets 0 - 127)>
- upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
- lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
- alpha = lowalpha | upalpha
- digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"
- alphanum = alpha | digit
- CTL = <any US-ASCII control character
- (octets 0 -- 31) and DEL (127)>
- CR = %d13 ; US-ASCII CR, carriage return character
- LF = %d10 ; US-ASCII LF, line feed character
- SP = %d32 ; US-ASCII SP, space character
- HT = %d09 ; US-ASCII HT, horizontal tab character
- CRLF = CR LF ; typically the end of a line
- alphanum = ALPHA / DIGIT
The following are defined in RFC 2396 [12] for the SIP URI: Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include:
次は RFC2396 で定義されており、 SIP URI で使います。幾つかの規則は RFC 2396 と違っていますが、 RFC2234 に適合するために更新したものです。
- unreserved = alphanum | mark
- mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
- escaped = "%" hex hex
- reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / ","
- unreserved = alphanum / mark
- mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")"
- escaped = "%" HEXDIG HEXDIG
SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators.
SIP 頭欄値は、続く行が間隔又は水平タブで始まるのであれば複数行に折畳むことができます。
すべての線形空白は、折畳みも含み、 SP
と同じ意味を持ちます。受信者は、欄値を解釈したり下流にメッセージを転送する前に任意の線形空白を単一の SP に置換しても構いません。これは RFC 2616 で説明されている HTTP/1.1 の場合と全く同じようになることを意図しています。 SWS 構造体は線形空白が省略可能である時、通常は字句と分離子の間で使います。
LWS = [CRLF] 1*( SP | HT ) ; linear whitespace- LWS = [*WSP CRLF] 1*WSP ; linear whitespace
- SWS = [LWS] ; sep whitespace
To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct.
頭名を残りの値と分離するためにコロンを使いますが、
これは上の規則により前に空白を求めるものの改行は認めず、
後には空白を改行も含めて認めます。 HCOLON
はこの構造体を定義します。
- HCOLON = *( SP / HTAB ) ":" SWS
The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8
character set (RFC 2279 [21])charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set.
TEXT-UTF8 規則は記述的欄内容とメッセージ解析器に解釈されることを意図しない値にのみ使います。
*TEXT-UTF8 の語は UTF-8 charset の文字だけを含めます。TEXT-UTF8-TRIM 規則は引用文字列ではなく、最初と最後の LWS が意味を持たない記述的欄内容に使用します。
この点では、 SIP は ISO 8859‐1 を使用する HTTP と異なります。
- TEXT-UTF8 = <any UTF-8 character encoding, except CTLs, but including LWS>
- TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char)
- TEXT-UTF8char = %x21-7E / UTF8-NONASCII
- UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT
- UTF8-CONT = %x80-BF
A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT-UTF8-TRIM value.
CRLFは、TEXT-TRIMの定義の中では、 頭欄継続の一部としてのみ認められています。 折畳みLWSはTEXT-TRIM値の解釈の前に単一のSPに置換されることを意図定しています。Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case.
十六進数文字は幾つかのプロトコル要素で使います。幾つかの要素 (認証) は十六進字母が小文字であることを強制します。
hex = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | digit- LHEX = DIGIT / %x61-66 ;lowercase a-f
Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case-insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used.
多くの SIP 頭欄値は、
LWSまたは特殊文字で分離される語で構成されます。別途言及されていない限り、字句は大文字・小文字を区別します。 特殊文字は引数値中で使うためには引用文字列中にいれなければなりません。word構造体はCall-IDでほとんどの分離子を使用できるようにするために使います。
token = 1*< any CHAR except CTL's or separators>- token = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" )
separators = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT- separators = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "=" / "{" / "}" / SP / HTAB
- word = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" / "`" / "'" / "~" / "(" / ")" / "<" / ">" / ":" / "\" / DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" )
When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters:
字句が使われる場合や分離子が要素間で使われる場合には、 空白がしばしばその文字の前後に認められます。
- STAR = SWS "*" SWS ; asterisk
- SLASH = SWS "/" SWS ; slash
- EQUAL = SWS "=" SWS ; equal
- LPAREN = SWS "(" SWS ; left parenthesis
- RPAREN = SWS ")" SWS ; right parenthesis
- RAQUOT = ">" SWS ; right angle quote
- LAQUOT = SWS "<"; left angle quote
- COMMA = SWS "," SWS ; comma
- SEMI = SWS ";" SWS ; semicolon
- COLON = SWS ":" SWS ; colon
- LDQUOT = SWS DQUOTE; open double quotation mark
- RDQUOT = DQUOTE SWS ; close double quotation mark
Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
注釈は、注釈文を括弧で囲むことで幾つかの SIP 頭欄中に含めることができます。 注釈は、欄値定義の一部に
commentを含んでいる欄でのみ認められます。 他のすべての欄では、括弧は欄値の一部とみなされます。
comment = "(" *(ctext | quoted-pair | comment) ")"- comment = LPAREN *(ctext / quoted-pair / comment) RPAREN
ctext = < any TEXT-UTF8 excluding "(" and ")">- ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS
ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks (") and backslashes (\) need to be escaped.
;
ctextは左右の括弧と逆斜線を除くすべての文字を含みます。 二重引用符を使って引用されている文字列は単一の語として解析します。引用文字列中では、引用符 (") と逆斜線 (\) は escape する必要があります。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )- quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE
qdtext = <any TEXT-UTF8 except <">>- qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation.
逆斜線文字 (
\) は、quoted-string構造体およびcomment構造体の中でのみ、 単一文字引用機構として使って構いません。HTTP/1.1 とは異なり、文字CR及びLFは行折畳みや頭分離との衝突を避けるためにこの機構を使って escape することはできません。
quoted-pair = " \ " CHAR- quoted-pair = "\" (%x00-09 / %x0B-0C / %x0E-7F)
[12] Apache HTTP Server Project ( ( 版)) http://httpd.apache.org/docs/1.3/misc/known_client_problems.html#force-response-1.0
[532] RFC 2660 - The Secure HyperText Transfer Protocol ( ( 版)) http://tools.ietf.org/html/rfc2660#section-2.4.2
[2055] RFC 4236 - HTTP Adaptation with Open Pluggable Edge Services (OPES) ( ( 版)) https://tools.ietf.org/html/rfc4236
Message
Request or a response between an OpenID Relying Party and an OpenID Provider.
proxy-sendextracrlf
Causes proxy to send an extra CR-LF newline on the end of a request. This is a workaround for a bug in some browsers.
By default, the message bodies of NOTIFY messages for the http-
monitor event package will be of content-type "message/http," as
defined in RFC 2616 [2].