Hypertext Transfer Protocol - HTTP/1.1
UC Irvine
J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
January 1997
Request for Comments: 2068
Category: Standards Track
この記述の状態
このドキュメントはインターネットコミュニティのためのインターネット標準トラックプロトコルを詳述し、改善のための論議と提案を要求する。標準化の状態とこのプロトコルは "インターネット公式プロトコル標準" (STD 1) の最新版を参照してください。この記述の配布は無制限である。
概要
Hypertext Transfer Protocol (HTTP) は共同的ハイパーメディア情報システム配布システムのためのアプリケーションレベルプロトコルである。これはリクエストメソッドの拡張を通じて、ネームサーバやオブジェクト配布管理システムなど、さまざまな作業に対して使用する事のできる一般的で国に依存しないオブジェクト指向プロトコルである。HTTP の機構はデータ表現のタイプ付けやネゴシエーションを行う事であり、転送データに依存しないシステムを構築できる。
HTTP は 1990 から World-Wide Web グローバル情報イニシアティブとしてすでに使用されている。この仕様書は "HTTP/1.1" として言及されるプロトコルを定義する。
目次
1 Introduction.............................................7 1.1 Purpose ..............................................7 1.2 Requirements .........................................7 1.3 Terminology ..........................................8 1.4 Overall Operation ...................................11 2 Notational Conventions and Generic Grammar..............13 2.1 Augmented BNF .......................................13 2.2 Basic Rules .........................................15 3 Protocol Parameters.....................................17 3.1 HTTP Version ........................................17 3.2 Uniform Resource Identifiers ........................18 3.2.1 General Syntax ...................................18 3.2.2 http URL .........................................19 3.2.3 URI Comparison ...................................20 3.3 Date/Time Formats ...................................21 3.3.1 Full Date ........................................21 3.3.2 Delta Seconds ....................................22 3.4 Character Sets ......................................22 3.5 Content Codings .....................................23 3.6 Transfer Codings ....................................24 3.7 Media Types .........................................25 3.7.1 Canonicalization and Text Defaults ...............26 3.7.2 Multipart Types ..................................27 3.8 Product Tokens ......................................28 3.9 Quality Values ......................................28 3.10 Language Tags ......................................28 3.11 Entity Tags ........................................29 3.12 Range Units ........................................30 4 HTTP Message............................................30 4.1 Message Types .......................................30 4.2 Message Headers .....................................31 4.3 Message Body ........................................32 4.4 Message Length ......................................32 4.5 General Header Fields ...............................34 5 Request.................................................34 5.1 Request-Line ........................................34 5.1.1 Method ...........................................35 5.1.2 Request-URI ......................................35 5.2 The Resource Identified by a Request ................37 5.3 Request Header Fields ...............................37 6 Response................................................38 6.1 Status-Line .........................................38 6.1.1 Status Code and Reason Phrase ....................39 6.2 Response Header Fields ..............................41 7 Entity..................................................41 7.1 Entity Header Fields ................................41 7.2 Entity Body .........................................42 7.2.1 Type .............................................42 7.2.2 Length ...........................................43 8 Connections.............................................43 8.1 Persistent Connections ..............................43 8.1.1 Purpose ..........................................43 8.1.2 Overall Operation ................................44 8.1.3 Proxy Servers ....................................45 8.1.4 Practical Considerations .........................45 8.2 Message Transmission Requirements ...................46 9 Method Definitions......................................48 9.1 Safe and Idempotent Methods .........................48 9.1.1 Safe Methods .....................................48 9.1.2 Idempotent Methods ...............................49 9.2 OPTIONS .............................................49 9.3 GET .................................................50 9.4 HEAD ................................................50 9.5 POST ................................................51 9.6 PUT .................................................52 9.7 DELETE ..............................................53 9.8 TRACE ...............................................53 10 Status Code Definitions................................53 10.1 Informational 1xx ..................................54 10.1.1 100 Continue ....................................54 10.1.2 101 Switching Protocols .........................54 10.2 Successful 2xx .....................................54 10.2.1 200 OK ..........................................54 10.2.2 201 Created .....................................55 10.2.3 202 Accepted ....................................55 10.2.4 203 Non-Authoritative Information ...............55 10.2.5 204 No Content ..................................55 10.2.6 205 Reset Content ...............................56 10.2.7 206 Partial Content .............................56 10.3 Redirection 3xx ....................................56 10.3.1 300 Multiple Choices ............................57 10.3.2 301 Moved Permanently ...........................57 10.3.3 302 Moved Temporarily ...........................58 10.3.4 303 See Other ...................................58 10.3.5 304 Not Modified ................................58 10.3.6 305 Use Proxy ...................................59 10.4 Client Error 4xx ...................................59 10.4.1 400 Bad Request .................................60 10.4.2 401 Unauthorized ................................60 10.4.3 402 Payment Required ............................60 10.4.4 403 Forbidden ...................................60 10.4.5 404 Not Found ...................................60 10.4.6 405 Method Not Allowed ..........................61 10.4.7 406 Not Acceptable ..............................61 10.4.8 407 Proxy Authentication Required ...............61 10.4.9 408 Request Timeout .............................62 10.4.10 409 Conflict ...................................62 10.4.11 410 Gone .......................................62 10.4.12 411 Length Required ............................63 10.4.13 412 Precondition Failed ........................63 10.4.14 413 Request Entity Too Large ...................63 10.4.15 414 Request-URI Too Long .......................63 10.4.16 415 Unsupported Media Type .....................63 10.5 Server Error 5xx ...................................64 10.5.1 500 Internal Server Error .......................64 10.5.2 501 Not Implemented .............................64 10.5.3 502 Bad Gateway .................................64 10.5.4 503 Service Unavailable .........................64 10.5.5 504 Gateway Timeout .............................64 10.5.6 505 HTTP Version Not Supported ..................65 11 Access Authentication..................................65 11.1 Basic Authentication Scheme ........................66 11.2 Digest Authentication Scheme .......................67 12 Content Negotiation....................................67 12.1 Server-driven Negotiation ..........................68 12.2 Agent-driven Negotiation ...........................69 12.3 Transparent Negotiation ............................70 13 Caching in HTTP........................................70 13.1.1 Cache Correctness ...............................72 13.1.2 Warnings ........................................73 13.1.3 Cache-control Mechanisms ........................74 13.1.4 Explicit User Agent Warnings ....................74 13.1.5 Exceptions to the Rules and Warnings ............75 13.1.6 Client-controlled Behavior ......................75 13.2 Expiration Model ...................................75 13.2.1 Server-Specified Expiration .....................75 13.2.2 Heuristic Expiration ............................76 13.2.3 Age Calculations ................................77 13.2.4 Expiration Calculations .........................79 13.2.5 Disambiguating Expiration Values ................80 13.2.6 Disambiguating Multiple Responses ...............80 13.3 Validation Model ...................................81 13.3.1 Last-modified Dates .............................82 13.3.2 Entity Tag Cache Validators .....................82 13.3.3 Weak and Strong Validators ......................82 13.3.4 Rules for When to Use Entity Tags and Last- modified Dates..........................................85 13.3.5 Non-validating Conditionals .....................86 13.4 Response Cachability ...............................86 13.5 Constructing Responses From Caches .................87 13.5.1 End-to-end and Hop-by-hop Headers ...............88 13.5.2 Non-modifiable Headers ..........................88 13.5.3 Combining Headers ...............................89 13.5.4 Combining Byte Ranges ...........................90 13.6 Caching Negotiated Responses .......................90 13.7 Shared and Non-Shared Caches .......................91 13.8 Errors or Incomplete Response Cache Behavior .......91 13.9 Side Effects of GET and HEAD .......................92 13.10 Invalidation After Updates or Deletions ...........92 13.11 Write-Through Mandatory ...........................93 13.12 Cache Replacement .................................93 13.13 History Lists .....................................93 14 Header Field Definitions...............................94 14.1 Accept .............................................95 14.2 Accept-Charset .....................................97 14.3 Accept-Encoding ....................................97 14.4 Accept-Language ....................................98 14.5 Accept-Ranges ......................................99 14.6 Age ................................................99 14.7 Allow .............................................100 14.8 Authorization .....................................100 14.9 Cache-Control .....................................101 14.9.1 What is Cachable ...............................103 14.9.2 What May be Stored by Caches ...................103 14.9.3 Modifications of the Basic Expiration Mechanism 104 14.9.4 Cache Revalidation and Reload Controls .........105 14.9.5 No-Transform Directive .........................107 14.9.6 Cache Control Extensions .......................108 14.10 Connection .......................................109 14.11 Content-Base .....................................109 14.12 Content-Encoding .................................110 14.13 Content-Language .................................110 14.14 Content-Length ...................................111 14.15 Content-Location .................................112 14.16 Content-MD5 ......................................113 14.17 Content-Range ....................................114 14.18 Content-Type .....................................116 14.19 Date .............................................116 14.20 ETag .............................................117 14.21 Expires ..........................................117 14.22 From .............................................118 14.23 Host .............................................119 14.24 If-Modified-Since ................................119 14.25 If-Match .........................................121 14.26 If-None-Match ....................................122 14.27 If-Range .........................................123 14.28 If-Unmodified-Since ..............................124 14.29 Last-Modified ....................................124 14.30 Location .........................................125 14.31 Max-Forwards .....................................125 14.32 Pragma ...........................................126 14.33 Proxy-Authenticate ...............................127 14.34 Proxy-Authorization ..............................127 14.35 Public ...........................................127 14.36 Range ............................................128 14.36.1 Byte Ranges ...................................128 14.36.2 Range Retrieval Requests ......................130 14.37 Referer ..........................................131 14.38 Retry-After ......................................131 14.39 Server ...........................................132 14.40 Transfer-Encoding ................................132 14.41 Upgrade ..........................................132 14.42 User-Agent .......................................134 14.43 Vary .............................................134 14.44 Via ..............................................135 14.45 Warning ..........................................137 14.46 WWW-Authenticate .................................139 15 Security Considerations...............................139 15.1 Authentication of Clients .........................139 15.2 Offering a Choice of Authentication Schemes .......140 15.3 Abuse of Server Log Information ...................141 15.4 Transfer of Sensitive Information .................141 15.5 Attacks Based On File and Path Names ..............142 15.6 Personal Information ..............................143 15.7 Privacy Issues Connected to Accept Headers ........143 15.8 DNS Spoofing ......................................144 15.9 Location Headers and Spoofing .....................144 16 Acknowledgments.......................................144 17 References............................................146 18 Authors' Addresses....................................149 19 Appendices............................................150 19.1 Internet Media Type message/http ..................150 19.2 Internet Media Type multipart/byteranges ..........150 19.3 Tolerant Applications .............................151 19.4 Differences Between HTTP Entities and MIME Entities...........................................152 19.4.1 Conversion to Canonical Form ...................152 19.4.2 Conversion of Date Formats .....................153 19.4.3 Introduction of Content-Encoding ...............153 19.4.4 No Content-Transfer-Encoding ...................153 19.4.5 HTTP Header Fields in Multipart Body-Parts .....153 19.4.6 Introduction of Transfer-Encoding ..............154 19.4.7 MIME-Version ...................................154 19.5 Changes from HTTP/1.0 .............................154 19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses .................................155 19.6 Additional Features ...............................156 19.6.1 Additional Request Methods .....................156 19.6.2 Additional Header Field Definitions ............156 19.7 Compatibility with Previous Versions ..............160 19.7.1 Compatibility with HTTP/1.0 Persistent Connections............................................161
1 イントロダクション
1.1 目的
Hypertext Transfer Protocol (HTTP) は共同的ハイパーメディア情報配布システムのためのアプリケーションレベルプロトコルである。HTTP は 1990 から World-Wide Web グローバルインフォメーションイニシアティブによる使用によって存在している。HTTP/0.9 と呼ばれる HTTP の最初のバージョンはインターネット上で未加工のデータを転送するための簡単なプロトコルであった。RFC 1945 [6] で定義されている HTTP/1.0 は、転送データに対するメタ情報とリクエスト/レスポンスセマンティクスの修飾子を含めた MIME-like なメッセージフォーマットを使用する事でプロトコルを改善した。しかしながら、HTTP/1.0 はプロキシ、キャッシングの階層構造と永続的な接続の必要性、仮想ホストの効果の熟慮を十分に取っていなかった。さらに、自身を "HTTP/1.0" と称する不完全に実装されたアプリケーションの激増により、双方の通信アプリケーションが互いに真の能力を発揮するための適切なプロトコルバージョンの変更が必要となった。
この仕様書は "HTTP/1.1" と呼ばれるプロトコルを定義している。このプロトコルはその機能の確実な実装を保証するため HTTP/1.0 よりもより厳格な要求を加えている。
現実的なの情報システムは単純な参照や包括的検索、front-end 更新、注釈よりもより多くの機能性を必要としている。HTTP は要求目的を示すメソッドを開放的 (open-ended) セットにしている。これは、メソッドが適用されるリソースを示す場所 (URL) [4] や名前 (URN) となる Uniform Resource Identifier (URI) [3][20] によって供給される参照規律に基づいている。メッセージは Multipurpose Internet Mail Extensions (MIME) として定義されているインターネットメールで使用されている形式に似たフォーマットで渡される。
HTTP はユーザエージェントが SMTP [16], NNTP [13], FTP [18], Gopher[2], WAIS [10] プロトコルなどを使用している別の情報システムへのプロキシ/ゲートウェイと通信を行うための一般的なプロトコルとしても使用される。このように、HTTP は多様なアプリケーションから利用できるリソースへの基本的なハイパーメディアアクセスを可能にする。
1.2 要求
この仕様書は入念な要求それぞれの意味を定義するために RFC 1123 [8] と同じ言葉を使用している。これらの言葉は:
- MUST: ならない
- この言葉や形容詞 "必要とされる" はそのその項目が仕様書において絶対に必要である事を意味する。
- SHOULD: すべきである
- この言葉や形容詞 "推奨される" はこの項目を無効とするのに妥当な理由が存在する、特有の状況が存在するかもしれない事を意味する。しかし、完全な実装を行うのであれば、別の方法をとる前によく理解して状況を注意深く考えるべきである。
- MAY: かもしれない, 事がある, 可能性がある
- この言葉もしくは形容詞 "オプション的" はこの項目が正確に任意である事を意味する。たとえば、特有の市場がその項目を要求している場合や製品の改良のためベンダはその項目を選ぶかもしれないし、別のベンダは同じ項目を除外するかもしれない。
もし実装したプロトコルが MUST 要求を一つでも満足していないなら、インプリメンテーションは従順ではない。プロトコルのすべての MUST とすべての SHOULD 要求を満たしているインプリメンテーションは "無条件に従順" と呼ばれる。プロトコルの全 MUST 要求を満たしているが、すべての SHOULD 要求を満たしているわけではないものは "条件付きで従順である" と呼ばれる。[訳注: 日本語訳において曖昧さが生じるため、厳密な使用は原文参照]
1.3 用語
この仕様書は HTTP 通信の参加者とオブジェクトが行う役割を表す幾つかの言葉を使用している。
- 接続
- 通信を目的とする二つのプログラムの間で確立されるトランスポート層仮想回路 (transport layer virtual circuit)。
- メッセージ
- 8 ビットバイト (octet) のシーケンスで構成された 4 章で定義される構文と一致するものと、接続を経由して転送されたもので成り立つ HTTP 通信の基本ユニット。
- リクエスト
- 5 章で定義されているような HTTP リクエストメッセージ。
- レスポンス
- 6 章で定義されているような HTTP レスポンスメッセージ。
- リソース
- 3.2 章で定義されている URI で識別できるネットワーク上のデータオブジェクトやサービス。リソースは複数の表現 (多様な言語、データフォーマット、サイズ、解像度のような) もしくは別の方法で変化させて利用できるかもしれない。
- エンティティ
- リクエストやレスポンスの結果として転送される情報。7 章で表されているように、エンティティは entity-header フィールド形式のメタ情報や entity-body 形式の内容 (Content) で構成される。
- 表現
- 12 章で表されるように、内容ネゴシエーションを行ったレスポンスに含まれるエンティティ。詳細なレスポンスステータスに関連した複数の表現が存在するかもしれない。
- 内容ネゴシエーション
- 12 章で表されるように、あるリクエストに対してサービスを行うときに適切な表現を選択するためのメカニズム。どのようなレスポンスのエンティティ表現もネゴシエーションする事ができる (エラーレスポンスを含む)。
- バリアント
- リソースは発生したあらゆる瞬間に、自分と関連する一つ以上の表現を持つかもしれない。これらの表現のそれぞれは `バリアント' と称される。`バリアント' という言葉の使用はリソースが内容ネゴシエーションに従っている事を暗黙的に意味するというわけではない。
- クライアント
- リクエスト送信の目的のため接続を確立するプログラム。
- ユーザエージェント
- リクエストを開始するクライアント。ブラウザ、エディタ、スパイダー (ウェブをわたるロボット) やその他のエンドユーザツールなどがある。
- サーバ
- レスポンスを送り返して要求を実行する目的で接続を受け入れるアプリケーションプログラム。作成されたどのようなプログラムもクライアントとサーバの両方の機能を持つことができる。われわれがクライアントやサーバという言葉を使用する場合、ある接続でプログラムが行う役割のみを指し、一般的なプログラムの機能を意味するのではない。同様に、どのようなサーバも個々のリクエストの性質に基づいて動作を変化させ、オリジンサーバ、プロキシ、ゲートウェイやトンネルの動作をすることができる。
- オリジンサーバ
- 与えられたリソースが存在もしくは制作されるサーバ。
- プロキシ
- 他のクライアントに代わってリクエストを作成する目的で、サーバとクライアントの両方の動作を演じる中間プログラム。リクエストはプロキシ内部で、または可能な変換を伴って別のサーバに渡すことで実行される。プロキシはこの仕様書のクライアントとサーバ両方を実装しなければならない。
- ゲートウェイ
- ある別のサーバへの中継者を演じるサーバ。プロキシと違い、リクエストされたりソースのオリジンサーバであるかのように要求を実行する。リクエストしているクライアントはゲートウェイと通信している事を意識する必要はない。
- トンネル
- 二つの接続間で機械的な中継をする役割の中間プログラム。トンネルは HTTP リクエストにより開始されたものかもしれないが、一度活性化すると HTTP 通信の当事者とみなされない。トンネルは中継している接続の両端がクローズされたときに存在を終了する。
- キャッシュ
- プログラムがレスポンスメッセージを保存するローカルな場所か、メッセージの保存、検索や削除を制御するサブシステム。キャッシュは後のレスポンスタイムを減らしたりネットワークバンド幅を減少するため、リクエストと同じ処理となるキャッシュ可能なレスポンスを保存する。トンネルとして動作しているサーバはキャッシュを使うことができないが、どんなクライアントもサーバもキャッシュを含むことができる。
- キャッシュ可能
- もしキャッシュが次回のリクエスト応答で使用するためにレスポンスメッセージのコピーを保存する事が認められるならば、レスポンスはキャッシュ可能である。HTTP レスポンスのキャッシュ可能性を決定するためのルールは 13 章で定義される。たとえリソースがキャッシュ可能だとしても、キャッシュがあるリクエストに対してキャッシュされたコピーを使えるかどうかに追加的な制約があるかもしれない。
- 直接的
- もしレスポンスが一つ以上のプロキシ経由によるためであろう不要な遅延なしに直接オリジンサーバから来たなら、レスポンスは直接的 (first-hand) である。レスポンスの正当性をオリジンサーバに直接確認した場合もレスポンスは直接的となる。
- 明確な満期時間
- オリジンサーバが意図する、キャッシュがさらなる確証動作なしにエンティティを返すべきではないという意味の時間。
- 発見的な満期時間
- 明確な満期時間が利用できないときにキャッシュが割り当てる満期時間。
- 年齢
- レスポンスの年齢は、それがオリジンサーバから送られるか、正当性が首尾良く確証されてからの時間である。
- 新鮮さの持続期間
- レスポンスの生成時間とその満期時間の間の長さ。
- 新鮮
- もしレスポンスの年齢がその新鮮な存在期間を超えていなければ、レスポンスは新鮮である。
- 新鮮でない/古くなった
- もしレスポンス年齢が新鮮な存在期間を超えていれば、レスポンスは新鮮でない。
- 意味的に透過
- リクエストしているクライアントにもサーバにもキャッシュの使用が影響を与えないとき (パフォーマンスを向上させるという効果を除いて)、キャッシュは個別のレスポンスを尊重して "意味的に透過" な態度をとる。キャッシュが意味的に透過であるとき、クライアントはサーバが直接処理したものと正確に同じレスポンス (hop-to-hop ヘッダを除いて) を受け取る。
- 正当性確証子
- キャッシュエントリがエンティティのコピーと等しいかどうかを調べるために使用されるプロトコル要素 (エンティティタグや Last-Modified 時刻など)。
1.4 全体的な操作
HTTP プロトコルはリクエスト/レスポンスプロトコルである。クライアントはサーバへの接続上で、プロトコルバージョン、リクエストメソッド、URI、そしてそれらの後に続くリクエスト修飾子、クライアント情報、可能であれば内容本体の MIME-like メッセージ形式でサーバにリクエストを送る。サーバは、メッセージのプロトコルバージョンと成功やエラーコードを意味するステータス行に続けてサーバ情報、エンティティメタ情報、可能であればエンティティボディ内容を含む MIME-like メッセージで応答する。HTTP と MIME の関係は付録 19.4 に記述されている。
ほとんどの HTTP 接続はユーザエージェントによって開始され、オリジンサーバ上のリソースに適用するリクエストで成り立つ。最も簡単な場合、ユーザエージェント (User Agent) とオリジンサーバ (Origin Server) との間の単一接続経由で成し遂げられるだろう。
より複雑な状況は一つ以上の仲介者がリクエスト/レスポンス連鎖に現れるときに起こる。三つの一般的な仲介者: プロキシ、ゲートウェイそしてトンネルが存在する。プロキシは絶対形式の URI のリクエストを受け取り、メッセージのすべてもしくは一部を書き換え、URI によって識別されるサーバに再フォーマットされたリクエストを転送するエージェントである。ゲートウェイはある別のサーバ (複数かもしれない) の上の層として動作し、もし必要ならリクエストを末端サーバのプロトコルに変換する受信エージェントである。トンネルはメッセージを変更する事なく二つの接続間の中継点として動作する。トンネルは通信が (ファイアウォールのような) 仲介者を通して伝えられる必要があるときや、仲介者がメッセージの内容を理解できないときに使用される。
上記の図はユーザエージェントとオリジンサーバの間の三つの仲介者 (A, B, C) を表している。連鎖全体を移動するリクエストやレスポンスメッセージは四つに分割された接続を通して渡される。いくつかの HTTP 通信オプションは (非トンネルの) 隣接にのみ、連鎖の端末点にのみ、そして連鎖上のすべての接続に適用できるため、この区別は重要である。ダイアグラムは線形であるがそれぞれの当事者は複数同時通信を行う事ができる。たとえば、B は A のリクエストを処理すると同時に、 A 以外のたくさんのクライアントからリクエストを受信しているかもしれないし、C 以外のサーバにリクエストを転送しているかもしれない。
トンネルとして動作していない通信のすべての当事者は内部的なキャッシュやリクエスト処理を使用できる。もし連鎖上の当事者の一つがそのリクエストに適用できるキャッシュされたレスポンスを持っているなら、キャッシュはリクエスト/レスポンス連鎖を短くするの効果をもつ。もし B が Origin Server から C を経由して来た、以前の (User Agent や A にキャッシュされていない) レスポンスのキャッシュコピーを持っているなら、以下はその結果となる連鎖を説明している。
すべてのレスポンスが有効にキャッシュ可能というわけではなく、いくつかのリクエストはキャッシュの動作に特別な要求を行う修飾子を含む事ができる。キャッシュの動作やキャッシュ可能なレスポンスに対する HTTP の要求は 13 章で定義されている。
事実、現在 World Wide Web 上で実験されて配置されているキャッシュとプロキシのアーキテクチャやコンフィギュレーションは幅広い多様性を持つ。これらのシステムは国際通信でバンド幅を節約するためのプロキシキャッシュの国際間階層や、キャッシュエンティティのブロードキャスト・マルチキャストを行うシステム、キャッシュされたデータのサブセットを CD-ROM で配布する組織などを含んでいる。HTTP システムは高バンド幅通信の社内イントラネット上で、そして非力なラジオ通信や断続的な接続を使う PDA 経由のアクセスで使用される。HTTP/1.1 の目的は、高い信頼性と、通信に失敗するなら少なくとも失敗の確実な指示が必要となるウェブアプリケーションを構築する人々のニーズに合うプロトコル構造を導入する事であるが、同時に既に設置されている構成の広い多様性をサポートする事でもある。
HTTP 通信は常に TCP/IP 接続上で行う。デフォルトポートは TCP 80 であるが、他のポートを使用する事もできる。これは HTTP がインターネットや他のネットワーク上で別のプロトコルの最上部として実装されるのを妨害しない。HTTP は確実な転送のみを前提とする。そのような保証を供給するどんなプロトコルでも使用できる。この問題でプロトコルのデータ転送単位の HTTP/1.1 リクエストとレスポンスのマッピングはこの仕様書の範囲外である。
HTTP/1.0 において、ほとんどのインプリメンテーションは個々のリクエスト/レスポンス交換のために新しい接続を使用していた。HTTP/1.1 では、接続を一つ以上のリクエスト/レスポンス交換に使用できるが、レスポンスの種類によっては接続がクローズされるかもしれない (8.1 章参照)。
2 表記法的慣習と一般文法
2.1 拡張 BNF
このドキュメントにおいて詳述されるメカニズムのすべては、単調 Backus-Naur Form (BNF) と RFC 822 [9] で使用されているもとの類似した拡張 BNF の両方で記述されている。実装者はこの仕様書を理解するためこの表記法に精通している必要がある。拡張 BNF は以下の構造を追加している。
- name = definition
- ルールの name は ("<" と ">" で囲んであるものを除いて) 単純にそれ自身の名前であり、その定義を等号 "=" 文字によって分割している。空白は一つ以上の行に及ぶルール定義を示すために使用される連続行の指示においてのみ意味を持つ。特定の基本ルールは 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
- 要素に先行する "*" 文字は繰り返しを意味する。完全な形式は element の最低 <n>、最大 <m> の存在を示している "<n>*<m>element" である。デフォルト値は 0 と無限であり、"*(element)" はゼロを含むどんな回数も可能である。"1*element" は最低一つ、"1*2element" は一つか二つが可能である。
- [rule]
- 角括弧は省略可能な要素を囲む。"[foo baf]" は "*1(foo bar)" と等しい。
- N rule
- 具体的な繰り返し: "<n>(element)" は "<n>*<n>(element)" と等しい。これは、(element) が正確に <n> 存在する。従って 2DIGIT は二つの数字であり、3ALPHA は三つのアルファベット文字の文字列である。
- #rule
- "*" と類似した "#" 構造は要素のリストを定義するために定義されている。完全な形式は element 最低 <n>、最大 <m> の存在を示している "<n>#<m>element" であり、それぞれは一つ以上のコンマ (",") と省略可能な連続空白 (LWS) で区切られる。これは普通とても簡単にリストのフォームを作る。"( *LWS element *(LWS "," *LWS element))" のルールは "1#element" として表す事ができる。この構造が使用されているどこでも、null 要素が許されるが、与えられた要素の数に影響しない。"(element), , (element)" は許されるが、二つの要素として数えられる。それゆえ、最低一つの要素が必要とされるところでは最低一つの null でない要素が与えられなければならない。デフォルト値は 0 と無限である。"#element" はゼロを含むどんな数も認め、"1#element" は最低一つを必要とし、"1#2element" は一つか二つを認めている。
- ; comment
- ルールテキストの右からある距離を置いて始まるセミコロンは、行末まで続くコメントを開始している。これはこの仕様書で平行した有用な記述を加えるための簡単な方法である。
- implied *LWS
- この仕様書によって記述される文法は word-based である。別の方法で明記していなければ、連続した空白 (LWS) はフィールドの解釈を変更しないで二つの隣接した言葉 (トークンや quoted-string) の間や隣接したトークンとデリミタ (tspecials) の間に追加する事ができる。二つのトークンの間にはそれらが単一のトークンとして解釈されないように最低一つのデリミタ (tspecials) が存在しなければならない。
2.2 基本ルール
以下のルールは基本的な構造説明を記述するためこの仕様書全体に渡って使用されている。文字セットとしてコード化された US-ASCII は ANSI X3.4-1986[12] で定義されている。
OCTET = <データの 8-bit シーケンスすべて> CHAR = <すべての US-ASCII 文字 (8 ビットバイト 0 - 127)> UPALPHA = <すべての US-ASCII 大文字 "A".."Z"> LOALPHA = <すべての US-ASCII 小文字 "a".."z"> ALPHA = UPALPHA | LOALPHA DIGIT = <すべての US-ASCII 数字 "0".."9"> CTL = <すべての US-ASCII 制御文字 (8 ビットバイト 0 - 31) と DEL (127)> CR = <US-ASCII CR, キャリッジリターン (13)> LF = <US-ASCII LF, ラインフィード (10)> SP = <US-ASCII SP, スペース (32)> HT = <US-ASCII HT, 水平タブ (9)> <"> = <US-ASCII ダブルクォート記号 (34)>HTTP/1.1 はエンティティボディ以外のすべてのプロトコル要素に対する行末として CR LF シーケンスを定義している (耐性のあるアプリケーションのための付録 19.3 章参照)。エンティティボディ内の行末マーカーは 3.7 章で記述されているように、その関連するメディアタイプによって定義される。
CRLF = CR LFHTTP/1.1 ヘッダは続く行が空白か水平タブで開始しているなら複数行にまたがって折り返す事ができる。折り返しているものを含むすべての連続空白は SP と同じ意味を持つ。
LWS = [CRLF] 1*( SP | HT )TEXT ルールはメッセージパーサーによって解釈されるのを目的とする説明的なフィールドの内容と値にのみ使用される。*TEXT の言葉は、RFC 1522 [14] のルールにしたがってエンコードされたときのみ、ISO-8859-1 [22] 以外の文字セットの文字を含む事ができる。
TEXT = <CTL 以外で LWS を含むすべての OCTET>16 進数文字はいくつかのプロトコル要素において使用される。
HEX = "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT多くの HTTP/1.1 ヘッダフィールド値は LWS か特別な文字によって区切られた言葉から成り立つ。これらの特別な文字がパラメータ値内で使用されるためには引用された文字列内に存在しなければならない。
token = 1*<CTL や tspecial を除くすべての CHAR> tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HTコメントは、いくつかの HTTP ヘッダ内でコメント文字を括弧で囲む事により加える事ができる。コメントは、それらのフィールド値定義の一部として "comment" を含んでいるフィールドにおいてのみ許される。その他のすべてのフィールドにおいては、括弧はフィールド値の一部とみなされる。
comment = "(" *( ctext | comment ) ")" ctext = <"(" と ")" を含むすべての TEXT>テキストの文字列はダブルクォート記号を使って引用されているなら、単一の言葉として解析される。
quoted-string = ( <"> *(qdtext) <"> ) qdtext = < <"> 以外のすべての TEXT>バックスラッシュ文字 ("\") は quoted-string と comment 構造内でのみ単一文字引用メカニズムとして使用されるだろう。
quoted-pair = "\" CHAR
3 プロトコルパラメータ
3.1 HTTP バージョン
HTTP はプロトコルのバージョンを含むる "<major>.<minor>" 番号スキームを使用する。プロトコルのバージョン付け処理は、この転送を使って得られる機構というよりも、サーバに対してメッセージのフォーマットを示したり、今後の HTTP 転送を理解する為の能力を表す。転送動作に影響を及ぼさなかったり、拡張可能なフィールド値を追加するだけのメッセージ構成要素の追加に対して、バージョン番号のどんな変更も行われない。<minor> 番号はプロトコルによってなされる変更が一般的なメッセージ解析アルゴリズムを変更しない機能を追加するときに増やされるが、これはメッセージセマンティクスを追加し、送り側の追加的な性能を暗黙的に意味するだろう。<major> 番号はプロトコル内のメッセージのフォーマットが変更されるときに増やされる。
HTTP メッセージのバージョンはメッセージの最初の行の HTTP-Version フィールドで示される。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGITメジャー番号とマイナー番号は分割した整数値として扱われるべきであり、一文字以上に増やされる事に注意する。従って、HTTP/12.3 よりも順序的に下となる HTTP/2.4 は HTTP/2.13 よりも下のバージョンである。先行するゼロは受け取り側によって無視されなければならず、送られてはならない。
この仕様書により定義されるような Request や Response メッセージを送るアプリケーションは "HTTP/1.1" の HTTP-Version を含まなければならない。このバージョン番号の使用は送り側のアプリケーションが少なくとも条件付きでこの仕様書に準じていると言う事を示す。
アプリケーションの HTTP バージョンはアプリケーションが少なくとも条件付きで準じている最も高い HTTP バージョンである。
プロキシとゲートウェイアプリケーションはプロトコル上で転送するバージョンの違うメッセージに注意しなければならない。プロトコルバージョンは送り側のプロトコル機能を示すため、プロキシ/ゲートウェイは決して実際のバージョンよりも大きなバージョン指標が付いたメッセージを送ってはならない。もしより高いバージョンのリクエストを受けたなら、エラーを返すか、トンネル動作にスイッチする。そのプロキシ/ゲートウェイのバージョンよりも低いバージョンのリクエストは転送される前にアップグレードできる。そのリクエストのプロキシ/ゲートウェイのレスポンスはリクエストと同じメジャーバージョンでなければならない。
注意: HTTP のバージョン間の変換は含まれるバージョンによって要求されるか禁止されているヘッダフィールドの修正を含んでいる。
3.2 Uniform Resource Identifiers
URI は多くの名前: WWW address, Universal Document Identifier, Universal Resource Identifier 最終的には Universal Resource Locator(URL) と Name(URN) で既に知られている。HTTP が関心を持たれる限り、Uniform Resource Identifier は
名前、ロケーションやその他の特徴で
3.2.1 一般構文
HTTP における URI は、絶対形式か当事者たちが置かれている状況に依存する幾つかの既知 URI の相対形式で表される。二つの形式は絶対形式の URI が常にコロンを後に持つスキーム名で開始しているという事実により区別される。
URI = ( absoluteURI | relativeURI ) [ "#" fragment ] absoluteURI = scheme ":" *( uchar | reserved ) relativeURI = net_path | abs_path | rel_path net_path = "//" net_loc [ abs_path ] abs_path = "/" rel_path rel_path = [ path ] [ ";" params ] [ "?" query ] path = fsegment *( "/" segment ) fsegment = 1*pchar segment = *pchar params = param *( ";" param ) param = *( pchar | "/" ) scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." ) net_loc = *( pchar | ";" | "?" ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | ":" | "@" | "&" | "=" | "+" uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national escape = "%" HEX HEX reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" extra = "!" | "*" | "'" | "(" | ")" | "," safe = "$" | "-" | "_" | "." unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">" national = <ALPHA, DIGIT, reserved, extra, safe, unsafeany を除くすべての OCTET>URL 構文や意味の定義的な情報は RFC 1738 [4] と RFC 1808 参照。HTTP サーバはアドレスの rel_path 部分を表す事のできる予約されていない文字セットにおいて制限されていないし、HTTP プロキシは RFC 1738 で定義されていない URI のリクエストを受信できるかもしれないため、この上記の BNF は RFC 1738 のよって示されているような正当な URLに入る事を許されていない国際文字を含む。
HTTP プロトコルは URI の優先的な長さに関してどんな制限も設けていない。サーバは当事者たちが送付してくるどんなリソースの URI も処理できなければならなず、もしそのような URI を生成する GET ベースのフォームを用意するなら、無制限の長さの URI を処理できるべきである。もし URI がサーバが処理できる限界 (10.4.15 章参照) よりも長いなら 414 (Request-URI Too Long) ステータスを返すべきである。
注意: サーバは古いクライアントやプロキシ実装が 255 バイトを超える長さを適切にサポートしていないかもしれないため、そのような長さの URI への依存に関して注意すべきである。3.2.2 http URL
"http" スキームは HTTP プロトコル経由でネットワークリソースの位置を定めるために使用される。このセクションでは http URL に対するスキーム記述構文とセマンティクスを定義している。
http_URL = "http:" "//" host [ ":" port ] [ abs_path ] host = <A legal Internet host domain name or IP address (in dotted-decimal form), as defined by Section 2.1 of RFC 1123> port = *DIGITもし port が空であったり省略されていれば、ポート 80 が仮定される。そのセマンティクスは、識別するリソースがそのホストのそのポートで TCP 接続のための接続待ちをしているサーバの場所を特定し、リソースに対する Request-URI は abs_path である。可能であれば URI での IP アドレスの使用は避るべきである (RFC 1900 [24] 参照)。もし abs_path が URI で与えられなければ、リソースに対する Request-URI として使われるとき "/" として与えられなければならない (5.1.2 章)。
3.2.3 URI の比較
もし二つの URI が一致しているかどうかを判別するためそれらを比較するなら、クライアントは以下を例外として URI 全体の大文字と小文字を区別した 8 ビットバイト同士を比較すべきである:
- 与えられた空やそうでない部分がその URI のデフォルト部分と等価である。
- ホスト名の比較は大文字小文字を区別してはならない。
- スキーム名の比較は大文字と小文字を区別してはならない。
- 空の abs_path は "/" の abs_path と等価である。
これら以外の "予約された" もしくは "危険な" セット (3.2 章参照) 文字はそれらの ""%" HEX HEX" エンコーディングと等しい。
たとえば、以下の三つの URI は等価である:
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
3.3 日付/時刻フォーマット
3.3.1 完全な日付
HTTP アプリケーションは歴史的に日付/時刻スタンプの表現のため三つの異なるフォーマットを認めている。
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, RFC 1123 で改定された Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, RFC 1036 により時代遅れ Sun Nov 6 08:49:37 1994 ; ANSI C の asctime() フォーマット最初のフォーマットはインターネット標準としてより好まれ、RFC 1123 (RFC822 の改定) で定義されている物の固定長サブセットに相当する。第二のフォーマットは一般的に使用されているが、時代遅れの RFC 850 [12] 日付フォーマットをベースにし、4 桁年号が欠落している。日付の値を解析する HTTP/1.1 クライアントとサーバは (HTTP/1.0 との互換性のため) 三つすべてのフォーマットを受け入れなければならないが、それらがヘッダフィールドで HTTP-date 値を表す時には RFC 1123 フォーマットのみを使用しなければならない。
注意: 日付の値の受取側は、しばしば SMTP や NNTP のプロキシ/ゲートウェイを経由して受送信されたメッセージを考慮して、非 HTTP アプリケーションによって送られるであろう日付の値を受け入れるような強固さを持つ事が推奨される。すべての HTTP 日付/時刻スタンプは例外を除いてグリニッジ標準時刻 (GMT)で表されなければならない。これはタイムゾーンに対する三文字略として"GMT" の包括によって最初の二つのフォーマットで示され、asctime フォーマットの解釈のときに仮定されなければならない。
HTTP-date = rfc1123-date | rfc850-date | asctime-date rfc1123-date = wkday "," SP date1 SP time SP "GMT" rfc850-date = weekday "," SP date2 SP time SP "GMT" asctime-date = wkday SP date3 SP time SP 4DIGIT date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) date2 = 2DIGIT "-" month "-" 2DIGIT ; day-month-year (e.g., 02-Jun-82) date3 = month SP ( 2DIGIT | ( SP 1DIGIT )) ; month day (e.g., Jun 2) time = 2DIGIT ":" 2DIGIT ":" 2DIGIT ; 00:00:00 - 23:59:59 wkday = "Mon" | "Tue" | "Wed" | "Thu" | "Fri" | "Sat" | "Sun" weekday = "Monday" | "Tuesday" | "Wednesday" | "Thursday" | "Friday" | "Saturday" | "Sunday" month = "Jan" | "Feb" | "Mar" | "Apr" | "May" | "Jun" | "Jul" | "Aug" | "Sep" | "Oct" | "Nov" | "Dec"注意: HTTP で要求される日付/時刻スタンプフォーマットはプロトコルストリーム内でのそれらの使用にのみ適用される。クライアントとサーバはユーザへの提示や、ログイン要求などに対してこれらのフォーマットを使用する必要はない。3.3.2 秒差
幾つかの HTTP ヘッダフィールドはメッセージが受信された時刻後の 10 進数で表される秒の整数として記述される時間値を認めている。
delta-seconds = 1*DIGIT
3.4 文字セット
HTTP は MIME のために表されているような "文字セット" 用語と同じ定義を使用する:
"文字セット" 用語はこのドキュメントで 8 ビットバイトシーケンスを文字シーケンスに変換するための一つ以上のテーブルで使用される方法を提示するために使用されている。すべての文字が与えられた文字セットで利用できるわけではなかったり、固有の文字を表すため文字セットが一つ以上の 8 ビットバイトシーケンスを供給する場合において、別の指示で無条件な変換が必要でない事に注意。この定義は US-ASCII のような簡単な単一テーブルマッピングから、ISO 2022 の技術を使うような複雑なテーブルをスイッチする方法まで、さまざまな種類の文字エンコーディングを認める目的を持つ。しかしながら、MIME 文字セット名に関連したこの定義は 8 ビットバイトから文字に行われるマッピングを完全に詳述しなければならない。特に、正確なマッピングを決定するための外部のプロフィール情報の使用は許されない。注意: この "文字セット" 用語の使用は "文字エンコーディング" としてより一般的に参照されている。しかしながら、HTTP と MIME が同じ登録を共有しているため、用語も共有される事が大切である。HTTP 文字セットは大文字と小文字を区別しないトークンによって識別される。トークンの完全セットは IANA Character Set 登録機構 [19] によって定義される。
charset = tokenとはいえ、HTTP は文字値として使用される任意のトークンを認めている。IANA Character Set 登録機構によって定義済みの値を持つどんなトークンもその登録機構で定義された文字セットを表さなければならない。アプリケーションは文字セットのそれらの使用に IANA 登録機構により定義されたこれらを制限すべきである。
3.5 内容コーディング
内容コーディング値はエンティティに適用されているもしくは適用できるエンコーディング変換を示す。内容コーディングは、その根本的なメディアタイプのアイデンティティを失ったり情報の欠落がおこなわれないで、圧縮されたり別の有用な変換が行われたドキュメントを許可するために使用される。しばしば、エンティティはコード化された形態で保存され、直接転送され、受け取り側によってのみデコードされる。
content-coding = tokenすべての content-coding 値は大文字と小文字を区別しない。HTTP/1.1 は Accept-Encoding (14.3 章) と Content-Encoding (14.12 章) ヘッダフィールドにおいて content-coding 値を使用する。値が content-coding で表されるとはいえ、より重要な事はデコーディングメカニズムがエンコーディングを取り除く必要があるだろうという事を示す事である。
Internet Assigned Numbers Authority (IANA) は content-coding 値トークンに対する登録機構を代行している。初めに、登録機構は以下のトークンを含んでいる:
- gzip
- RFC 1952 [25] に示されているファイル圧縮プログラム "gzip" (GNU zip) により作られるエンコーディングフォーマット。このフォーマットは 32 bit CRC 付きの Lempel-Ziv コーディング (LZ77) である。
- compress
- 一般的な UNIX ファイル圧縮プログラム "compress" で作られるエンコーディングフォーマット。このフォーマットは Lempel-Ziv-Welch コーディング (LZW) に適合している。
注意: エンコーディングフォーマットの確認のためのプログラム名の使用は望ましくなく、将来的なエンコーディングを妨害する。ここでのこれらの使用は歴史的な慣例の代表であり、良いデザインではない。HTTP の以前のインプリメンテーションへの互換性のため、アプリケーションは "x-gzip" と "x-compress" をそれぞれ "gzip" と "compress" に等価であるとみなすべきである。
- deflate
- RFC 1951 [29] で記述される "deflate" 圧縮メカニズムと結合した、RFC 1950 [31] で定義されている "zlib" フォーマット。
新しい conetnt-coding 値トークンが登録されるべきである。クライアントとサーバの間での内部操作性を認めるため、新しい値を実装する必要のある内容コーディングアルゴリズムの仕様は公的に利用でき独立したインプリメンテーションに適し、この章で定義された内容コーディングの目的に従うべきである。
3.6 転送コーディング
転送コーディング値はネットワークを通して "安全な転送" を保証するためエンティティボディに適用されている、される事のできる、する必要のあるエンコーディング変換を示す。これは転送コーディングが元のエンティティではなくメッセージの特性である内容エンコーディングとは異なる。
transfer-coding = "chunked" | transfer-extension transfer-extension = tokenすべての transfer-encoding 値は大文字小文字を区別しない。HTTP/1.1 は Transfer-Encoding ヘッダフィールド (14.40 章) で転送コーディング値を使用している。
転送エンコーディングは MIME の Content-Transfer-Encoding 値と類似している。これは 7-bit 転送サービス上でバイナリデータの安全な転送を可能にするために設計されている。しかしながら、安全な転送の焦点は完全な 8 bit転送プロトコルに対して異なる。HTTP では、メッセージボディに特有の危険さは、明確なボディ長 (7.2.2 章) を決定する事が困難なことや、共有された転送経路上でデータの暗号化を望む事だけである。
chunked エンコーディングは、それぞれエンティティヘッダフィールドを含んでいるオプション的なフッタが続くそれ自身のサイズ指標をつけて、チャンクの連続としてそれを転送するためにメッセージのボディを修正する。これは、受取人が全メッセージを受信した事を確かめるための必要な情報とともに転送される動的に生成された内容を認めている。
Chunked-Body = *chunk "0" CRLF footer CRLF chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF hex-no-zero = <HEX excluding "0"> chunk-size = hex-no-zero *HEX chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] ) chunk-ext-name = token chunk-ext-val = token | quoted-string chunk-data = chunk-size(OCTET) footer = *entity-headerchunked エンコーディングはサイズがゼロにされたチャンクとそれに続くフッタにより終了する。これは空行によって終わる。フッタの目的は動的に生成されたエンティティに付いての情報を供給するための効果的な方法を備える事である。アプリケーションは、電子署名や別の機能のための Content-MD5 や HTTP の将来的な拡張のように、フッタに対して適切であるようなものとして明白に定義されていないフッタのヘッダフィールドを送ってはならない。
Chunked-Body デコーディングのための例題過程は付録 19.4.6 で紹介されている。
すべての HTTP/1.1 アプリケーションは "chunked" 転送コーディングを受信しデコードできなければならず、それらが理解できない転送コーディング拡張は無視されなければならない。理解できない transfer-coding 付きのエンティティボディを受信したサーバは 501 (Unimplemented) を返して接続を閉じるべきである。サーバは HTTP/1.0 クライアントに転送エンコーディングを送ってはならない。
3.7 メディアタイプ
HTTP は Content-Type (14.18 章) と Accept (14.1 章) ヘッダフィールドにおいてオープンや拡張データタイプ定義やタイプネゴシエーションを供給するために Internet Media Type を使用する。
media-type = type "/" subtype *( ";" parameter ) type = token subtype = tokenパラメータは attribute/value ペアの形態で タイプ/サブタイプ が続くであろう。
parameter = attribute "=" value attribute = token value = token | quoted-stringタイプ、サブタイプやパラメータ属性名は大文字と小文字を区別しない。パラメータ値はパラメータ名のセマンティクスに依存して大文字小文字の区別が行われるであろう。連続した空白文字 (LWS: Linear white space) はタイプとサブタイプの間や属性とその値の間で使われてはならない。メディアタイプを識別するユーザエージェントはユーザに検知したどんな問題も知らせるため、この type/subtype 定義により表されるような MIME タイプに対するパラメータを処理 (もしくはユーザエージェントによりこの type/subtype を処理するために使われるどんな外部アプリケーションにも処理されるように) しなければならない。
注意: 幾つかの古い HTTP アプリケーションはメディアタイプパラメータを認識しない。この時、古い HTTP アプリケーションにデータを送るため、インプリメンテーションはそれらがこの type/subtype 定義により要求されるときのみメディアタイプを使用すべきである。メディアタイプ値は Internete Assigned Number Authority (IANA) によって登録される。メディアタイプ登録手続きは RFC 2048 [17] において概説されている。登録されていないメディアタイプの使用は慎むべきである。
3.7.1 公式化とテキストデフォルト
インターネットメディアタイプは公式の形式で登録される。一般的には、HTTPメッセージ経由で転送されるエンティティボディはその転送に前述の適切な公式形式で表されなければならない。例外は次のパラグラフで定義されるような "text" タイプである。
公式形式において、"text" タイプのメディアサブタイプはテキスト行末に CRLF を使う。HTTP はこの要求をゆるめ、それがエンティティボディ全体に対して一貫ししているとき、行末を表すのに単独の CR や LF をつけたテキストメディアの転送を認めている。HTTP アプリケーションは HTTP 経由で受信されるテキストメディアにおいて行末表現であるものとして CRLF, CR や LF を受け入れなければならない。追加として、もしテキストが、幾つかのマルチバイト文字セットに対する場合であるように、CR と LF それぞれに対して8 ビット文字 13 と 10 が使われていないような文字セットに相当するならば、HTTP は行末の CR と LF の評価を表すためのこの文字セットによって定義されているどんな 8 ビット文字の使用をも認める。行末に関するこの柔軟性はエンティティボディのテキストメディアにのみ適用される。単独の CR や LF は HTTP 制御構造 (ヘッダフィールドやマルチパート境界など) のすべてにおいて CRLF に置き換えられてはならない。
もしあるエンティティボディが Content-Encoding でエンコードされているならば、根本的なデータはエンコードされるために上記で定義される形態とならなければならない。
"charset" パラメータはデータの文字セット (3.4 章) を定義するための、幾つかのメディアタイプで使用されている。明確な charset パラメータが送り側から供給されない場合、"text" タイプのメディアサブタイプは HTTP 経由でそれが受信されるときデフォルトの "ISO-8859-1" の charset 値を持つと定義される。"ISO-8859-1" やそのサブセット以外の文字セットにおけるデータは適切な charset 値付きでラベル付けされなければならない。
幾つかの HTTP/1.0 ソフトウェアは charset パラメータを使っていない Content-type ヘッダを "受取人が推測する" を意味するものとして間違って中間処理している。この振る舞いを無効にする事を望む送り側は charset が ISO-8859-1 であるような charset を含んでも良く、それが受取人を混乱させないであろうという事を知っている場合にはそのようにすべきである。
不幸にも、幾つかの古い HTTP/1.0 クライアントは明白な charset パラメータを適切に処理していない。HTTP/1.0 の受け取り側は送り側によって供給される charset ラベルを尊重しなければならない。そして charset を "推測する" 準備のあるユーザエージェントは、もしそれらがその charset をサポートしているならば、ドキュメントを最初に表示するときに受取人の好みよりも Content-Type フィールドからの charset を使わなければならない。
3.7.2 マルチパートタイプ
MIME は "multipart" タイプ
HTTP では、マルチパート body-parts はその部分の意味に重要な意義を持つヘッダフィールドを含むかもしれない。Content-Location ヘッダフィールド (14.15 章) は URL によって識別されうるそれぞれの同封されたエンティティの body-part において含まれるべきである。
一般的には、HTTP ユーザエージェントは MIME ユーザエージェントがマルチパートタイプの受領上でするであろうと同じまたは似たような振る舞いに習うべきである。アプリケーションが認識されないマルチパートサブタイプを受け取ったなら、アプリケーションはそれを "multipart/mixed" に相当するものとして扱わなければならない。
注意: "multipart/form-data" タイプは RFC 7867 [15] で表されるように特に POST リクエストメソッド経由で処理するのにふさわしいフォームデータを転送するために既に定義されている。
3.8 製品のトークン
製品のトークンはソフトウェアの名前とバージョンによってそれ自身を識別するアプリケーションと通信する事ができるように使用される。製品のトークンで使用されているほとんどのフィールドは空白で区切られたリストされるアプリケーションを意味する部分を構成している sub-product を認めている。習慣的に製品はアプリケーションを識別するためのそれらの重要性の順にリストされる。
product = token ["/" product-version] product-version = token例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 Server: Apache/0.8.4製品トークンは短く要点を成すべきである
3.9 優先値
HTTP 内容ネゴシエーション (12 章) はさまざまな交渉可能なパラメータの相対的な重要性 ("ウェイト") を示す短い "浮動小数点" 数を使う。ウェイトは実数値 0 から 1 までに標準化され、0 は最小値で 1 は最大値である。HTTP/1.1 アプリケーションは小数点以下の 3 つの数字以上を生成してはならない。これらの値のユーザ設定もこの様式にかぎられるべきである。
qvalue = ( "0" [ "." 0*3DIGIT ] ) | ( "1" [ "." 0*3("0") ] )"Quality value" はそれらの値が単に要請される特質の相対的な格付けを示すため誤称である。
3.10 言語タグ
言語タグは別の人間との情報コミュニケーションのため、人間によって話されたり書かれたり、別の方法で伝えられる自然言語を識別する。コンピュータ言語は明らかに除外される。HTTP は Accept-Language や Content-Language フィールドにおいて言語タグを使用する。第一の言語タグと空でも良いサブタグの連続である。
language-tag = primary-tag *( "-" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHAホワイトスペースはタグの中では認められず、すべてのタグは大文字と小文字を区別しない。言語タグの名前空間は IANA によって管理されている。例として以下を含むタグがある:
en, en-US, en-cockney, i-cherokee, x-pig-latinここでどんな二文字の第一タグも ISO 639 言語短縮系であり、サブタグの初めにつけられるどんな二文字も ISO 3166 国コードである。(上記最後の 3 タグは登録されていないタグである; しかし最後のすべては将来的に登録されるかもしれないタグの例である。)
3.11 エンティティタグ
エンティティタグは要求された同じリソースからの二つ以上のエンティティを比較するために使用される。HTTP/1.0 は ETag (14.20 章)、If-Match (14.25章)、If-None-Match (14.26 章)、及び If-Range (14.27 章) ヘッダフィールドでエンティティタグを使用する。それらがどのよう使われ、キャッシュが正しいと確認するものとして比較されるかの定義は 13.3.3 章で成される。エンティティタグはひょっとすると weakness インジケータが前方に付く、非空白の引用文字列とみなされるかもしれない。
entity-tag = [ weak ] opaque-tag weak = "W/" opaque-tag = quoted-string"string entity tag" はもしそれらが 8 ビット文字と等価とみなされるときのみリソースの 2 つのエンティティによって分けられるであろう。
"W/" プレフィクスによって示される "weak entity tag" はエンティティが等価でありセマンティクスにおいてそれぞれ重要な変更がないそれぞれを用いる事ができるときのみ、リソースの 2 つのエンティティによって分けられる。weak エンティティタグは不十分な比較に対してのみ使用される。
エンティティタグは特有のリソースと結び付けられたすべてのエンティティのすべてのバージョンを超えてユニークでなければならない。与えられたエンティティタグの値はそれらのエンティティの等価性に付いてすべてを暗に意味することなしに異なる URI での要求によって得られるエンティティに対して使用されうる。
3.12 レンジユニット
HTTP/1.1 はクライアントに、レスポンス内に含まれるレスポンスエンティティの (範囲の) 一部だけリクエストする事を可能にしている。HTTP/1.1 は Range (14.36 章) と Content-Range (14.17 章) においてレンジユニットを使用する。エンティティはさまざまな構造上のユニットにしたがったサブレンジのなかで分解されるだろう。
range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = tokenHTTP/1.1 で定義されている唯一のレンジユニットは "bytes" である。HTTP/1.1 インプリメンテーションは別のユニットを使用して述べられたレンジを無視するだろう。HTTP/1.1 はレンジに付いての知識に依存しないようなアプリケーションのインプリメンテーションを認めるように設計されている。
4 HTTP メッセージ
4.1 メッセージタイプ
HTTP メッセージはクライアントからサーバへの要求とサーバからクライアントへの応答で成り立つ。
HTTP-message = Request | Response ; HTTP/1.1 messages要求 (5 章) と応答 (6 章) メッセージはエンティティ転送 (メッセージの負担荷重) のため RFC 822 [9] の一般的なメッセージフォーマットを使用する。メッセージの両方のタイプは一つの開始行、一つ以上のヘッダフィールド(ヘッダとしても知られる)、ヘッダフィールドの終了を示す (CRLF の前に何もない行のような) 空行、そして任意のメッセージボディからなる。
generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line | Status-Line強固の重要性において、サーバは Request-Line が期待される所においてすべての受け取った空行も無視すべきである。言いかえれば、もしサーバがメッセージの開始におけるプロトコルストリームで読み出しを行って、最初に CRLF を受信したなら、その CRLF は無視すべきである。
注意: あるバグを持った HTTP/1.0 クライアントインプリメンテーションは POST リクエストの後に余分な CRLF を生成する。BNF によって明らかに禁止される事を再度述べると、HTTP/1.1 クライアントは余分な CRLF が先行する要求を行ってはならない。
4.2 メッセージヘッダ
一般ヘッダ (4.5 章)、レスポンスヘッダ (6.2 章)、及びエンティティヘッダ(7.1 章) を含む HTTP ヘッダフィールドは RFC 822 [9] の 3.1 章で与えられているもとの同じ一般的なフォーマットに従う。それぞれのヘッダフィールドはコロン (":") が後に続く名前とフィールド値から成る。フィールド名は大文字と小文字を区別しない。フィールド値は、一つの SP が好まれるが、幾つかの LWS を先頭に付ける事もできる。ヘッダフィールドは最低一つ以上のSP や HT をそれぞれの行頭につける事で複数行にまたがる事ができる。アプリケーションは、共通形式を超えたあらゆるものの受け入れに失敗する幾つかのインプリメンテーションが存在するであろうため、HTTP 構造を生成するとき "共通形式" に従うべきである。
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>異なるフィールド名を持つヘッダフィールドの受信される順序は重要性を持たない。しかしながら、リクエストヘッダやレスポンスヘッダに先立って一般ヘッダフィールドを最初に送りエンティティフィールドを最後にする事が "良い慣例" である。
同じフィールド名を持つ複合メッセージヘッダフィールドは、そのようなヘッダフィールドに対するエンティティフィールド値がコンマで区切られたリスト[#(value) のような] として定義される場合、かつその場合にのみ、メッセージに存在しうる。コンマによってそれぞれ分けられるそれぞれの続く field-value を最初に追加する事により、メッセージのセマンティクスを変える事無しにある "header-name: header-value" ペアでの複合ヘッダフィールドを結合する事が可能でなければならない。それゆえ同じフィールド名を持つヘッダフィールドが受信される順番は、連結されたフィールド値の中間処理に重要であり、したがってプロキシはメッセージが転送されるときにそれらのヘッダ値の順番を変えてはならない。
4.3 メッセージボディ
HTTP メッセージの message-body はリクエストやレスポンスに関連するentity-body を運ぶために使用される。message-body は Transfer-Encodingヘッダフィールド (14.40 章) によって示された転送コーディングが適用されたときのみ entity-body とは異なる。
message-body = entity-body | <entity-body encoded as per Transfer-Encoding>Transfer-Encoding はアプリケーションにより安全を保障しメッセージのふさわしい転送を行うために適用されるすべての転送コーディングを示すために使用される。Transfer-Encoding はそのメッセージの性質であり、エンティティの性質ではない。したがってそれはリクエスト/レスポンス連鎖に伴うすべてのアプリケーションによって追加されたり削除されたりされうる。
message-body がメッセージにおいてみとめられるようなルールはリクエストとレスポンスの違いではない。
リクエストにおける message-body の存在はリクエストの message-headerでの Content-Length や Transfer-Encoding ヘッダフィールドの抱合によって伝えられる。message-body はリクエストメソッド (5.1.1 章) がentity-body を許可しているときのみリクエストに含まれるであろう。
レスポンスメッセージに対して、message-body がメッセージに含まれているかどうかはリクエストメソッドとレスポンスステータスコード (6.1.1 章) の両方に依存する。HEAD リクエストメソッドのどんなレスポンスも、たとえentity-header フィールドがそうであるように導いていたとしても、message-body を含んではならない。1xx (Information)、204 (no content)、及び304 (not modified) レスポンスのどれも message-body を含んではならない。他のすべてのレスポンスは長さがゼロである以外は message-bodyを含む。
4.4 メッセージの長さ
message-body がメッセージに含まれるとき、このボディの長さは以下の一つで決定される。
- message-body を含んではいけない (1xx, 204, 304 レスポンスや HEAD リクエストに対するすべてのレスポンス) すべてのレスポンスメッセージは entity-header フィールドがメッセージにおいて与えられるてもヘッダフィールドの後の最初の空行で常に終了する。
- もし Transfer-Encoding ヘッダフィールド (14.40 章) が与えられ、"chunked" 転送コーディングが適用されているようならば、長さは chunked エンコーディング (3.6 章) によって定義される。
- もし Content-Length ヘッダフィールド (14.14 章) が与えられるなら、そのバイト値は message-body の長さを示す。
- もしメッセージが自身で区切りを持つメディアタイプ "multipart/byteranges" を使うなら、これはその長さを定義する。このメディアタイプは、受取人が それを解析できる事を送り側が知っている事無しに使用されてはならない。リクエストにおけるマルチバイト幅指定子付きの Range ヘッダの存在は、クライアントが multipart/byterange レスポンスを解析できる事を暗黙的に意味する。
- 接続を閉じるサーバによる。(接続を閉じる事はリクエストボディの終了を使用するために使う事ができない。これはサーバがレスポンスを送り返す可能性がないであろう為である。)
HTTP/1.0 アプリケーションの互換性のため、message-body を含む HTTP/1.1リクエストは、サーバが HTTP/1.1 に準じていると分かっている場合を除いて有効な Content-Length ヘッダフィールドをを含まなければならない。もしmessage-body と Content-Length を含んでいるリクエストが与えられなければ、サーバはメッセージの長さが決定できないとき 400 (bad request) や有効な Content-Length を受信する事を要求するなら 411 (length required)を返すべきである。
エンティティを受け取るすべての HTTP/1.1 アプリケーションは "chunked"転送エンコーディング (3.6 章) を受け入れなければ成らず、したがってメッセージ長が前もって決定されていないときメッセージに対して使用されるこのメカニズムを認めなければならない。
メッセージは Content-Length ヘッダフィールドと "chunked" 転送エンコーディングの両方を含んではならない。もし両方が受信されたら、Content-Length が無視されなければならない。
Content-Length が、message-body が認められるメッセージにおいて与えられたとき、そのフィールド値は message-body における 8 ビット文字の数と正確に一致しなければならない。HTTP/1.1 ユーザエージェントは不正な長さが受信されたり検出されたとき通知しなければならない。
4.5 一般ヘッダフィールド
リクエストとレスポンスメッセージの両方のための一般的な適用性を持つ幾つかのヘッダフィールドがあるが、これは転送されたエンティティには適用されない。これらのヘッダフィールドは伝えられているメッセージに対してのみ適用される。
general-header = Cache-Control ; Section 14.9 | Connection ; Section 14.10 | Date ; Section 14.19 | Pragma ; Section 14.32 | Transfer-Encoding ; Section 14.40 | Upgrade ; Section 14.41 | Via ; Section 14.44一般ヘッダフィールド名はプロトコルバージョンにおける変換に伴う連動においてのみ確実に拡張される事ができる。しかしながら、新しいヘッダフィールドや実験的なヘッダフィールドは、もしコミュニケーションにおけるすべてのパーティがそれらを一般ヘッダフィールドであると認識できるなら、一般的なヘッダフィールドのセマンティクスが与えられるであろう。認識されないヘッダフィールドは entity-header フィールドとして扱われる。
5 リクエスト
メッセージの最初の行内のクライアントからサーバへのリクエストメッセージはリソースに適用されるメソッド、リソースの識別子、使用されているプロトコルのバージョンを含んでいる。
Request = Request-Line ; Section 5.1 *( general-header ; Section 4.5 | request-header ; Section 5.3 | entity-header ) ; Section 7.1 CRLF [ message-body ] ; Section 7.2
5.1 リクエスト行
Request-Line は Request-URI とプロトコルバージョンが後にく続メソッドトークンで開始し CRLF で終了する。最後の CRLF シーケンス以外の CR もLF もみとめられない。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF5.1.1 メソッド
Method トークンは Request-URI により識別されるリソースに行われるためのメソッドを示す。メソッドは大文字と小文字を区別する。
Method = "OPTIONS" ; Section 9.2 | "GET" ; Section 9.3 | "HEAD" ; Section 9.4 | "POST" ; Section 9.5 | "PUT" ; Section 9.6 | "DELETE" ; Section 9.7 | "TRACE" ; Section 9.8 | extension-method extension-method = tokenリソースにより認められるメソッドのリストは Allow ヘッダフィールド (14.7 章) で記述される。レスポンスのリターンコードは、許されるメソッドのセットが動的に変化できるため、メソッドが現在リソースに許されていてもいなくても常にクライアントに伝えられる。もしサーバがメソッドを理解できても要求されたリソースに対して許されていなければ、サーバはステータスコード 405 (Method Not Allowed) を返すべきであり、もしサーバがそのメソッドを認識できなかったり実装されていない場合には 501 (NotImplemented) を返すべきである。サーバが理解しているメソッドのリストは Public レスポンスヘッダフィールド (14.35 章) でリストされる。
GET と HEAD メソッドはすべての一般目的サーバによってサポートされなければならない。他のすべてのメソッドはオプションである。しかしながら、もし上記のメソッドがインプリメントされているなら、それらは 9 章で記述されているものと同じセマンティクスで実装されなければならない。
5.1.2 Request-URI
Request-URI は Uniform Resource Identifier (3.2 章) であり、リクエストを適用するリソースを識別する。
Request-URI = "*" | absoluteURI | abs_pathRequest-URI に対する 3 つのオプションはリクエストの性質に依存する。アスタリスク "*" はリクエストが特有のリソースではなくサーバ自身に適用する意味を持ち、使われているメソッドがリソースに適用される必要がないときにのみ許される。一つの例は以下のようになる。
OPTIONS * HTTP/1.1absoluteURI フォームはリクエストがプロキシにより生成されたものであるときに必要となる。プロキシは有効なキャッシュからリクエストやサービスの転送を要求され、レスポンスを返す。プロキシは別のプロキシや直接 absoluteURIによって示されたサーバにリクエストを転送する事ができる。リクエストのループを回避するため、一つのプロキシはエイリアス、ローカルバリエーション、数値での IP アドレスを含めてそのサーバ名のすべてのを認識できなければならない。Request-Line の例は以下のようになる:
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1HTTP の将来のバージョンにおけるすべてのリクエストの absoluteURI の移行を考慮して、もし HTTP/1.1 クライアントがプロキシへそれらをリクエストとしてのみ生成するであろうならば、すべての HTTP/1.1 サーバはリクエストにおける absoluteURI 形式を受け入れなければならない。
Request-URI のもっとも一般的な形式はオリジンサーバやゲートウェイ上のリソースを識別するために使用される事である。この場合 URI の絶対パスはRequest-URI として伝えられなければならなず (3.2.1 章, abs_path 参照)、URI のネットワークロケーション (net_loc) は Host ヘッダフィールドにおいて転送されなければならない。たとえば、上記のように元のサーバから直接回収する事を望むクライアントはホスト "www.w3.org" のポート 80 にTCP 接続を確立し、Request の残りが後に続く以下の行を送信する:
GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org絶対パスは空ではない事に注意。元の URI で何も与えられていなければ、"/"(サーバのルート) を与えなければならない。
プロキシが Request-URI においてどんなパスも持たないリクエストを受け取り、記述されたメソッドがリクエストのアスタリスク形式をサポートできるなら、リクエスト連鎖の最後のプロキシは最終的な Request-URI として "*" をつけたリクエストを転送しなければならない。たとえば、リクエスト
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1はプロキシによってホスト "www.ics.uci.edu" のポート 8001 に接続した後
OPTIONS * HTTP/1.1 Host: www.ics.uci.edu:8001を転送するであろう。
Request-URI は 3.2.1 章で記述されるフォーマットで伝えられる。オリジンサーバはリクエストを適切に解釈するためにその Request-URI をデコードしなければならない。サーバは不正な Request-URI に適切なステータスコードで答えるべきである。
転送されるリクエストにおいて、プロキシは上記の null abs_path を "*" に置き換える以外、プロキシがその内部的な実装で行うどんな事でも、Request-URI の "abs_path" を書き換えてはならない。
注意: オリジンサーバが予約された目的のための予約されていない URL 文字を不適当に使用しているとき、"書き換え禁止" ルールはプロキシがリクエストの意味を変えないようにする。実装者は既に幾つかの以前の HTTP/1.1 プロキシが Request-URI を書き換える事が知られていると言う事を知るべきである。
5.2 リクエストによるリソース識別
HTTP/1.1 オリジンサーバはインターネットリクエストにより識別された正確なリソースが Request-URI と Host ヘッダフィールドの両方で検査する事により決定されると言う事を知るべきである。
リソースにリクエストされたホストによって異なる事を認めていないオリジンサーバは Host ヘッダフィールド値を無視する事ができる。(ただしHTTP/1.1 での Host サポートの別の要求のため 19.5.1章参照。)
リクエストされたホストを元にしてリソースを区別する (しばしば仮想ホストや空虚なホスト名として参照される) オリジンサーバは HTTP/1.1 リクエストの要求されたリソースを決定するために以下のルールに従わなければならない:
- もし Request-URI が absoluteURI ならば、ホストは Request-URI の一部である。リクエストにおけるどんな Host ヘッダフィールド値も無視されなければならない。
- もし Request-URI が absoluteURI でなく、リクエストが Host ヘッダフィールドを含んでいるならば、ホストは Host ヘッダフィールド値によって決定される。
- もしルール 1 や 2 で決定されるようなホストがそのサーバで正当なホストでないならば、レスポンスは 400 (Bad Request) エラーメッセージでなければならない。
Host ヘッダフィールドの欠落した HTTP/1.0 リクエストの受け取り側はどんな正確なリソースが要求されているかを決定するため (特有のホストにユニークな何かに対する URI パスの試験のような) 発見的方法を使用する事を試みる事ができる。
5.3 リクエストヘッダフィールド
request-header フィールドはクライアントにリクエストやクライアント自身に関する追加的な情報をサーバに渡す事を可能にする。これらのフィールドはこれらはプログラミング言語のメソッド呪文と等価なセマンティクスを伴ってリクエスト修飾子として動作する。
request-header = Accept ; Section 14.1 | Accept-Charset ; Section 14.2 | Accept-Encoding ; Section 14.3 | Accept-Language ; Section 14.4 | Authorization ; Section 14.8 | From ; Section 14.22 | Host ; Section 14.23 | If-Modified-Since ; Section 14.24 | If-Match ; Section 14.25 | If-None-Match ; Section 14.26 | If-Range ; Section 14.27 | If-Unmodified-Since ; Section 14.28 | Max-Forwards ; Section 14.31 | Proxy-Authorization ; Section 14.34 | Range ; Section 14.36 | Referer ; Section 14.37 | User-Agent ; Section 14.42request-header フィールド名はこのプロトコルバージョンにおける変更の関連においてのみ正確に拡張する事ができる。しかしながら、もし通信においてすべてのパーティがそれらを request-header フィールドと認識するならば、新しいものや実験的なヘッダフィールドは request-header フィールドのセマンティクスが与えられる可能性がある。認識されないヘッダフィールドはentity-header フィールドとして扱われる。
6 レスポンス
リクエストメッセージを受信して解釈した後、サーバは HTTP レスポンスメッセージを返す。
Response = Status-Line ; Section 6.1 *( general-header ; Section 4.5 | response-header ; Section 6.2 | entity-header ) ; Section 7.1 CRLF [ message-body ] ; Section 7.2
6.1 Status-Line
Response メッセージの最初の行はステータスコード番号とそれに関連したテキストフレーズが後に続くプロトコルバージョンからなる Status-Line であり、それぞれの要素は SP 文字によって区切られる。最後の CRLF シーケンス以外ではどんな CR も LF もみとめられない。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF6.1.1 Status-Code と Result-Phrase
Status-Code 要素はリクエストを理解し満たした試みの 3 文字数字の結果コードである。これらのコードは 10 章ですべて定義されている。Response-Phrase は Status-Code の短いテキスト記述を与える目的を持つ。Status-Code は自動処理によって使う事を目的とし Reason-Phrase は人間のユーザのためである。クライアントは Reason-Phrase を調べたり表示したりする事を必要とされない。
Status-Code の最初の数字はレスポンスの分類である。最後の二つの数字はどんな分類ルールも持たない。最初の数字には 5 つの値がある:
- 1xx: Informational - リクエストは受け入れられ、処理を続けている
- 2xx: Success - 動作は正常に受信され、理解され、受け入れられた
- 3xx: Redirection - リクエストを完了するためさらにそれ以上の動作を行わなければならない
- 4xx: Client Error - リクエストは間違った構文か果たす事のできないものを含んでいる
- 5xx: Server Error - サーバは明白に正当なリクエストを果たすのに失敗した
HTTP/1.1 で定義された個々のステータスコード数値及びそれに相当するResason-Phrase のセットの例の値は以下に示される。ここでリストされたreason phrase は勧められるだけである
Status-Code = "100" ; Continue | "101" ; Switching Protocols | "200" ; OK | "201" ; Created | "202" ; Accepted | "203" ; Non-Authoritative Information | "204" ; No Content | "205" ; Reset Content | "206" ; Partial Content | "300" ; Multiple Choices | "301" ; Moved Permanently | "302" ; Moved Temporarily | "303" ; See Other | "304" ; Not Modified | "305" ; Use Proxy | "400" ; Bad Request | "401" ; Unauthorized | "402" ; Payment Required | "403" ; Forbidden | "404" ; Not Found | "405" ; Method Not Allowed | "406" ; Not Acceptable | "407" ; Proxy Authentication Required | "408" ; Request Time-out | "409" ; Conflict | "410" ; Gone | "411" ; Length Required | "412" ; Precondition Failed | "413" ; Request Entity Too Large | "414" ; Request-URI Too Large | "415" ; Unsupported Media Type | "500" ; Internal Server Error | "501" ; Not Implemented | "502" ; Bad Gateway | "503" ; Service Unavailable | "504" ; Gateway Time-out | "505" ; HTTP Version not supported | extension-code extension-code = 3DIGIT Reason-Phrase = *<TEXT, excluding CR, LF>HTTP ステータスコードは拡張可能である。HTTP アプリケーションは、すべての登録されたステータスコードの理解が明らかに望ましいが、それらすべての意味を理解する必要はない。しかしながら、アプリケーションは最初の数字によって示されるような、どんなステータスコードの分類も理解しなければならなず、認識されないレスポンスがキャッシュされてはならないという例外を除いて、すべての認識されないレスポンスをそのクラスの x00 ステータスコードに相当するようなものとして扱わなければならない。たとえば、431 の認識されないステータスコードがクライアントに受信されたなら、そのリクエストに何か不備があると言う安全な推測が行え、それが 400 ステータスコードを受信したかのようにレスポンスを扱える。このような場合、このエンティティがこの異常なステータスを説明しているであろう人間が読める情報をたぶん含んでいるため、ユーザエージェントはレスポンスで返されたエンティティをユーザに示すべきである。
6.2 レスポンスヘッダフィールド
レスポンスヘッダフィールドはサーバが Status-Line に置けないレスポンスに関する追加的な情報を渡す事を可能にする。これらのヘッダフィールドはサーバとさらにそれ以上の Request-URI によって識別されたリソースへのアクセスに関する情報を与える。
response-header = Age ; Section 14.6 | Location ; Section 14.30 | Proxy-Authenticate ; Section 14.33 | Public ; Section 14.35 | Retry-After ; Section 14.38 | Server ; Section 14.39 | Vary ; Section 14.43 | Warning ; Section 14.45 | WWW-Authenticate ; Section 14.46response-header フィールド名は確かにこのプロトコルのバージョンにおける変更に関連で拡張される事ができる。しかしながら、もし通信におけるすべてのパーティがそれらを response-header フィールドであると認識するなら、新しいものや実験的なヘッダフィールドは response-header フィールドのセマンティクスを与えられる可能性がある。
7 エンティティ
リクエストメソッドやレスポンスステータスによって特に妨げられていないなら、リクエ