[1] 状態行status lineは、応答メッセージの開始行です。

仕様書

構文

[3] 状態行は、HTTPの版、SP、状態符号、 理由句、CRLF を順に連ねたものです >>2。

  1. HTTPの版
  2. SP
  3. 状態符号
  4. SP
  5. 理由句
  6. CRLF

[4] 状態符号は応答メッセージの意味を決める3桁の整数です。

[5] 理由句は数値の状態符号に対応するテキストの説明を提供するものです >>2。

[7] HTTPの版は、送信者が対応するHTTPの版を示すものです。

[11] HTTP/0.9 メッセージには状態行がありません。

構文解析

[32] HTTPの構文解析も参照。

[9] 構文上 SP の箇所は、空白1つ以上を区切りとみなして構文解析して構いません。 また、最初と CRLF 前の空白は無視して構いません。ここで空白は、 SP、HTAB、VT、FF、CR のことをいいます。 >>8

[33] 実際には IE も Firefox も Chrome も、 SP のみを空白とみなすようです。 IE と Chrome は複数の SP も空白とみなします。 Firefox は SP が複数あっても状態符号を正しく取得できますが、 理由句は (状態符号の前に SP が複数あると) おかしくなります。

[26] Chrome は、プロトコルの版と空白の後、0文字以上の数字列があれば、 それを状態符号とします。その後空白があれば無視し、残ったものを理由句とします。 (少なくても XHR の status では) 231 以上なら、 231-1 がかわりに返されます。数字列がない場合、 200 OK とみなされ、実際の残りの文字列は無視されます。

[28] (少なくても XHR では) Firefox は符号無し16ビット整数として扱い、 0 になるならかわりに 200 を返します。 IE は32ビット符号付き整数として扱います。 Firefox でも IE でも大きすぎると桁溢れします。

[29] Firefox でも IE でも、状態符号の後に空白がないと、 理由句がないものとして扱われます。

[30] Chrome でも IE でも Firefox でも、先導0はたくさんあっても正しく無視します。

[27] (少なくても Chrome の XHR は) プロトコルの版よりも前に空白やそれ以外の文字があると、すべて無視します。 プロトコルの版の後に空白、状態符号、理由句と解釈できるものがあれば、 そのように扱われます。 (プロトコルの版参照。)

[34] 理由句の末尾の空白は、 IE と Firefox ではそのまま保存されますが、 Chrome では除去されます。

[35] HTTPクライアントの中には、理由句が空文字列の時に正しく処理できず、 最初のヘッダーが理由句とみなされるなどおかしな動作をするものもあります。

[10] 改行については、メッセージの項を参照してください。

[13] 応答の最初の行が状態行として解釈できない場合、 HTTP/0.9 応答とみなされることとなります。

HTTP/0.9 も参照。

status 要素 (WebDAV)

[21] DAV: 名前空間の status 要素は、 HTTP 状態行を表します >>19。

[22] 内容は、状態行を表す文字データです >>19。

  1. 状態行

[20] RFC 2616 の状態行の定義を参照しており >>19、末尾に CRLF が含まれることとなっていますが、 RFC 4918 中の例示はすべて改行なしとなっており、 実際には改行は含めないのが意図と思われます。

[23] プロトコルの版は RFC 4918 の例示ではすべて HTTP/1.1 となっていますが、その決め方や解釈は明記されていません。

[18] status 要素は、 response 要素で使うことができ >>17、 href 要素で示される資源に関する状態を表します。

[16] status 要素は、 propstat 要素で使うことができ、 prop 要素に含まれる特性に関する状態を表します >>15。

歴史

[6] RFC 1945 (HTTP/1.0); RFC 2068・2616 (HTTP/1.1) 6.1 Status-Line

The first line of a {1945} Full-Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.

Full-Response メッセージの最初の行は Status-Line で、プロトコルの版とそれに続く数値状態符号とそれに関連付けられた文語句で構成され、 それぞれの要素は SP 文字で分離します。 最終 CRLF 列を除いて CR や LF は認められていません。

  • Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

{1045} Since a status line always begins with the protocol version and status code

状態行は常にプロトコルの版と状態符号

  • "HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP

(e.g., "HTTP/1.0 200 "), the presence of that expression is sufficient to differentiate a Full-Response from a Simple-Response. Although the Simple-Response format may allow such an expression to occur at the beginning of an entity body, and thus cause a misinterpretation of the message if it was given in response to a Full-Request, most HTTP/0.9 servers are limited to responses of type "text/html" and therefore would never generate such a response.

(例えば HTTP/1.0 200 ) で始まりますから、 この表現の存在は Full-Response と Simple-Response を区別するのに十分です。 Simple-Response 書式は実体本体にこのような表現を認めていますから、 Full-Request 経の応答でそのようなものがあるとメッセージの誤解釈を起こしてしまうことになりますが、 ほとんどの HTTP/0.9 サーバーは型 text/html の応答に制限されていますから、そのような応答は決して生成されないでしょう。

6.1.1 Status Code and Reason Phrase

→状態符号

[14] RFC 2518 (WebDAV) 12.9.1.2 status XML Element

Name
status
Namespace
DAV:
Purpose
Holds a single HTTP status-line
Value
status-line ;status-line defined in [RFC2068]
目的
単一の HTTP status-lineを保持します
値
status-line ; status-line は [{RFC2068 で定義]]

<!ELEMENT status (#PCDATA) >

[12] RFC 3507 - Internet Content Adaptation Protocol (ICAP) ( ( 版)) http://tools.ietf.org/html/rfc3507#section-4.3.3

[24] draft-singer-appsawg-mcast-url-00 - URLs and HTTP Response Forms for Multicast ( ( 版)) https://tools.ietf.org/html/draft-singer-appsawg-mcast-url-00#section-6

関連

[25] HTTP/2 では、疑似ヘッダーが状態行の役割を果たしています。