HTTP/1.0仕様書 日本語訳
Hypertext Transfer Protocol -- HTTP/1.0
ハイパーテキストトランスファープロトコール第1.0版仕様書
このメモの位置づけ
この文書は、インターネットドラフトです。インターネットドラフトとは、
the Internet Engineering Task Force (IETF)自身、IETFの領域、またはIETF
の下にあるワーキンググループの作業文書(working documents)です。他のグ
ループも、作業文書をインターネットドラフトとして配布してもよいことに注
意してください。
インターネットドラフトの有効期限は最大でも作成日から６カ月であり、内
容の更新、新たな文書による置き換え、または他の文書に出現による価値の喪失
がおこる可能性が常にあります。このため、インターネットドラフトを参考文献
として使用することや、「作業進行中」と明記することなしに引用することは適
切ではありません。
インターネットドラフトの最新の状態を知るためには、ds.internic.net(ア
メリカ東海岸), nic.nordu.net (ヨーロッパ), ftp.isi.edu (アメリカ西海岸),
またはmunnari.oz.au (太平洋地域)のFTPサーバーの"the Internet-Drafts
Shadow Directories"に含まれている"1id-abstracts.txt"をチェックしてください。
この文書の配布に制限はありません。この文書へのコメントは、ワーキング
グループ（http-wg@cuckoo.hpl.hp.com）宛にお送り下さい。このワーキンググ
ループでの議論は、<URL:http://www.ics.uci.edu/pub/ietf/http/>に保管され
ています。またHTTP及びそれを用いたアプリケーションについての議論は、
<www-talk@info.cern.ch>メーリングリストで行なわれています。
要旨
Hypertext Transfer Protocol (HTTP)は、分散化される一方で互いに協調して
機能するハイパーメディア情報システムで必要とされる低負荷で、高速なアプリ
ケーションレベルのプロトコールである。HTTPは、多くの目的に利用可能な、状
態を保存しない(stateless)、オブジェクト指向のプロトコールであり、そのコマ
ンドの拡張により、例えばネームサーバーや分散型オブジェクト管理システムな
どの多くの用途に用いることができる。HTTPの特徴は、データ表現の型の分類
(typing)とそれについてデータの受け手と送り手がネゴーシエイションできるこ
とにある。これにより、転送されるデータと独立にシステムを構築することが可
能となっている。HTTPは、1990年からWorld-Wide Web global informationで使用
されてきた。この仕様書は、HTTP/1.0として知られているプロトコールの望ましい
使用法を記載しており、その内容は1994年11月以前に実装されたほとんどの有力な
HTTPサーバー、クライアントの仕様と互換性がある。
目次
1. はじめに
1.1 目的
1.2 プロトコールの仕組みの概要
1.3 用語の解説
2. 表記上の慣習と一般的な文法
2.1 拡張BNF記法
2.2 基本ルール
3. HTTPメッセージ
3.1 ヘッダーフィールド
3.2 オブジェクトボディー
4. RFC 822とMIME構文の利用
4.1 Date/Timeフォーマット
4.2 メディアの型(Media Types)
4.2.1 マルチパート型(Multipart Types)
4.2.1.1 Multipart/mixed
4.2.1.2 Multipart/parallel
4.2.1.3 その他のマルチーパート型
4.2.2 正準形式(canonical form)への変換
4.3 一般メッセージヘッダーフィールド(General Message Header Fields)
4.3.1 Connection
4.3.2 Date
4.3.3 Forwarded
4.3.4 Mandatory
4.3.5 Message-ID
4.3.6 MIME-Version
5. リクエスト(Request)
5.1 リクエストライン(Request-Line)
5.2 メソッド(Method)
5.2.1 GET
5.2.2 HEAD
5.2.3 POST
5.2.4 PUT
5.2.5 DELETE
5.2.6 LINK
5.2.7 UNLINK
5.3 HTTPのバージョン
5.4 URI(包括的資源識別子=Universal Resource Identifier)
5.5 リクエストヘッダーフィールド(Request Header Field)
5.5.1 User-Agent
5.5.2 If-Modified-Since
5.5.3 Pragma
5.5.4 Authorization
5.5.5 Proxy-Authorization
5.5.6 Referer
5.5.7 From
5.5.8 Accept
5.5.9 Accept-Encoding
5.5.10 Accept-Language
6. レスポンス(Response)
6.1 ステータスライン(Status-Line)
6.2 HTTPのバージョン
6.3 ステータスコード(Status Codes)とそれを説明するメッセージ
(Reason Phrases)
6.3.1 Successful 2xx
6.3.2 Redirection 3xx
6.3.3 Client Error 4xx
6.3.4 Server Errors 5xx
6.4 レスポンスヘッダーフィールド
6.4.1 Server
6.4.2 WWW-Authenticate
6.4.3 Proxy-Authenticate
6.4.4 Retry-After
7. オブジェクトヘッダーフィールド
7.1 Allow
7.2 Content-Length
7.3 Content-Type
7.4 Content-Encoding
7.5 Content-Transfer-Encoding
7.6 Content-Language
7.7 Expires
7.8 Last-Modified
7.9 URI Header
7.10 Location
7.11 Version
7.12 Derived-From
7.13 Title
7.14 Link
8. HTTPのネゴーシエイションアルゴリズム
9. 基本アクセス認証法(Basic Access Authentication Scheme)
10. 登録管理機関（Registration Authority）
11. セキュリティーについて
11.1 クライアントの認証
11.2 Idempotent Methods
11.3 サーバーログの悪用
12. 謝辞
13. 参考文献
14. 著者のアドレス
付録
A. プロトコールからわずかな逸脱を許容するアプリケーション
(Tolerant Applications)
A.1 リクエストライン、ステータスコード及びヘッダーフィールド
A.2 オブジェクトボディー
A.3 後向きの互換性
1. はじめに
1.1 目的
Hypertext Transfer Protocol (HTTP)は、分散化される一方で協調して働く
ハイパーメディア情報システムで必要な低負荷で高速なアプリケーションレベ
ルのプロトコールである。HTTPは、1990年からWorld-Wide Web Glocal
Informatino Initiativeにより使用されてきた。この仕様書は、HTTP/1.0として
知られているプロトコールの望ましい使用法を記述したものである。この仕様書
は、必ずしも特定のサーバーやクライアントの実装の現状を示すものではないが、
可能な限り現存する実装と互換性を保つことを目指して書かれており、HTTP/1.0
の今後の実装のためにレファレンスと考えてよい。
実用目的で使われる情報システムには、検索、画面の更新及び注釈を含めた
単純な情報収集機能以上の高度な機能が要求される。HTTP/1.0では、リクエスト
の目的を示すために使用されるメソッドが追加可能である。HTTPは、メソッドの
適用されるリソースを特定するために、Universal Resource Identifier(URI)[2]
を使用しているが、これは所在場所(URL)または[3]または名前(URN)を利用している。
メッセージは、インターネットメール[7]及びMultipurpose Internet Mail
extension(MIME)[4]で用いられているのと同様なフォーマットで転送される。
HTTP/1.0は、ユーザーエイジェントと様々なゲートウエイの間のコミュニケー
ションのためにも用いることができ、SMTP[12], NNTP[11], FTP[14], Gopher[1]や
WAIS[8]のような既存のインターネットプロトコールへのハイパーメディアによる
アクセスを可能としている。HTTP/1.0は、プロキシーサーバーを介して、既存のプ
ロトコールによって伝達されたデータを完全な形で利用することができるようにデ
ザインされている。
1.2 プロトコール仕組みの概要
HTTPによる通信は、リクエストとそれに対するレスポンスという枠組で行なわ
れる。リクエストを行なうプログラム（クライアント）は、それを受けとるプロ
グラム（サーバー）へコネクションをはり、リクエストメソッド、URI、プロトコー
ルバージョン（これらはスペースで区切られた１行の文字列で、リクエストライ
ンと呼ばれる：訳注）とその後に続くMIME様メッセージを含んだリクエスト・モ
ディファイアー（ヘッダーという１行の文字列に含まれる：訳注）、クライアン
ト情報（ヘッダーに含まれる）、ときにオブジェクトボディーの内容（POSTメソッ
ド場合には入力されたデータ、PUTメソッド場合にはファイル等：訳注）という
形態のリクエストをサーバーへおくる。サーバーは、ステータスライン（プロト
コールバージョンと状態コードを含む１行の文字列）とそれに続くMIMEに似たサ
ーバーについての情報（ヘッダーに含まれる：訳注）、オブジェクトの情報（ヘッ
ダーに含まれる：訳注）、時にオブジェクトボディーの内容（URLで指定された
ファイルの内容等：訳注）を含むメッセージを返す。１つのプログラムが、クラ
イアントとしてもサーバーとしても動作することがありえる（プロキシーやゲート
ウエイ：訳注）。クライアントとサーバーという用語は、１つのプログラムの一般
的な意味での目的というよりは、特定のコネクションの間での当該のプログラムの
役割を意味している。
インターネット上では、コネクションはTCP/IPを利用して行なわれることが通常
である。HTTPサーバーのデフォルトのポート番号は８０であるが、他の番号を使用
することもできる。このことは、HTTP/1.0がインターネットやその他のネットワー
クで他のプロトコールに優先して実装されることを妨げるものではない[15]。
HTTP/1.0のリクエストやレスポンスのデータ構造が、問題となっているプロトコー
ルのどのトランスポートデータ単位にマッピングされるかは、この仕様書では取り
扱わない。
この仕様書がかかれた時点の最新の実装では、コネクションはクライアントにより
各々のリクエストに先だって確立され、レスポンスを返した後にサーバーによって
切断される。しかし、これはプロトコールの特徴ではなく、この仕様書によって規
定されているわけではない。クライアントとサーバーは、ユーザーの操作、タイム
アウトやプログラムのエラーにより、どちらかの側が完了前にコネクションを切断
する場合に対応できなくてはならない。こうした場合、そのときの状態に関係なく、
コネクションの切断により行なわれていたリクエストは必ず終了する。
1.3 用語の説明
この仕様書は、HTTPによる通信を行なうプログラムの役割と送受信の対象となる
オブジェクトを示すために多くの技術用語を用いている。この節でで、その中の主
要なものの意味を説明しておくことにする。
コネクション(connection)
通信の目的のために２者の間に仮想回線(Virutual Circuit)を開設すること。
リクエスト(request)
HTTPのリクエストメッセージ(５章に定義されている)。
レスポンス(response)
HTTPのレスポンスメッセージ(６章に定義されている)。
リソース(resource)
URIにより識別可能なネットワークのデータオブジェクトまたサービス
クライアント(client)
リクエストを送る目的でコネクションを確立するプログラム。
ユーザーエイジェント(user agent)
ユーザーのもっとも近くにあり、リクエストを発信するクライアントプロ
グラム。
サーバー(server)
サービスのリクエストにレスポンスを返して答えるためにコネクションを受
けつけるプログラム
オリジンサーバー(origin server)
与えられたリソースを実際に持っているか、またはそれを作成するサーバー
プロキシー(proxy)
リクエストを転送（forward）するためにクライアントとサーバーの両方の
役割を果たす仲介プログラムのこと。プロキシーは、多くの場合ファイヤーウォー
ルを通るための手段として用いられる。プロキシーサーバーは、クライアントからの
リクエストを受けつけ、クライアントに対して直接サービスを行なうか、または他
のサーバーへリクエストを（多くの場合、ある種の翻訳、変換を行なって）転送す
る。キャッシングプロキシーは、サーバーレスポンスをキャッシュするサーバーで
ある。リクエストされたリソースのある部分は、本来のサーバーでなくキャッシュ
から提供される。プロキシーサーバーの中には、本来のサーバーとしても動作する
ものがある。
ゲートウエイ(gateway)
HTTPを他のプロトコールへ変換する役割を果たすプロキシーのこと。サー
バーからの返答もユーザーエイジェントに送られる前に同様にHTTPに変換さる。
2. 表記上の慣習と一般的な文法
2.1 拡張BNF（バッカス・ナウアー型）記法
この文書の内容は、通常の文及びRFC 822で使用されているものと似た拡張BNF記法
を用いて記述されている。本文書の仕様をもとにアプリケーションプログラムを書く人
は、本文書の記法に慣れておく必要がある。拡張BNF記法は、以下のような構造を
持っている。
name = definition
ルールの名前（name）は、単に名前そのもので（「<」や「>」では囲まな
い）、その定義(definition)とは「=」で区切られる。スペースは、継続行のイン
デントが１行以上にわたるルールの定義を示すために使われる場合にのみ意味を
持つ。いくつかの基本的なルールは、SP、TAB、CRCF、DIGIT、ALPHAなどの大文字
で表現されている。角括弧は、その存在がルール名の使用を識別するのに役立つ
場合には、定義の中で使用される。
"literal"
引用符はテキストを囲む。特に記述されていなければ、テキストは大文字、
小文字の区別をしない。
rule1 | rule2
("|")で囲まれた要素は、選択可能なものである。例えば、"yes | no"は、
yesとnoのどちらでもよいということを意味する。
(rule1 rule2)
括弧で囲まれた要素は、単一の要素として扱われる。即ち、
"(elem (foo | bar) elem)"は、"elem foo elem"と"elem bar elem"というトークン
の列を表現する。
*rule
"*"という文字は、繰り返しの要素の前に置かれる。上記の例の完全な
(complete)表現形式は、"<n>*<m>element"で、最低<n>回と最大でも<m>回要素が
出現することを示す。デフォルトの値は、０と無限であり、"*(element)"は、
０も含めていかなる数の要素にも対応する。"1*element"は少なくとも１個の要素に対応し、"1*2element"は１つまたは２つの要素に対応する。
[rule]
箱括弧は、オプションの要素を示す。"[foo bar]"は、"*1(foo bar)"と同じ
である。
N rule
"<n>(element)"は繰り返しの特殊な形態であり、"<n>*<n>(element)"と同じ
である。これは、(element)が<n>回出現することを表す。2DIGITは、２桁の数字で
あり、3ALPHAは３つのアルファベット文字列である。
#rule
構造子"#"は、"*"と似た意味を持ち、要素のリストを定義するために定義
されている。完全な表現形式は、"<N>#<M>ELEMENT"であり、１つ以上の(",")で
区切られた少なくとも<N>最大でも<M>の要素を表す。区切りには、いくつかの
スペースの列(LWS)が加わってもよい。この記法は、リストの通常の表現形態を非常に
簡単にする。例えば、"( *LWS ELEMENT *( *LWS "," *LWS ELEMENT ))"
のようなルールは、"1#ELEMENT"として示すことができる。この構造子が使われる
場合には、ヌル要素が許容されている。しかし、存在する要素の個数には数えられ
ない。例えば、"(ELEMENT), , (ELEMENT)"は許されているが、２つの要素としてし
か数えられない。このため、少なくとも１つの要素が要求されている場合には、最
低１つのヌルでない要素が存在しなければならない。デフォルトの値は、０と無限
であり、"#(ELEMENT)"は0を含めて如何なる数の要素のリストにもなりえる。
"1#ELEMENT"は、少なくとも１つ以上の要素を表現し、"1#2ELEMENT"は1または
2の要素を表現する。
; comment
ルールテキストの右側に置かれたセミコロンは、それ以降から行末までが
コメントであることを示す。これは、仕様の規定に対して有用な注釈をつけるため
の簡便な方法である。
2.2 基本ルール
基本的な構文構造を記述するために、この仕様書では以下のようなルールが使用
されている。US-ASCIIキャラクターセットは、文献[17]で定義されている。
OCTET = <すべての８ビット文字>
CHAR = <すべてのUS-ASCII文字(octets 0 - 127)>
UPALPHA = <すべてのUS-ASCIIの大文字（AからZまで）>
LOALPHA = <すべてのUS-ASCIIの小文字（"a"から"z"まで）>
ALPHA = UPALPHA | LOALPHA
DIGIT = <すべてのUS-ASCII数字（"0"から"9"まで）>
CTL = <すべてのUS-ASCIIコントロール文字(octets 0 - 31)
及びDEL(127)>
CR = <US-ASCII CR, キャリッジリターン(13)>
LF = <US-ASCII LF, ラインフィード(10)>
SP = <US-ASCII SP, スペース(32)>
HTAB = <US-ASCII HT, タブ(9)>
<"> = <US-ASCII ダブルクオータ>
HTTP/1.0では、オブジェクトボディーを除いたプロトコール要素において、
CR,LFという文字列を行末記号と定義している（これ以外の行末記号もアプリ
ケーションによっては許容される場合があるので付録を参照のこと）。オブ
ジェクトボディーの終りは、4.2.2節で記述されているように、オブジェクト
ボディーのデータメディアにより決められる。
CRLF = CR LF
HTTP/1.0のヘッダーを複数の行に分割する場合には、継続行はスペースの並
びで始まるようにしなければならない。連続したスペースは、意味的にはSPと
同じ（改行による折り返しも含めて）である。
LWS = [CRLF] ( SP | HTAB )
多くのHTTP/1.0のヘッダーフィールドの値は、LWSまたは特殊文字(special
character)により区切られる。これらの特殊文字をパラメーターの値として使
用する場合には、引用符つきの文字列の入れておかなくてはならない。
word = token | quoted-string
token = 1*<CTLsまたはtspecialsを除くすべてのCHAR>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "¥" | <">
| "/" | "[" | "]" | "?" | "="
| SP | HTAB
テキストの文字列は、ダブルクオータまたは角括弧を用いて引用されている場合
には、１つの単語として取り扱われる。
quoted-string = ( <"> *(qdtext) <"> )
| ( "<" *(qatext) ">" )
qdtext = <<">とCTLsを除くすべてのCHAR、
ただしLWSは含めるものとする>
qatext = <"<"、 ">"とCTLsを除く,すべてのCHAR、
ただしLWSは含めるものとする>
以下のテキストルールは、記述的なフィールド内容の対してのみ用いられる。
テキストの語は、RFC1522[5]に従う場合に限りUS-ASCII以外の文字セットのもの
を用いることができる。
text = <CTLsを除くすべてのOCTET
ただしLWSは含めるものとする>
3. HTTPのメッセージ
HTTPのメッセージは、クライアントのリクエストとサーバーのレスポンスから
なっている。
HTTP-message = Simple-Request ; HTTP/0.9のメッセージ
| Simple-Response
| Full-Request ; HTTP/1.0のメッセージ
| Full-Response
フルリクエスト(Full-Request)とフルレスポンス(Full-Response)は、オブジェ
クトの転送にRFC822[7]で指定された一般フォーマットを使用する。この２つのメッ
セージは、オプションとしてヘッダーフィールドとオブジェクトボディーを持つこ
とができる。オブジェクトボディーは、CRLFのみから成り立っているヌル行により
ヘッダーから分離される。
Full-Request = Request-Line ; 5.1節参照
*General-Header ; 4.3節参照
*Request-Header ; 5.5節参照
*Object-Header ; 7節参照
CRLF
[ Object-Body ]
Full-Response = Status-Line ; 6.1節参照
*General-Header ; 4.3節参照
*Response-Header ; 6.4節参照
*Object-Header ; 7節参照
CRLF
[ Object-Body ]
５節と６節で各々定義されているSimple-RequestとSimple-Responseでは、ヘッ
ダー情報はまったく利用できないし、リクエストメソッドは１つ(GET)に限定され
ている。このため、クライアントがオブジェクトの内容についてネゴシエイション
をすることやサーバーが返されてきたオブジェクトのメディアタイプを同定する
ことはできない。このため、ごく単純アプリケーションを除いては、Simple-Request
を用いることは避けた方がよい。
3.1 ヘッダーフィールド
リクエストヘッダー、レスポンスヘッダー、一般(general)ヘッダー、オブジェ
クトヘッダーや拡張ヘッダーを含めたHTTPヘッダーフィールドは、RFC822[7]の3.1
節で規定されている一般フォーマットにすべて従う。各々のヘッダーフィールドは、
「フィールド名称、":"、フィールド値」から成り立っている。フィールド値の前
には、スペースがいくつあってもよいが、１つであることが望ましい。ヘッダー
フィールドは、１つ以上のスペース文字を継続行の行頭におくことにより複数の行
に分けて記載できる。
HTTP-header = field-name ":" [ field-value ] CRLF
field-name = 1*<CTL、SP及び":"を除くすべてのCHAR>
field-value = *( field-content | comment | LWS )
field-content = <フィールド値を表現するOCTET、及び*textまたは
token、tspecials、quoted-stringからなるOCTET>
ヘッダーフィールドの順序には意味がない。しかしながら、一般ヘッダーを
最初にして、リクエストヘッダーまたはレスポンスヘッダーをその後に置き、
最後にオブジェクトヘッダーを置くのが通常である。コメントは、括弧でコメ
ントテキストを囲むことにより、HTTPヘッダーの中にいれることができる。
comment = "(" *( ctext | comment ) ")"
ctext = <"("と")"を含めたすべてテキスト文字列>
注意： HTTPヘッダーの中へコメントをいれることは、一般には推奨され
ない。というのは、そのコメントは人の眼にふれることがほとんどなく、ネット
ワークのトラフィックを増やすだけだからである。しかし、NNTPやSMTPゲートウ
エイを介して送受信されるメッセージについては有用かもしれない。
3.2 オブジェクトボディー
HTTP/1.0のリクエストまたはレスポンスともに送られるオブジェクトボディー
は、オブジェクトヘッダーフィールドによって定義されたフォーマットとコーディ
ング法に基づいて作成されている。
Object-Body = *OCTET
オブジェクトボディーの実際の長さ、エンコード法とデータの型は、MIMEで定義
されたものと似た、Content-Length, Content-Encoding, Content-Transfer-Encoding
とContent-Typeにより決定される。Content-Lengthヘッダーフィールドが存在すれ
ば、その値はオブジェクトボディーの長さをバイトで表現したものである。もし存
在しなければ、ボディーの長さは、Content-TypeとContent-Encodingによって決定
されるかまたは、サーバーによるコネクション切断によって決められる。
注意： オブジェクトボディーがリクエストメッセージの一部である場合に
は、コネクションの切断がContent-Lengthヘッダーの値を示すものとして用いるこ
とはできない。というのは、サーバーがレスポンスを返す可能性がないからである。
4. RFC 822とMIME構文
HTTP/1.0は、多くのインターネットメール（RFC 822,[7]）及びMutlpurpose
Internet Mail Extensions (MIME, [4])で定義された構文を再利用しており、こ
れによりオブジェクトを様々な表現法で転送することができる。しかし、HTTPは
既存のメールプロトコールとゲートウエイの制限に拘束されないため、RFC 822と
MIMEによって課せられた宣言のいくつかには従わない。この節では、これらの共
通の構文がHTTP内でどのように定義されているかについて記述する。
4.1 Date/Timeフォーマット
歴史的な理由により、HTTP/1.0では、日付／時間を表現するのに３つの異なった
フォーマットを採用している。
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()のフォーマット
最初のフォーマットは、インターネットの標準であり、RFC1123[6]（RFC 822の
改訂版）で定義されたフォーマットのうちの固定長のサブセットである。２つめの
フォーマットは、現在よく使用されている方法ではあるが、新しいのRFCの出現に
より意味を失ったRFC 850[10]の日付フォーマットに基づいており、年を４桁で表
現していない。HTTP/1.0のクライアントとサーバーは、３番目のフォーマットを
生成すべきではないが、これら３つのすべてのフォーマットを処理できなくてはな
らない。今後は、クライアントとサーバーとも、日付／時間の表現にはRFC 1123
フォーマットだけを生成するようにすることが強く望まれる。
すべてのHTTP/1.0の日付／時間は、グリニッジ標準時間(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/1.0規定しているのは、プロトコールストリーム内での使用す
る日付／時間フォーマットことのみである。クライアントとサーバーは、これら３
つのフォーマットをユーザーに表示したり、リクエストのログをとるなどのために
使用する必要はない。
4.2 メディアタイプ
HTTPは、オープンで拡張可能なデータ型分類及びそれに関してのネゴーシエイ
ションの方法を提供するために、以前MIME Content-Types[4]と呼ばれていたイン
ターネットメディアタイプを利用する[13]。メールプログラムでは、送り手と受け
手の間で型分類に関してのネゴシエンションがないが、こうした場合には許容可能
なメディアの型を厳しく限定することが理にかなっていた。しかし、HTTPでは、ユ
ーザーエイジェントは、コネクションの一部により許容可能なメディアタイプを指
定できるため、公式登録されていないメディアの型を利用するに際しては自由度が
大きい。メディアタイプについての以下の文法は、MIMEのスーパーセットになって
いる。
media-type = type "/" subtype *( ";" parameter )
type = token ; 大文字、小文字の区別なし
subtype = token ; 大文字、小文字の区別なし
parameter = attribute "=" value
attribute = token ; 大文字、小文字の区別なし
value = token | quoted-string ; 時に大文字と小文字の区別
をする
4.2.1 Multipart Types
HTTPでは、いくつかの「マルチパート(multipart)」タイプが利用可能である。
"multi-part"タイプでは、１つのメッセージのオブジェクトボディーの中に複数の
オブジェクトが格納される。マルチパートレスポンスは、ユーザーエイジェントが
個々の構成要素のメディアタイプを受け入れ可能なことの他に、マルチパートのメ
ッセージを受け入れ可能である場合にかぎり使用すべきである。一方、ユーザーエ
イジェントは、POSTまたはPUTリクエストの一部としてオブジェクトを送るときに
マルチパートタイプを使用することができる。
MIME[4]で同様にすべてのマルチパートタイプは、共通の構文を有し、メディア
タイプの一部として境界パラメーター(boundary parameter)を持たなくてはならな
い。一方、MIMEと異り、マルチパートボディーの各部分は、その部分の意味に対応
したHTTPヘッダーを持ってもよい。
boundary = 0*69( bchar | SP ) bchar
bchar = DIGIT | ALPHA | "'" | "(" | ")" | "+"
| "_" | "," | "-" | "." | "/" | ":" | "=" | "?"
マルチパートメッセージのオブジェクトボディーは、以下のように形式で作成
される。
multipart-body = discard-text 1*encapsulation
close-delimiter discard-text
encapsulation = delimiter body-part CRLF
delimiter = "--" boundary CRLF ; 境界(boundary)は、
; Content-Typeから得られる。
close-delimiter= "--" boundary "--" CRLF
discard-text = *(*text CRLF) ; 無視される。
body-part = *Object-Header
CRLF
[ Object-Body ] ; 境界(bondary)が異れば再帰的に
なり得る。
URIで識別可能な各々のオブジェクトの対して、URIヘッダーフィールド(7.9節)を
ボディー部分に入れておくべきである。
4.2.1.1 Multipart/mixed
"multipart/mixed"メディアタイプは、最初のボディーパートが同時に送られる
他のボディーパートへの参照を含む場合に使用される。例えば、最初のボディー
パートがHTML文書であり、続くボディーパートがその文書への注釈であるという
場合がある。しかし、"Multipart/mixed"を、関連したオブジェクトがすでに送信
済みであったり、ユーザーエイジェントやキャッシングプロキシーによりキャッ
シュされている場合に使用するのはやめた方がよい。
4.2.1.2 Multipart/parallel
"multipart/parallel"メデイアタイプは、"multipart/mixed"とほぼ同じ意味を
もつが、同時に送られるすべての部分をユーザーエイジェントが同時に表示しな
ければならないということ意味が付け加わっている。このタイプは、例えば音声
付きのスライドや映画のように複数のメディアを同時に表現することが重要な場
合に使用するとよい。
注意： この文書は、「同時表現」という言葉が意味していることをすべて
規定しているのではない。言い換えると、HTTP/1.0は、"multipart/parallel"とい
うタイプのメッセージの各部分の間での情報表現の同期の手段を提供してはいない。
4.2.1.3 他のマルチパートタイプ
IANA[15]に登録された他のマルチパートタイプは、HTTP/1.0では特別な意味は
持たないが、ユーザーエイジェントは、各ボディーパートの目的を正しく解釈す
るためにそれらのタイプを理解する必要があるかもしれない。
4.2.2 正準形(cannonical form)への変換
メディアタイプに関係なく、クライアントとサーバー間でのデータの転送中に、
HTTPはオブジェクトボディーの行末記号や他の構文の正準型への変換を求めない。
しかし、ゲートウエイ上のプログラムは、MIMEの規定に従うプロトコールへHTTP
のオブジェクトボディーが渡される前に正準型への変換が必要になる可能性があ
る[4]。それに加えて、HTTPメッセージを他のプロトコールで転送される形に
変換するために追加処理が必要となるかもしれない。特にContent-Encodingがメッ
セージに入っているオブジェクトに適用されている場合はそうした処理が必要な
ことが多い。
これらの場合と違って、MIMEの規定に従うメッセージをHTTPで転送する場合には、
変換の必要がないようにすべきである。
4.3 一般(general)メッセージヘッダーフィールド
リクエストとレスポンスの両方で使用できるヘッダーフィールドがいくつかある
が、これらは交信者と転送されるオブジェクトに対しては使用するものではない。
一般ヘッダーには必須のものはないが、その使用が適切な場合には使用することが
強く望まれ、今後の実装されるHTTP/1.0のクライアントとサーバーはこれらを理解
する必要がある。一般ヘッダーは、転送されるメッセージにのみ適用される。
General-Header = Connection
| Date
| Forwarded
| Mandatory
| Message-ID
| MIME-Version
4.3.1 Connection
Connectionヘッダーは、現在のコネクションのパラメーター（望まれているもの
でも実際に使用されているものでもよい）を指定するのに用いられる。クライアン
トは、このヘッダーをコネクションオプションのうちのどれを使用したいかを指定
するために用いる。サーバーは、実際にどのオプションが実際に使われているかを
示すために使用する。このフィールドは、現在のコネクションにのみ適用される。
受け手は、コネクションが閉じられた後にそのコネクションの情報をキャッシュ
したり保存したりしてはならない。プロキシーは、このヘッダーを転送してはなら
ないが、自分が張ったコネクション用に別のコネクションヘッダーを生成してもよ
い。
Connection = "Connection" ":" 1#connect-option
connect-option = token [ "=" word ]
現在のHTTP/1.0クライアントとサーバーは、実験目的以外ではコネクションヘッ
ダーを用いていないが、このフィールドは当該のコネクションに特有の動作を将来
拡張可能にするために必要となると思われる。もっとも重要なことは、HTTP/1.0の
プロキシーは、このヘッダーの内容を理解できないかまたは使わない場合でも転送
してはならないことである。例えば、実験用のクライアントが以下のように送って
きた場合、クライアントは、複数のリクエストのためにコネクションをオープンし
たまますることを望んでいることを示す。
Connection: keep-alive
サーバーは、以下のようなメッセージを返して、コネクションが最大５つのリク
エストまで維持されるが、１０秒以内に次のリクエストがこなければタイムアウト
することを伝えるかもしれない。
Connection: keep-alive, timeout=10, maxreq=5
ここに例として挙げたオプションの意味は、HTTP/1.0では規定されていないこと
を注意しておく（この例のようなオプションが将来のHTTPで定義されるかもしれな
いが）。
4.3.2 Date
Dateヘッダーは、メッセージが発信されたときの日付と時間を表現する。意味は
RFC 822のorig-dateと同じである。もしメッセージがユーザーエイジェント（リク
エストの場合）や発信元のサーバー（レスポンスの場合）との直接のコネクション
から得られた場合には、デフォルトのdateは最終的な受け手の現在のdateであると
想定される。しかしながら、発信時点のdateは、キャッシュされたレスポンスの評
価のために重要であるから、発信元のサーバーは常にdateヘッダーを送るべきで縅
る。dateヘッダーフィールドを持たないメッセージを受けとった場合には、それが
受け手にキャッシュされるか、またはdateを要求した他のプロトコールにより仲介
された場合にかぎり、受け手がdateを付与すべきである。フィールドの値は、4.1
節に記述されたhttp-dateである。
Date = "Date" ":" HTTP-date
例を挙げる。
Date: Tue, 15 Nov 1994 08:12:31 GMT
１つのメッセージには、dateヘッダーフィールドを１つだけをつけることができる。
注意： この文書の前のバージョンでは、同時に送られたオブジェクトボディ
ーの作成されたdateをこのフィールドが入れるべきであると誤って規定していた。こ
れは、実際の（そして適切な）使用法を反映するように変更されている。
4.3.3 Forwarded
forwardedヘッダーは、ユーザーエイジェントとサーバー（リクエストの場合）の
間及びオリジンサーバーとクライアント（レスポンスの場合）間を仲介する過程を示
すためにプロキシィーが使用する。このヘッダーは、RFC 822のreceivedフィールド
と類似しており、転送上の問題をつきとめるためやリクエストループを回避するため
に使用されることを意図して作成された。
Forwarded = "Forwarded" ":" "by" URI [ "(" product ")" ]
[ "for" FQDN ]
FQDN = <Fully-Qualified Domain Name>
例えば、メッセージはptsun00.cern.ch上のクライアントからサーバーinfo.cern.ch
のポート8000番へ送られ得る。www.ics.uci.eduのサーバーに受けとられたリクエスト
は、以下のようなforwardedヘッダーフィールドを持つ。
Forwarded: by http://info.cern.ch:8000/ for ptsun00.cern.ch
forwardedヘッダーは複数つけることができ、メッセージを転送した各々のプロ
キィシーを記載できる。ファイアーウオールの通過手段として使用されるプロキシ
ーでは、デフォルトでは、ファィアーウオール内のホストについての情報を送り出
さないようにすることが望ましい。この情報は、明示的にホスト情報の転送を有効
にした場合にかぎり外に出されるようにべきである。この機能が無効になっていた
場合には、forトークンとFQDNをこのフィールドの値に入れてはならない。
4.3.4 Mandatory
mandatoryヘッダーは、メッセージの内容が蓄積され、キャッシュされ、ユーザー
に提示される前に受け手により理解されなくてはならないフィールドヘッダー名の
リストを示すために使用される。このヘッダーは、受け手にここにリストされたヘッ
ダーを理解できない場合には、安全に無視することはできないということを警告す
る。フィールド名は、送り手のライセンス、著作権、支払または他の正しい使用を
守るために受け手が認識しなけらればならない状況へ対応することが想定される。
Mandatory = "Mandatory" ":" 1#field-name
mandatoryヘッダーの推奨される使用法は、HTTP/1.0では定義されていない。しか
しながら、キャッシングプロキシーは、理解できないmandatoryヘッダーを含むレス
ポンスをキャッシュしてはならない。
4.3.5 Message-ID
HTTPのmessage-IDフィールドは、インターネットメイルやUSENETメッセージで使
用されているものと同一であり、文献[10]で定義されている。このフィールドは、
メッセージ（その内容ではない）を一意に識別するためにそのメッセージの予測され
る生存期間よりも”かなり長い間”使用できる単一のユニークな識別子として使用で
きる。
Message-ID = "Message-ID" ":" "<" addr-spec ">"
addr-spec = unique-string "@" FQDN
unique-string = <1*CHAR, ただしスペース, "@"または">"は含まない>
unique-stringは、FQDNで規定されるホスト内でユニークでなければならない。例
えば以下のようなものである。
Message-ID: <9411151630.4256@info.cern.ch>
このmessage-IDは、ホストinfo.cern.chの時間、日付とprocess-IDから成り立っ
ている。
4.3.6 MIME-Version
HTTPは、MIMEに従うプロトコールではない。しかしながら、HTTP/1.0メッセージ
は、メッセージを構築するためにMIMEのどのバージョンが使用されているかを示す
MIME-Versionヘッダーを１つだけ含んでもよい。MIME-Versionヘッダーフィールド
の使用は、MIMEプロトコール（文献[4]で規定されている）に完全にメッセージが
沿っていることを示すべきである。残念ながら、HTTP/1.0クライアントとサーバー
の現在のバージョンは、このフィールドを厳密に使用しないため、受け手はメッセ
ージが実際のMIMEに完全に対応していることを想定してはならない。ゲートウエイ
は、厳格なMIME環境へメッセージを転送する場合には、この許容性（可能なら）を
保証する責任がある。将来のHTTP/1.0のアプリケーションは、メッセージがMIMEに
対応することを意図していればmime-versionヘッダーのみを使用しなければならな
い。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIMEバージョン1.0がHTTP/1.0ではデフォルトになっている。しかしながら、
HTTP/1.0のメッセージの構文や意味は、この文書により定義されており、MIMEの
仕様により定義されているわけではない。
5. リクエスト
クライアントからサーバーへのリクエストメッセージには、最初の行にリクエ
ストされたオブジェクトに適用するメソッド、オブジェクトの識別子と使用され
るプロトコールのバージョンが含まれている。機能の限定されたHTTP/0.9プロト
コールとの後向きの互換性のために、HTTPリクエストには２つの有効なフォーマ
ットがある。
Request = Simple-Request | Full-Request
Simple-Request = "GET" SP URI CRLF ; HTTP/0.9リクエスト
Full-Request = Request-Line ; 5.1節参照
*General-Header ; 4.3節参照
*Request-Header ; 5.5節参照
*Object-Header ; 7節参照
CRLF
[ Object-Body ] ; 3.2節参照
HTTP/1.0のサーバーがSimple-Requestを受けとったら、HTTP/0.9のSimple-
Responseを返さなくてはならない。同様にクライアントは、ステータスラインで
始まらないレスポンスを受けとったら、Simple-Responseであると想定して構文
解析しなければならない。
5.1 リクエストライン(Request-Line)
リクエストラインは、メソッド(method)トークンではじまり、URIとプロトコー
ルのバージョンが続き、CRLFで終わる。各要素は、スペースで区切られる。最後の
CRLF以外には、CRやLFの挿入は許されない。
Request-Line = Method SP URI SP HTTP-Version CRLF
5.2 メソッド（Method）
Methodトークンは、URIで識別されるリソースに対して適用されるメソッドを示
す。メソッドは、大文字、子文字の区別し、拡張が可能である。
METHOD = "GET" | "HEAD" | "PUT" | "POST"
| "DELETE" | "LINK" | "UNLINK"
| extension-method
extension-method=token
GETとHEADは、すべてのHTTP1.0に従うサーバーでサポートされなくてはならない。
特定のリソースに対して受理可能なメソッドのリストは、"Allow"オブジェクトヘッ
ダーで指定できる(7.1節)。しかしながら、クライアントは特定のリソースに対して
あるメソッドが現在許容されているのかどうか常にレスポンスのリターンコードに
よって通知を受けている。常にこれは動的に変化するからである。
HTTP/1.0で規定されているメソッドを以下に記述する。これらは容易に拡張可能
であるが、追加されたメソッドは独立に拡張されたクライアントとサーバーで同じ
意味を持つことは仮定できない。互換性を維持するために、拡張メソッドの意味の
定義はHTTP登録機関(HTTP registration authority)に登録すべきである。サーバー
は、もしメソッドが未知のものであれば、ステータスコード"501 Not Implemented"
を返すべきである。
5.2.1 GET
GETメソッドは、URIで識別されたオブジェクトを取ってくることを意味する。URI
がデータを出力するプロセス、またはプロセスにより起動されるスクリプトであれ
ば、レスポンス中のオブジェクトボディーとして返されるのは出力されたデータで
あり、スクリプトやプロセスのソーステキストでない。（たまたまデータを出力す
るプロセスの出力がそうであった場合は除く）
GETメソッドの意味は、リクエストメッセージがIf-Modified-Sinceヘッダーフィー
ルドを含めば条件つきGET（conditional GET）に変わる。条件つきGETメソッドは、
認識されたオブジェクトボディーがIf-Modified-Sinceヘッダーで与えられた日付か
ら更新された場合にのみ転送される。更新されていれば（または送られたIf-Modified-
Since日付が無意味なものであれば）、レスポンスはGETとまったく同じである。も
しオブジェクトがIf-Modified-Since以来更新されていなければ、サーバは
"304 Not Modified"を返す。条件つきGETメソッドは、複数のリクエストを発生させ
たり、不必要なデータを転送したりすることなしに、キャッシュされたオブジェクト
をリフレッシュすることを可能にすることにより、ネットワークの負荷を減少させ
るために考案された。
HTMLフォーム[16]からのデータは、GETメソッドを用いて"?"と属性とその値の組
を追加することによりサーバーへ転送可能である。11.2節では、リクエスト中に
フォームデータをいれる場合に、GETとPOSTをどのように使い分けるか記述してある。
5.2.2 HEAD
HEADメソッドは、サーバーがレスポンスにオブジェクトボディーを返してはな
らないことを除けば、GETと同じである。HEADリクエストに対するレスポンスの
HTTPヘッダーに含まれるメタ情報は、GETリクエストへのレスポンスとして送ら
れる情報と同じでなければならない。このメソッドは、オブジェクトボディーを
転送することなく、URIで識別されたオブジェクトについてのメタ情報を取得す
るのに用いられる。このメソッドは、ハイパーテキストのリンク先の妥当性、
アクセス可能性、もっとも最近の変更を知るためによく用いられる。
5.2.3 POST
POSTメソッドは、オリジンサーバーがリクエストラインでURIとして同定される
リソースに新たに従属するものとして、リクエスト中のオブジェクトを受けとるた
めに使用される。POSTメソッドは、以下の機能を実現できるような実現できるよう
な包括的な機能をもつものとして設計された。
o 既存の文書の注釈
o 掲示板、ニュース、メールや他の同様な記事の集まりへメッセージを
投稿すること
o データのブロック（通常はフォームである）をデータを処理できる
プロセスまたはそうしたプロセスによって起動されるスクリプトへ送ること
o 新たな記述を加えて文書を拡張すること
投稿されたオブジェクトは、ファイルがそれを含むディレクトリーに所属するよ
うに、またニュースの記事が投稿されたニュースグループに所属するように指定さ
れたURIに所属するものと考えられる。
クライアントとは、リクエスト中にURI-headerフィールドを含めることにより
新しいリソースを識別するためのURIを提案できる。しかしながら、サーバーは
それをURIをつけるための参考として取り扱うべきであり、異なったURIのもとにオ
ブジェクトを置いてよい。オリジンサーバーは、ユーザーエイジェントに割り当て
られたURIをレスポンス中のURI-headerで返さなければならない。
クライアントは、7.14節で記述したように新しいリソースと他の既存のリソース
の間の関係をLinkヘッダーフィールドを含めることにより規定できる。サーバーは、
新しいオブジェクトが付け加えられたことの結果として、他の操作をこのリンクを
用いて行なってよいが、これはオリジンサーバーの義務ではない。オリジンサー
バーもまた、それ自体または追加的なリンクを他のリソースにはってもよい。
リソースがオリジンサーバーで作成されたら、リクエストのステータスを記述し、
新しいリソースを参照するオブジェクトボディー（望むらくは"text/html"で）とと
もに、割り当てられたURIとすべての利用可能なLinkを示すヘッダーフィールドを
レスポンスの中に含めておく必要がある。
POSTが成功しても、オリジンサーバ上にオブジェクトがリソースとして作成され
たり、将来アクセス可能になるとは限らない。即ち、POSTメソッドで行なわれる
アクションは、URIで同定できるリソースをもたらさないかもしれない。この場合
、レスポンス中の"200 OK"というコードは正しいStatus-Codeである。リソースが
作成されたら、"201 Created"がレスポンスでなければならない。
注意： ユーザーエイジェントは、Webのトポロジーに関してこのメソッド
の結果もたらされる状況を仮定してはならない。例えば、POSTが受理されると、
その効果は遅れたり、人間やバッチプロセスにより修正されたりするかもしれない。
ユーザーエイジェントは、今作られた（またはかつて）リソースに依存した動作を
してはならない。
5.2.4 PUT
PUTメソッドは、リクエスト中のオブジェクトが同時に提供されたURIのもとで
蓄積されることを要求する。URIがもし既存であれば、同封のオブジェクトは
サーバー上に存在するオブジェクトの改訂版とみなされるべきである。URIが既存
のリソースをささず、リクエストしたユーザーエイジェントからの新しいリソース
である規定できれば、サーバーはそのURIのもとでリソースを作成してよい。
クライアントは、7.14節で記すようにLinkヘッダーフィールドをいれることに
より同じリクエスト中のオブジェクトと他の既存のリソースとの関係を作成または
変更できる。POSTと同様にサーバーはLink情報をリクエストの結果として、他の操
作を実行するために用いることができるが、義務ではない。サーバーは、それ独自
または追加のリンクを他のリソースにはることができる。
リソースがどのように置かれるか、そしてその既存のリソースに何がおこるか決
めるために実際の方法は、すべてサーバーにより規定される。もしサーバーに
バージョン管理(version control)が実装されていれば、VersionとDerived-From
ヘッダーフィールドは、リソースの版の同定と制御に用いられるべきである。
5.2.5 DELETE
DELETEメソッドは、オリジンサーバーにURIで識別されるリソースを削除すること
を要求する。このメソッドは、サーバー上での人間の介入（または他の方法）によ
りオーバーライドされる可能性がある。クライアントは、例えオリジンサーバが削
除に成功したというステータスコードを返してきたとしても、その操作が実行され
たことを保証されない。しかしながら、サーバーはレスポンスの時点でそのリソー
スを削除することを意図していないのであれば、成功したと返すべきではない。
5.2.6 LINK
LINKメソッドは、URIで同定される既存のリソースと他の既存リソースの間に１
つまたはそれ以上のLink関係を確立する。LINKメソッドとリソースの間のlink関
係を作成できる他のメソッドとの違いは、LINKメソッドでは、オブジェクトボディー
をリクエストの中に送ることができず、新しいリソースの作成が行なわれない点に
ある。このメソッドは、既存のリソースへメタ情報を加えるためにだけの目的のた
めに定義されている。
5.2.7 UNLINK
UNLINKメソッドは、URIで同定される既存のリソースとの１つまたはそれ以上の
リンク関係を取り除く。これらのリンクは、LINKメソッド及びlinkヘッダーをサ
ポートする他のメソッドによっても作成可能である。リソースへのリンクを取り
除くことは、リソースが消滅したり、以後もアクセスできなくなることを意味し
ない。
5.3 HTTP-Version
HTTP-Version要素は、リクエストで用いられるHTTPのバージョンを示す。もし
指定されていなければ、サーバーはHTTP version 0.9と想定し、Simple-Response
を返す。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
この仕様書で定義されるプロトコールのFull-Requestは、"HTTP/1.0"を用いる。
5.4 包括的資源識別子（Universal Resource Identifier）
URIは、RFC 1630[2]で定義された包括的資源識別子（Universal Resource
Identifier）であり、リクエストを適用する資源を識別する。
URI = <As defined in RFC 1630>
サーバーがproxyとして使われていない場合には、部分URIがHTTPプロトコール
の使用(http)とホスト名（またはアドレス）が自明であることを前提に与えられる。
つまり正式なURIが次のようなものとすると、
http://info.cern.ch/hypertext/WWW/TheProject.html
対応するSimple-RequestでもFull-Requestでも部分URIは、次のようなものとな
ります。
/hypertext/WWW/TheProject.html
クライアントがproxyを介して要求を送る場合には、プロトコールとホスト名は
明示的に表現されなければならない。
URIは、文献[2]で記述されたエスケーピングスキーマ(escaping scheme)を用いて
表現しなくてはならない。
5.5 リクエストヘッダーフィールド
リクエストヘッダーフィールドは、クライアントがリクエストについての付加的な
（およびクライアント自身）情報をサーバーへ送るために用いられる。すべて
のヘッダー領域は、オプションであり、一般的なHTTP-headerの構文と一致する。
Request-Header = User-Agent
| If-Modified-Since
| Pragma
| Authorization
| Proxy-Authorization
| Referer
| From
| Accept
| Accept-Encoding
| Accept-Language
未知のヘッダー領域は、Object-Headerとみなされる。
5.5.1 User-Agent
ユーザーエイジェントフィールドは、リクエストを行なったユーザーエイジェン
トについての情報を含む。これは、統計をとる目的、プロトコール違反の追跡、レ
スポンスを返す際に特定のユーザーエイジェントの制限や特徴を避けるために必要
なユーザーエイジェントの自動認識のために使用される。このフィールドは必須で
はないが、ユーザーエイジェントはリクエストに際してこのフィールドを含めるべ
きです。このフィールドには、ソフトウエアの名前を示す複数のトークンを含むこ
とができ、これにはスラッシュと版を示す表示やユーザーエイジェントの重要な部
分をなす他のソフトウエアの名前を含めてもよい。そのアプリケーションを特定す
るために重要な順にリストされるのが習慣である。
User-Agent = "User-Agent" ":" 1*( product )
product = token ["/" product-version]
product-version = 1*DIGIT "." 1*DIGIT
例
User-Agent: CERN-LineMode/2.15 libwww/2.17
ソフトウエアを示すトークンは簡潔であるべきである。このフィールドを宣伝目
的や他の必須でない情報のために使うことは、巌につつしむべきであるし、そうし
た行為はプロトコール違反とみなされるであろう。
注意: いくつかのproxyソフトウエアは、そのソフトの情報をUser-Agent
フィールドに追加する。これは現時点では推奨されない。というのは、これらの
フィールドのコンピュータの解釈を曖昧にするからである。proxyは4.3.3節に述
べたForwardedヘッダーを使用するべきである。
5.5.2 If-Modified-Since
"If-Modified-Since"ヘーダーフィールドは、処理を条件つきにするために
GET methodで用いられる。もしリクエストされた文書がこのフィールドで示さ
れた時間以後に変更されていない場合には文書はサーバーから送られず、その
代わりに"304 Not Modified"というステータスが送られる。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
例は以下の通りである。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
この機能の目的は、トランザクションのオーバーヘッドを最小にした効率的な
ローカルキャッシュの更新を可能にすることである。オーバーヘッドは増えるが、
同じ機能は、HEADリクエストを出してオブジェクトの変更の有無を確認してから、
GETリクエスト要求を出すことによって実現可能である。
5.5.3 Pragma
Pragmaヘーダーフィールドは、関連する(例えば、proxy）サーバーに適用される
指示子（directive）を指定するために使用される。指示子は、クライアントがリク
エストチェインの際にすべてのサーバーにある一定の動作を要求することを可能に
する。複数のpragma指示子が、リクエストの一部として記述可能であるが、HTTP/1.0
では現時点で"no-cache"指示子しか定義していない。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token
"no-cache"が存在すると, キャッシングサーバーはキャッシュ期限がきれてい
なくてもキャシュされた文書を返さずに、実際のサーバーへその文書をリクエスト
する。
Pragmaは、それ自体がproxyで意義を持つ場合であっても、必ず転送されなくては
ならない。これは、リクエストが多段proxyで処理される場合に必要で、pragmaは
すべてのproxyに影響を与える必要がある。特定のproxyに対して、特定のpragma
を適用するように指定することはできない。しかしながら、gatewayやproxyの関連
しないpragram指示子は無視されるべきである。
5.5.4 Authorization
今回のHTTP protocolのバージョンでは、９節で説明するような簡単なユーザー
認証のための方法を用意している。Authorizationヘッダーフィールドには、リク
エストを行ったユーザーを指定する。
Authorization = "Authorization" ":" (
( "Basic" encoded-cookie )
| ( extension-scheme [ extension-encrypted ] ) )
encoded-cookie = <base64 encoding of userid-password>
userid-password = [ token ] ":" *text
extension-scheme = token
extension-encrypted = word
このフィールドは、より高度な暗号化方法を利用できるように拡張が可能となって
いる。最初の単語は、使用している認証法を指定し、その後にUser-IDとパスワードの
コード化されたものが続くデコードされた形では、"｜"で区切られている。）。ベー
シックスキーマ(Basic schema）によるコード化は、改行なしのMIMEのbase64のコード
化と同じでである。ベーシックスキーマは、通常のFTPやtelnetで用いられているのと
同様な低いセキュリティーセキュリティーレベルの認証法しか提供おらず、安全な情
報転送しくみとはみなすことができない。
注意： User-IDとpasswordはともに省略可能なので、useridとpasswordの組
は単一のコロン(":")にすることもできるが、これは推奨できない。
5.5.5 Proxy-Authorization
Proxy-Authorizationヘッダーフィールドは、クライアント（またはユーザー）の
認証をプロキシーが行うために使用する。フォーマットは、Authorizationと同じ
である。
Proxy-Authorization
= "Proxy-Authorization" ":" (
( "Basic" encoded-cookie )
| ( extension-scheme [ extension-encrypted ] ) )
Authorizationと異なり、Proxy-Authorizationは現在のコネクションのみに適用
され、もっと先にあるサーバーやプロキシーへ転送されてはならない。
5.5.6 Referer
Refererフィールドには、サーバー側の便宜のためにリクエスト中のURIが得られ
た文書（または文書の中の要素）のURIを指定する。これにより、サーバー側では、
サーバー運用者の興味、及びログ、キャッシュの最適化等の目的のためにバックリン
クのリストを生成することができる。またメインテナンスの目的で既になくなったか
またはタイプミスのあるリンクをトレースすることが可能である。このフィールドの
フォーマットは 下記の通りである。
Referer = "Referer" ":" URI
例を挙げる。
Referer: http://info.cern.ch/hypertext/DataSources/Overview.html
部分URIが与えられたら、リクエストされたオブジェクトのURIへの相対的な
パスと解釈されるべきである。
注意： リンクのソースは、個人的な情報かもしれないし、情報源の所在を開
示することによりセキュリティー上の問題が生じる可能性があるので、Refererフィー
ルドを送るかどうかユーザーが決められるようにしておくことが強く推奨される。例
えば、クライアントのブラウザーは、情報を開示して情報を参照するのかまたは
匿名で行うのか指定するトグルスイッチを持つようにし、それがRefererとFrom情報を
送るかどうかに各々対応するようにしておくことが可能である。
5.5.7 From
Fromヘッダーフィールドは、もし存在すればuser agentを使用している人の電子
メールアドレスが指定する。そこには、RFC 822で定義された機械可読形態のメー
ルアドレスが記載すべきである。
From = "From" ":" addr-spec
例えば、以下の通りです。
From: webmaster@w3.org
このヘッダーフィールドは、ログをとる目的と無意味であったり望まれないリク
エストを識別する方法として用いることができる。このフィールドは、アクセス制
限のための方法として用いるべきではない。このフィールドの解釈は、指定された
人に代わってリクエストが行なわれているということであり、その人は使用されるメ
ソッドに対して責任を持つ人である。特にロボットからリクエストを発する場合に
は、このフィールドを入れておくべきである。というのは、問題が起こった場合に
ロボットを走らせた人とコンタクトがとる必要があるからである。
このフィールドのメールアドレスは、ロボットの動いているマシン名と対応して
いる必要はない。（例えば、レクエストがproxyを介してなされる場合には、オリジ
ナルの発信者のアドレスを使用するべきである。アドレスは、インタネットアドレス
か他のメールシステムのアドレスをインターネット形式で表現したものかどうかにか
かわらず、有効なインタネットメールアドレスであるべきです。
注意： クライアントは、実際のユーザーの許諾なしにFromヘッダーを送って
はならない。ユーザーのプライバシー上の利益やそのサイトのセキュリティーポリ
シーとの間にあつれきをおこす可能性があるからである。ユーザーがリクエストの前
にこの機能を停止、開始、変更することができるように
することが強く望まれる。
5.5.8 Accept
Acceptヘッダーフィールドには、リクエストへのレスポンスとして受理可能な
メディアの型を記載する。このフィールドの値は、クライアントの受理可能なメ
ディア型を表現する必要がある。
このフィールドは、複数の行に分割可能であり、また複数個のフィールドを
用いることができる。この場合、すべてのエントリーが１つのフィールドに属
するのと同じ意味となる。
Accept = "Accept" ":" 1#(
("*" | type) "/" ("*" | subtype)
*(";" parameter)
[ ";" "q" "=" ( "0" | "1" | float ) ]
[ ";" "mxb" "=" 1*DIGIT ] )
float = <ANSI-C floating point text representation,
where (0.0 < float < 1.0)>
qは、クライアントがそのメディアタイプをどの程度うまく取り扱いことができ
るかを示す質的因子であり、mxbは最大受理可能なオブジェクトボディのサイズを
10進法で示したものである。定義自体は、重複したacceptパラメータを禁止してはい
ないが、その解釈の仕方は定義していない。ネゴーシエイションのアルゴリズムに
ついては８節を参照のこと。少なくとも１つのAcceptヘッダーが存在する場合には、
質的因子0はmedida-typeやmedica-typesの組を含んだacceptヘッダーフィールドを
送らないことと等価である。デフォルトの値は、qは1であり、mxbは定義されていない。
時間を節約するため、またクライアントに予想できないmedia typeを処理すること
ができるようにするために、アスタリスク"*"はtype tokenまたはsubtype tokenのど
ちらかかまたは両方に用いることができる。例えば下記の例は、「audio/basicの
でデータが用意されていればそれで送って欲しい。そうでなければその他のaudioでもよい」という意味に解釈される。
Accept: audio/*; q=0.2, audio/basic
Acceptヘッダーがない場合には、クライアントはすべてのフォーマットを質的因子
1で受け入れると想定される。これは、Acceptヘッダーフィールドに下記の２つのよ
うに記載するのと等価である。
Accept: */*; q=1 または Accept: */*
もっと複雑な例は、以下のとおりである。
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8; mxb=100000, text/x-c
これは、言葉で表現すれば「text/htmlとtext/x-cは、望ましいメディアタイプで
あるが、もし存在しなければオブジェクトの大きさが100000バイトよりも小さけれ
ば、オブジェクトボディーをtex/x-dviで送ってくれ。もしこれが当てはまらなけれ
ば、text/planが送ってくれ。」という意味である。
注意： 前のバージョンの仕様書では、mxsパラメーターはレスポンスが到
着するまでの最大許容可能な遅れを秒単位で表現していた。これは、サーバーが有
用な参照値を得る方法がないという理由により削除された。しかしながら、このこ
とはクライアントが内部でレスポンスの時間をはかりacceptヘッダーフィールドを
それに基づいて最適化することを妨げるものではない。
5.5.9 Accept-Encoding
Accept-Encodingヘッダーフィルドは、Acceptと同様の意味を持ち、レスポンス
の中で受けとることのできるContent-Encodingタイプをリストする。
Content-Encodingは、7.4節に記述されている。
Accept-Encoding = "Accept-Encoding" ":"
1#(encoding-mechanism [ ";" encoding-param ] )
encoding-mechanism = extension-encoding
encoding-param = "q" "=" ( "0" | "1" | float )
extension-encoding = token
qは、クライアントが如何にencoding typeを取り扱うかということの質的因子で
ある。デフォルトの値は、1である。IANA[15]にエンコード法(encoding-mechanism)
が登録されていない場合は、すべて拡張エンコード法(extension-encoding)に属す
ることになる。以下のような２つの有名な拡張エンコード法が存在する。
"x-compress", "x-gzip"
Accept-Encodingがない場合には、クライアントはいかなるエンコード法も受理
しないと想定される。使用例は以下のとおりである。
Accept-Encoding: x-compress
5.5.10 Accept-Language
Accept-Languageヘッダーフィールドは、Acceptと同様であるが、受理可能なレ
スポンスの自然言語の集合である。
Accept-Language = "Accept-Language" ":"
1#(language-dialect *1(";" language-param) )
language-dialect = ("*" | language) ["/" dialect ]
language-param = "q" "=" ( "0" | "1" | float)
language = <ISO 639の定義による。ただし大文字、小文字の区別は
しない。>
dialect = <ISO 3166の定義による。ただし大文字、小文字の区別は
しない。>
Acceptフィールドと同様に、質的因子qを指定できるが、この場合はユーザーへの
理解度のレベルを表現する。デフォルトの値は、q=1である。定義自体は、言語パラ
メータの重複を禁止していないが、解釈は不定である。使用法の例を挙げる。
Accept-Language: dk, en/gb; q=0.5
意味には、「もし存在すれば、デンマーク語版を送ってくれ。そうでなければ、
英国英語版を送ってくれ」である。
Accept-Lanuageが存在しなければ、クライアントはすべての自然言語を質的因子1
で受け付けると仮定される。サーバーが指定された言語でサービスができない場合や
多言語オブジェクトボディーのサブセットを表現するだけの場合には、指定されない
言語でリクエストに答えても謝りとはいえない。"*"文字は、いかなる言語のいかな
る方言を表現するのに使われる。
注意： 理解度は、個々のユーザーに高く依存するので、クライアントプログ
ラムではユーザーが言語の好みを選択できるようにしておくことを勧める。
6. レスポンス
クライアントがHTTPリクエストを出した場合に、サーバーのレスポンスは以下の
ような構成のものになる。
Response = Simple-Response | Full-Response
Simple-Response= [Object-Body]
Full-Response = Status-Line ; 6.1節参照
*General-Header ; 4.3節参照
*Response-Header ; 6.4節参照
*Object-Header ; 7節参照
CRLF
[ Object-Body ] ; 3.2節参照
シンプルレスポンス(Simple-Response)は、HTTP/0.9のシンプルリクエスト
(Simple-Request)に返答するものでなくてはならない。シンプルレスポンスは、
リクエストされたオブジェクトのみからなっていることとサーバがコネクション
を切ることにより終了するということに注意すべきである。
6.1 ステータスライン
ステータスライン（Status-Line）は、プロトコールバージョンとそれに続く、
数字のステータスコードとそれに関連した言葉からなっており、それぞれの要素
はスペースで区切られている。最後のCRLF列以外には、CRやLFが入ることは許さ
れない。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
6.2 HTTPバージョン（HTTP Version）
HTTPバージョン要素は、サーバーで使用されるプロトコールのバージョンを指定
する。このフィールドのフォーマットは、5.3節で記述された対応するリクエスト
ラインのHTTP-Versionフィールドと同じである。
6.3 ステータスコード（Status-Code）とその説明句（Reason-Phrase）
ステータスコードは、リクエストを理解し、それに答えようとした試みに対する
結果を示す３桁の整数のコードである。説明句は、ステータスコードへの短い説明を
与えること意図したものである。ステータスコードは、コンピュータによる使用、
説明句は人間による使用を意図して作成された。クライアントは、説明句を理由を
解釈する必要はないし、それを人間のユーザーへ示す必要もない。
Status-Code = 3DIGIT
Reason-Phrase = token *( SP token )
ステータスコードに関係なく、すべてのレスポンスは、オブジェクトヘッダーと
オブジェクトボディーの両方または片方を含んでよい。これは、リクエストされた
URIで参照されるオブジェクトまたはステータスコードを更に説明するためのオブ
ジェクトのどちらでもよい。後者の場合には、望ましいメディアタイプは、
"text/html"であるが、"text/plain"でもよい。
ステータスコードの最初に桁は、HTTPのレスポンスのクラスを定義している。
最後の２つの桁は、コードをカテゴリー化する役割は持たない。最初の桁には、
５つの値が存在している。
o 1xx: 未定義（将来の使用のために予約）
o 2xx: 成功 - リクエストされたアクションは、適切に受理され、
理解された。
o 3xx: リダイレクション（Redirection） - リクエストを完了するために
別の追加アクションがなされる必要がある。
o 4xx: クライアントエラー - リクエストに間違った構文があるか、または
実行がもともと不可能である。
o 5xx: サーバーエラー - サーバーは、リクエストを遂行できなかった。
数字のステータスコードの値及び対応する説明句の例を以下に示す。すべての
ステータスコードについて、どのメソッドへの結果かいうこととといかなるメタ
情報がHTTPヘッダーで要求されれているかということを記述する。
6.3.1 Successful 2xx
この状態コードのクラスは、クライアントのリクエストが適切に受理され、理
解されたことを示す。
200 OK
o メソッド: GET, HEAD, POST
o 要求されたメタ情報: なし
リクエストは満たされ、オブジェクトヘッダーがレスポンス中に返されるべき
である。GETの場合には、レスポンス中にオブジェクトボディーがなければなら
ない。
201 Created
o メソッド: POST, PUT
o 要求されたメタ情報: URI-header
これは、POSTが成功したことまたはPUTが新しいオブジェクトを作成したことを
示す。新しく作成されたオブジェクトは、レスポンス中のURI-headerフィールドで
返されたURIで参照可能である。このアクションは、いかなる場合でもオリジンサー
バー（または人間の介入）により失効し得る。従って、この状態コードは与えられた
URIでオブジェクトが利用可能でありつづけることを保証しない。
202 Accepted
o メソッド: GET, HEAD, PUT, POST, DELETE
o 要求されるメタ情報: なし
リクエストは、処理のために受理されたが、処理は完了していない。リクエス
トは、最終的に実行されるかどうか不明である。それは、実際に実行された段階で
不許可になるかもしれないからである。このような非同期的なアクションからス
テータスコードを再送付するための機構は存在しない。
203 Provisional Information
o メソッド: GET, HEAD, POST
o 要求されるメタ情報: なし
これはHTTP-header中のメタ情報がオリジンサーバーから利用可能な確定した
集合ではなく、ローカルまたはサードパーティーから集められたものであること
を示す。その集合は、オリジナルの部分集合（サブセット）でもスーパーセット
でもよい。例えば、リソースに関する注釈(annotation)などである。
204 No Response
o メソッド: GET, HEAD, POST
o 要求されるメタ情報 : なし
サーバーはリクエストを受けとったが返す情報がない。クライアントは同じ文書
を表示した状態のままでいる必要がある。このステータスコードは、主として文書
を表示したままの状態で、スクリプトへの入力を可能とするためのものである。
205 Deleted
o メソッド: DELETE
o 要求されるメタ情報: なし
DELETEメソッドは成功し、オブジェクトはサーバーから削除された。このアク
ションは、オリジンサーバーにおいていかなる時点でもつくがえされえる（例えば、
人間の介入により）。従って、このステータスコードはアクションが実際に
行なわれたということを保証するものではない。
206 Modified
o メソッド: PUT
o 要求されるメタ情報: なし
PUTメソッドは成功し、オブジェクトはサーバー上で更新された。このアクション
は、オリジンサーバーにおいていかなる時点でもつくがえされえる（例えば、人
間の介入により）。従って、このステータスコードはアクションが実際に行なわれた
ということを保証するものではない。
6.3.2 リダイレクション（redirection 3xx)
このステータスコードのクラスは、リクエストを実行するためにクライアントが
とる必要がある追加アクションを指定する。要求されたアクションは、通常ユー
ザーを煩わせることなくクライアントプログラムによって実行される。しかし、
このステータスコードは、GETまたはHEADメソッドのときのみに返されるようにす
ることを強く推奨される。
301 Moved Permanently
o メソッド: GET, HEAD, POST, PUT
o 要求されるメタ情報: URI-header, Location
オブジェクトは、新しいURIを割り当てられ、今後当該のオブジェクトに対する
参照はレスポンス中に返された新しいURIを用いて行なわなければならない。リンク
を編集する機能のあるクライアントは、可能な限りサーバーから返された新しいURI
へ自動的にリンクしなおすようにすることが推奨される。
注意: サーバーは、PUTやPOSTを用いたリクエストに対してもこのステータス
コードを返すことが可能である。しかしながら、これはリクエストが行われた発行さ
れた状態を変更する可能性があるため、ユーザーエイジェントはユーザーの確認なし
に自動的にリクエストをリダイレクトすべきでない。
302 Moved Temporarily
o メソッド: GET, HEAD, POST, PUT
o 要求されるメタ情報: URI-header, Location
リクエストされたデータは、一時的に異なったURIで存在している。リダイレク
ションは時に変更される可能性があるため、クライアントはユーザーからの将来
のリクエストにおいて、このリクエストで使用されたオリジナルのURIを使用し続け
るべきであり、URI-headerフィールドで返されたURIを用いるべきではない。
注意: サーバーは、PUTやPOSTを用いたリクエストに対してこのステータスコ
ードを返すことが可能である。しかしながら、これはリクエストが発行された状態を
変更する可能性があるため、ユーザーエイジェントはユーザーの確認なしに自動的に
リクエストをリダイレクトすべきでない。
303 Method
o 要求されるメタ情報: なし
このコードは現在は意味をもたない。
304 Not Modified
o メソッド: 条件付きGET
o 要求されたメタ情報: none
クライアントが、条件つきのGETリクエストを行ない、アクセスが許されたが、
If-Modified-Sinceフィールドで指定された日付、時間から文書が変更されていな
い場合には、サーバーはこのステータスコードを返す。この場合、オブジェクト
ボディーをクライアントに送るべきではない。レスポンス中のメタ情報は、キャッ
シュ管理プログラムに関連した情報とオブジェクトのLast-Modified日付に独立に
変更される可能性のあるものに限るべきである。関連のあるヘッダーフィールド
とは、例えばDate, Server, Expiresなどである。しかし、これらはすべて必須で
はない。
6.3.3 Client Error 4xx
4xxクラスのステータスコードは、クライアントがエラーを起こしたと推測され
る場合を示すことを意図している。これらのコードは、5.2節のすべてのメソッド
に対して発生し得る。以下のものからなる。
400 Bad Request
o 要求されたメタ情報: なし
リクエストは、誤った構文を持っているか、またはもともと実行が不可能である。
クライアントが、修正なしにリクエストを繰り返す適切でない。
401 Unauthorized
o 要求されたメタ情報: WWW-Authenticate
サーバーは、6.4.2節で示すような認証法(authorization scheme)を含む
WWW-Authenticateヘッダーフィールドを返さなくてはならない。このヘッダー
フィールドには、クライアントがオブジェクトボディーを取得できるように少な
くとも１つの認証スキーマが必要である。クライアントは、再び適切な
Authorizationヘッダーフィールドをつけてリクエストを送り直すべきである。HTTP
のアクセス認証スキーマは、９章で説明されている。
402 Payment Required
o 要求されたメタ情報: なし
このコードは現在サポートされていないが、将来の使用のために予約されている。
403 Forbidden
o 要求されるメタ情報: なし
クライアントには知らされない理由により、リクエストは禁止されている。アク
セスは不可能であり、リクエストは繰り返されるべきではない。このステータス
コードは、サーバーがクライアントの認証が不完全なためにリクエストを実行でき
ないか、またはオブジェクトが存在しないために実行できないかを明らかにしたく
ない場合にも使用される可能性がある。
404 Not Found
o 要求されるメタ情報: なし
サーバーは、与えられたURIにマッチするものを見つけられなかった。これが、
一時的なものか、または恒久的なものであるかの情報は与えられない。
405 Method Not Allowed
o 要求されるメタ情報: Allow
リクエストラインで指定されたメソッドは、URIで指定されたオブジェクトに
対して許可されていない。サーバーは、7.1節で説明してある妥当なメソッドのリスト
を含むヘッダーをかえすべきである。
406 None Acceptable
o 要求されるメタ情報: Content-Type, Content-Encoding,
Content-Language
サーバーが、与えられたURIに適合するオブジェクトをみつけたが、Accept、
Accept-Encoding、Accept-Languageリクエストヘッダーで指定された条件のうち
少なくともどれかに適合していない。レスポンスは、少なくともContent-Type、
Content-Encoding、Content-Lanaugeを含まなくてはならないが、すべてのメタ
情報を含むようにすることが推奨される。オブジェクトボディーを、レスポンス
に入れることはできない。
407 Proxy Authentication Required
o 要求されるメタ情報: Proxy-Authenticate
このコードは、"401 Unauthorized"と同等であるが、ユーザーエージェントは、
6.4.2節に述べたProxy-Authenticateヘッダーフィールドを返さなくてはならない。
このヘッダーフィールドには、クライアントがプロキィーを利用できるように少な
くとも１つの認証法が必要である。クライアントは、これを用いて、サー
バーへの経路上のプロキシーと適当なProxy-Authorizationヘッダーフィールドを
伴った新しいリクエストを作成する必要がある。HTTPアクセスの認証法は、
９章で説明されている。
408 Request Timeout
o 要求されるメタ情報: なし
このコードは、サーバーが待ち得る時間内にクライアントがリクエストを送るこ
とができなかったことを示す。クライアントが、リクエストをまだ作成しているの
であれば、サーバーへ更に情報を送ることのを直ちに止めなければならない。
6.3.4 Server Errors 5xx
５で始まる状態コードは、サーバーがエラーの発生、またはリクエストが実行で
きないことをを検知しているかことを示す。これらのコードは、いつでもどのメ
ソッドを使用した場合でも発生しえる。
注意: 5xxコード（サーバーエラーの発生）のすべてについて、一時的な
エラーであっても恒久的なものであっても、サーバーはHTTPヘッダーとエラーの
状況を示すオブジェクトボディーを送ることが推奨される。
500 Internal Server Error
サーバーは、リクエストを実行することを妨げる予期しない状況に遭遇した。
501 Not Implemented
サーバーは、リクエストを実行するために要求された機能をサポートしていない。
502 Bad Gateway
これは、"500 Internal Server Error"と同等であるが、他のサービスへのゲー
トウウエイまたはプロキシーの場合において使用され、他のサービスからのレスポ
ンスが妥当でないことを示す。クライアントとHTTPの交信という観点からみると、
他のサービスはゲートウエイまたはプロキシーの中に隠蔽されているので、これは
"500 Internal Server Error"と同等に扱うことができるが、診断的な意味を有し
ている。
503 Service Unavailable
o 要求されるメタ情報: Retry-After
サーバーは、リクエストを取り扱うことが現在できない。これは、サーバーコン
ピュータまたはサーバーサービスが高負荷の際に起こり得る。これは一時的な状態
であり、Retry-Afterヘッダーで示される時間の後には緩和されるであろうことを
示す。レスポンス中にRetry-Afterヘッダーが存在しなければ、クライアントはレ
スポンスを"500 Internal Server Error"と同等に扱う必要がある。
504 Gateway Timeout
これは、"500 Internal Server Error"と等価であるが、ゲートウエイまたはプロ
キシーが他のサービスをしている場合には、これは他のサービスからのレスポンス
がゲートウエイの指定した時間内に得られないことを意味している。クライアント
とHTTPの交信という観点からは、他のサービスはゲートウエイとプロキシーに隠蔽
されているので、これは"500 Internal Server Error"と同じに取り扱ってよいが、
診断的な価値を持っている。
6.4 Response Header Fields
レスポンスヘッダーフィールドは、サーバーがステータスラインに記述すること
ができないレスポンスについての付加的な情報を送ることができるようにしたもの
である。これらのヘッダーフィールドは、レスポンスのオブジェクトボディーにつ
いてではなく、サーバー自身についての情報を与えることを意図している。
Response-Header= Server
| WWW-Authenticate
| Proxy-Authenticate
| Retry-After
未知のヘッダーフィールドは、オブジェクトヘッダーフィールドと解釈される
べきである。
6.4.1 Server
サーバーヘッダーフィールドは、リクエストを処理するオリジンサーバーで使用
されているソフトウエアについての情報を含むものである。このフィールドは、
User-Agentフィールドと類似のもので、以下のようなフォーマットを持っている。
Server = "Server" ":" 1*( product )
例:
Server: CERN/3.0 libwww/2.17
レスポンスがプロキシーによりフォワードされている場合には、プロキシーソフ
トウエアはこのリストに自身のデータを加えてはならない。その代わりに4.3.3節で
記述されているForwardedフィールドを加えるべきである。
6.4.2 WWW-Authenticate
WWW-Authenticateヘッダーフィールドは、クライアントからのリクエストに対
して、サーバーが"401 Unauthorized"ステータスコードを、９章で記述してある基
本認証法にもとづいて返す際に、レスポンス中に入れておかなければならない。この
ヘッダーは、使用されている認証スキーマとリクエストされたURIが所属するセキュリ
ティー区分(realm)を指定する。
WWW-Authenticate = "WWW-Authenticate" ":" (
( "Basic" realm )
| ( extension-scheme realm ) )
realm = "Realm" "=" 1#( "<" URI ">" )
このフィールドの最初の語は、使用されている認証法を示し、保護されて
いるURIのセキュリティー区分がその後に続く。セキュリティー区分は、コンマで区
切られたURIのリストであり、相対的なURLはリクエストライン中でリクエストされ
たリソースのURIからの相対位置を示すと解釈されるべきである。リクエストが認証
され、セキュリティー区分が指定されると、User-IDとパスワードはこのセキュリ
ティー区分内へのすべてのリクエストに対して効力を有する。
注意: セキュリティー区分は、複数のオリジンサーバーにまたがってもよい。
6.4.3 Proxy-Authenticate
WWW-Authenticateヘッダーフィールドは、クライアントからのリクエストに対し
て、プロキシーが"407 Proxy Authentication Required"ステータスコードを返す際
にレスポンスの中に入れておく必要がある。このヘッダーフィールドは使用されて
いる認証法とプロキシーのセキュリティー区分(realm)を指示する。
Proxy-Authenticate = "Proxy-Authenticate" ":" (
( "Basic" realm )
| ( extension-scheme realm )
WWW-Authenticateと異なり、Proxy-Autheticateは、現在のコネクションのみに
適用され、次の段階のユーザーエイジェントやプロシーには転送されない。
6.4.4 Retry-After
Retry-Afterヘッダーフィールドは、"503 Service Unavailable"とともにリクエ
ストを送ってきたクライアントにどのくらい後までサービスが利用できないと予想
されるかを通知する。このフィールドの値は、HTTP-dateで示される時刻でもよい
し、レスポンスがあってからの時間を10進法の秒数で表現したものでもよい。
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
delta-seconds = 1*DIGIT
利用法の例を２つ示す。
Retry-After: Wed, 14 Dec 1994 18:22:54 GMT
Retry-After: 120
後者の例では遅延は2分である。
7. オブジェクトヘッダーフィールド
フルリクエストとフルレスポンスメッセージは、オブジェクトヘッダーフィール
ドとオブジェクトボディーを含むことができる (3章で定義しているように)。 こ
の章では、オブジェクトヘッダーフィールドの形式と内容を定義する。
Object-Header = Allow
| Content-Length
| Content-Type
| Content-Encoding
| Content-Transfer-Encoding
| Content-Language
| Expires
| Last-Modified
| URI-header
| Location
| Version
| Derived-From
| Title
| Link
| extension-header
extension-header=HTTP-header
この章の記述中のレシピエントとは、クライアントとサーバーのオブジェクトを
受けとる側の方を意味する。これはリクエストとレスポンスによって異ってくる。
各々のオブジェクトヘッダーは、以下の節で説明してある。この他のヘッダー
フィールドも使用も可能であるが、レシピアントに認識可能であると想定すべきで
はない。未知のヘッダーフィールドは、レシピアントに無視されるが、フォワード
されるのであればそのまま送られる。
7.1 Allow
"Allow"は、リクエストされたURIによって同定されるオブジェクトでサポートさ
れているメソッドをリストする。このフィールドの目的は、オブジェクトの対する
正当なメソッドをレシピアントに厳密に伝えることにある。これは、クライアント
が他のメソッドを使用することを妨げるものではないが、このフィールドで指定さ
れたメソッドを使用することが推奨される。このフィールドは、デフォルトの値が
ない。もしこのフィールドがなければ、許容される方法はリクエストがあった時点
でのオリジンサーバーによって決定される。
Allow = "Allow" ":" 1#method
使用例:
Allow: GET, HEAD, PUT
注意: １つまたは複数のメソッドを理解しないプロキシーを介してレ
スポンスが伝えられる場合には、そのプロキシーはAllowヘッダーを変更して
はならない。というのは、ユーザーエイジェントは、オリジンサーバーと別
の経路で通信を行なってきたかもしれないからである。
7.2 Content-Length
Content-Lengthヘッダーフィールドは、レシピアントに送られるオブジェクト
ボディーの大きさ（10進法でオクテット（バイト）単位）を示す。HEADメソッド
の場合には、GETメソッドを用いた場合に送られてくるであろうオブジェクトの
大きさを表す。
Content-Length = "Content-Length" ":" 1*DIGIT
以下に例を挙げる。
Content-Length: 3495
この仕様では義務づけていないが、アプリケーションはオブジェクトのメディア
タイプに関係なく転送されるオブジェクトボディの大きさをこのフィールドを用
いて指定することを強く推奨する。
0以上のいかなる値もContent-Lengthとして意味のある値である。もしContent-
Lengthが記述されていなければ、オブジェクトボディーの長さはメディアタイプ
（マルチパートタイプが使われている場合）、Content-Encoding（区切りつきエ
ンコーディングが用いられている場合）、またはサーバーからのコネクションの
切断により決定される。しかしながら、多くのアプリケーションは、マルチーパー
トタイプや区切りつきエンコーディングを処理できないので、妥当なContent-Length
は、一般にPUTやPOSTリクエストに含まれるオブジェクトに対して要求される。
注意: このフィールド意味は、これに対応するMIMEのフィールドの仕様と
大きく異なっている。MIMEでは、"message/external-body"というContent-Typeの
中で使用されるオプションのフィールドであるが、HTTPでは、転送前にオブジェク
トの大きさがわかれば使用すべきである。
7.3 Content-Type
Content-Typeヘッダーフィールドは、レシピアントに送られるオブジェクトボ
ディーのインターネットメディアタイプ（4.2節に記述されている）を示す。HEAD
メソッドでは、GETメソッドを用いたら送られてくるはずのメディアタイプを表す。
Content-Type = "Content-Type" ":" media-type
フィールドの例を挙げる。
Content-Type: text/html; charset=ISO-8859-1
拡張トークンよりも、IANAに登録されているメディアタイプを使用するのが、
望ましい。しかし、HTTPは、HTTPに対応したアプリケーションが正式に登録され
たメディアタイプのみを使用するように強制することはないし、またお互いに合
意のとれたアプリケーションの間での短期間の実験的な使用を除けば、非公式な
タイプに用いる「x-」プレフィックスの使用を積極的に勧めるものでもない。
データの供給者は、RFC 1590[13]に記述してある手続きでIANAにメディアタイ
プを登録することを強く勧める。
Content-Typeヘッダーフィールドには、デフォルトの値はない。メディアタイ
プがわからない場合に限って、受け手はオブジェクトボディーの内容と、オブ
ジェクトへのアクセスに使用されたURLとファイル名の拡張子の両方またはどちら
かからメディアタイプを推測しようとしてよい。それでもメディアタイプがわか
らなければ、受け手はそれを"application/octet-stream"として扱うべきである。
7.4 Content-Encoding
Content-Encodingヘッダーフィールドは、HTTPに独自のものであり、メディア
タイプの変換のために使用される。もし存在すれば、その値はメッセージに入れ
る前に関連するオブジェクトボディに適用されるエンコード法を示すが、これは
Content-Typeヘッダーフィールドで参照されるメディアタイプを得るために適用
されたデコード法を示すことにほかならない。これは、メディアタイプの同一性
を失うことなく、オブジェクトの圧縮を行なうことを第１の目的として使用される。
Content-Encoding = "Content-Encoding" ":" encoding-mechanism
使用法の例を示す。
Content-Encoding: x-gzip
このフィールドを、次に示すContent-Transfer-Encodingと混同してはならない。
Content-Transfer-Encodingの目的は、「転送の際に受理可能な方法でオブジェク
トを表現するための変換の方法を示すこと」にある。これに対して、Content-
Encodingは、データの保存と転送の両方またはどちらか一方のために有利な場合に
転送前に行なわれる圧縮、暗号化、パッケージ化等のすべての変換方法を指定する。
エンコード化された情報は、通常バイナリーであるが、Content-Transfer-
Endocingにより規定されるいかなるタイプであってもよい。
7.5 Content-Transfer-Encoding
すべてのHTTPによる通信は、８ビットクリーンな環境で行なわれるため、デフォ
ルトのContent-Transfer-Encodingはバイナリーである。これは、MIME[4]で規定さ
れているデフォルトと異なることに注意して欲しい。つまりHTTPとMIMEの仕様に
準拠したプロトコールのゲートウエイでは、Content-Transfer-Endodingが存在し
ない場合には、明示的に"Content-Transfer-Encoding: binary"をメッセージヘッ
ダーに付け加えなければならない。
Content-Transfer-Encoding = "Content-Transfer-Encoding" ":"
cte-mechanism
cte-mechanism = token
7.6 Content-Language
Content-Languageフィールドは、オブジェクトボディーで使用される自然言語の
種類を記述する。このフィールドは以下のように記述される。
Content-Language = "Content-Language" ":" 1#lang-dia
lang-dia = language ["/" dialect ]
その使用例は以下のとおりであり、メッセージはデンマーク語で方言については
特定されていない。
Content-Language: dk
次の例は、デンマーク語と英国英語であることを示す。
Content-Language: en/gb, dk
このヘッダーは、多言語のオブジェクトボディーの場合には、langdiaコードを
用いて記述できる。 この仕様書は、オブジェクトボディーの中で異った自然言語が
表現できるような拡張の手段を指定するものではない。
注意： このフィールドは、テキスト文書のみではなく、音や他のメディア
のために使用されることも意図して定義されている。オブジェクトボディーの
"text/*"タイプに限定されたものと考えてはならない。
Content-Languageヘッダーがない場合には、クライアントはレスポンスとして
返ってくるオブジェクトボディーの言語について仮定するべきではない。なぜな
らそれは中間言語(language-neutral)または多言語の文書かもしれないからである。
7.7 Expires
Expiresフィールドには、その情報が妥当性をもたなくなる日付と時刻を与える。
そのコピーをローカルに保存ある場合には、もう一度検索しなおす必要がある。この
フィールドは、キャッシュメカニズムの制御を可能とするが、日付と時刻はオリジ
ナルのオブジェクトが存在しなくなる時点を必ずしも意味しない。このフィールド
は完全にサーバーによって制御される。フォーマットは、4.1節で定義された絶対
日付／時刻である。形式表現は以下の通りである。
Expires = "Expires" ":" HTTP-date
以下に用例を示す。
Expires: Thu, 01 Dec 1994 16:00:00 GMT
注意: このフィールドは、動的または一時的なデータの自動更新のためにも
使用できる。しかし、これはオブジェクトの期限が切れた時に自動的に新しいリク
エストをおくるクライアントの実装に完全に依存している。
データを生成するプロセスやスクリプトによって生成されたオブジェクトは、
その性質からして動的に変化することが多い。従って、そうしたオブジェクトを含む
レスポンスには、Expiresヘッダーフィールドをいれておくことが強く推奨される。
7.8 Last-Modified
Last-Modifiedヘッダーフィールドは、送り手の把握しているオブジェクトの
最終変更日付／時刻を示す。このフィールドの正確な意味は、受け手がそれをど
のように解釈すべきかという観点から定義されている。受け手がLast-Modified
フィールドのた日付／時刻よりも前のオブジェクトのコピーを持っていれば、そ
のコピーはこのオブジェクトの旧版であるとみなされる。
Last-Modified = "Last-Modified" ":" HTTP-date
使用法の例を示す。
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
このヘッダーの正確な意味は、送り手の実装により決まる。ファイルについては、
それが更新された最後の日付である。動的に取り込まれる部分を持つものについて
は、構成要素の中で最後に更新されたものの日付になるかもしれない。データベー
スゲートウエイに対しては、レコードのタイムスタンプかもしれない。仮想オブジェ
クトについては、最後に内部状態が変化したときかもしれない。どの場合でも、
レシピアントは、Last-modifiedヘッダーがどのようなものであるにしろ、その結果を
知る（心配する）だけで、それがどのように得られたか検討すべきではない。
7.9 URI Header
URI-headerフィールドは、オブジェクトが存在すると想定されるURIを示す。
5.4節のリクエストラインで示したトークンと混同してはならない。通常のリク
エストでは、指定されたURIでそのリソースがアクセスできることは保証されて
いない。このフィールドは、通常、"301 Moved Permanently"または
"302 Moved Temporarily"というステータスコードをもつレスポンスに含まれる。
URI-header = "URI" ":" 1#( "<" URI ">" [ ";" vary ] )
vary = "vary" "=" <"> 1#vary-param <">
vary-param = "type" | "language" | "version" | "encoding"
| "user-agent" | extension-vary
extension-vary = token
このフィールドに指定されたURIは、[9]で規定されているリクエストライン中
のURIへの絶対表現でも相対表現でもよい。
URIが複数の派生物を指している場合は、派生物が異なっている次元を派生
パラメーターで与えなければならない。varyフィールドのvary-paramが複数
出現した場合には、オブジェクトへの別のアクセス名やアドレスが与えられる。
このフィールドの例を挙げる。
URI: <http://info.cern.ch/hypertext/WWW/TheProject.multi>;
vary="type,language"
これは、指定されたURIがメディアタイプと使用言語の異なった複数のリソースを
持っていることを意味する。クライアントは、Accept, Accept-Encoding,
Accept-Language, and Versionなどのリクエストヘッダーフィールドを用いて
これらの中でどのオブジェクトがレスポンスとして返ってくるかを指定できる。
もう１つの例を挙げる。
URI: <http://info.cern.ch/hypertext/WWW/TheProject.ps>;
vary="encoding"
これは、URIで参照されるリソースがContent-Encodingフィールドで定義される
異なったエンコード法で存在することを示す。
7.10 Location
Locationヘッダーは、URI-headerの以前の形式であり、すでに意味をなさなく
なっている。しかしながら、HTTP/1.0のクライアントとサーバーは、古いアプリ
ケーションと適切に交信するためにこのヘッダーをサポートすべきである。Location
ヘッダーの意味は、URI-headerと同じであるが、派生形の使用はできず、ただ１つ
の絶対的位置を示すURIの指定のみが許されている。
Location = "Location" ":" URI
例を挙げる。
Location: http://info.cern.ch/hypertext/WWW/NewLocation.html
7.11 Version
Versionフィールドは、オリジンサーバー中で改訂がなされているオブジェクト
の現在の内容を示すバージョン番号を示す。7.12節で記述するDerived-Fromフィー
ルドとともに、グループが同時に何度もオブジェクトを作り直していくことを可能
としている。このフィールドは、特定の仕事の単一の道筋による更新を示す。関連
した派生的な仕事や異なった表現法を指定するために用いるべきではない。
Version = "Version" ":" *text
注意: このフィールドは、PUTメソッドがリクエスト中に指定したURIで
指し示すオブジェクトに対して許容されたメソッドである場合には、レスポンス
中に存在しなければならない。しかし、このフィールドの存在がPUTが許されて
いるかどうか示すものと考えてはならない。
7.12 Derived-From
Derived-Fromフィールドには、更新が繰り返されるリソースについての、転送を行
なうアプリケーションの存在する場所における最新のValueフィールドの値を記述
する。このフィールドの値は、Versionフィールドの値と同一の形式でなればならない。
Derived-From = "Derived-From" ":" *text
このフィールドの定義により、更新を繰り返すリソースの異なったバージョン
をいっしょに取り扱うことのできるコード管理システムを、サーバーとクライア
ントの両方が構築することが可能となった。Versionフィールドに関しては、
Derived-Fromフィールドは、数々のリソース更新の道筋の中で特定の１つの道筋
を示すためだけに使用されてよい。派生した仕事や異なった表現法を指定するため
に使用するべきではない。
注意: この定義により、異なったコードを管理するシステムの作成が可能
となる。必要なことは、内部で改版されるシステムとDerived-FromとVersionで定
義される版との間の整合的なマッピングだけである。
7.13 Title
このヘッダーフィールドは、文書のタイトルを示す。タイトルは、オブジェクト
の１部とはみなされない。このフィールドの定義は以下の通りである。
Title = "Title" ":" *text
このフィールドと、RFC 822で記述された"Subject"フィールドを比較すると、
前者がリソースの作者により定義されるものであり、後者が情報の発信者によっ
て定義されるものである点が異なる。このフィールドは、HTML[16]の<TITLE>要素
と同様の形のものと考えるべきである。
7.14 Link
Linkヘッダーは、HTTPオブジェクトの間の関係を記述する手段として使用される。
オブジェクトは、複数のLink要素を持つことが可能であり、典型的には階層構造
のような関係を表現する。このフィールドは、意味的にHTML文書の<LINK>タグと
同等である。
Link = "Link" ":" 1#("<" URI ">" [ ";" "REL" "=" relation ] )
relation = "UseIndex" | "UseGlossary" | "Contents"
| "Next" | "Previous" | "Parent"
| "BookMark" | "Made" | "Help"
Link関係の意味に関する詳しい説明がHTML仕様書[16]に出ているので参考にす
るとよい。
Link: <http://info.cern.ch/previous>; REL="Previous"
Link: <mailto:timbl@info.cern.ch>; REL="Made"
最初の例は、このオブジェクトが論理的にURIで同定される前のオブジェクトと
連続していることを示している。２つ目は、オブジェクトの作成者のメールアドレス
を示している。
注意: HTMLのメタ情報要素（<BODY>ではなく、<HEAD>の中で記述可能なも
ののこと）はすべてHTTPオブジェクトヘッダーの候補にしてもよいのではないかと
いうことが提案されてきた。この文書では、この中の２つの例であるLinkとTitle
というフィールドを定義した。
8. HTTPのネゴーシエイションアルゴリズム
ネゴシエイションアルゴリズムの最終的な目的は、多次元のパラメーターを１次
元空間に射影することであり、計算された重みはリソースの「劣化の程度」の指標
を表現する。最大値を実現するパラメーターの集合は、オブジェクトボディーが最
適な条件でクライアントに返されるようなメディアタイプを表現する。
オブジェクトボディーが特定のメディアタイプの特定のメディアタイプに変換さ
れた場合の質の低下の程度に絶対値を割り当てることが可能であると想定する。これ
は主観的な指標であり、実際は関心の対象となる文書によっても変わるが、単なる
表現法の関数としてこの劣化指標を定義できるという仮定をおいた。
更にオブジェクトをみるためのユーザーのコストが、情報を表現するため使われる
時間の関数であるという仮定もおいておく。まず、コストは時間の線形関数であると
仮定し、更に時間はオブジェクトの大きさの関数であると仮定した。
計算された重みは、0から9まで（0が最小、9が最大）の実数に規格化した。この
仕様書では、アルゴリズムに以下のパラメーターを定義している。
q クライアントアプリケーションの特定のメディアタイプで表現されたオブ
ジェクトボディーの劣化のレベルを表現する質的因子
qs qと同等であるが、サーバーがメディタイプの変換を行なうときに使われる。
デフォルト値は、qs=1である。
mxb クライアントで受理可能なオブジェクトボディーの最大の大きさ。デフォ
ルトは、mxb=undefined（無限大）である。
bs オブジェクトボディーの実際の大きさ。メディアタイプとエンコード法の
関数である。この値は、Content-Lengthフィールドで送られる値に等しい。
デフォルトは、bs=0である。
コストを計算する離散関数は、以下のように定義されれている。
{ if mxb=undefined, then (qs * q) }
Q(q,qs,mxb,bs) = { if mxb >= bs, then (qs * q) }
{ if mxb < bs, then 0 }
関数Qの最大値は、クライアントにオブジェクトボディをおくるために望ましい
メディアタイプを表現する。
このネゴーシエイションアルゴリズムまたはその派生型、もしくはその両方を
使用することは義務ではない。しかし、帯域幅の大きな節約になるため使用する
ことがつよく推奨される。細かな決定アルゴリズムの必要性がないようにすべきで
ある。というのは、多くの場合異ったフォーマットの違いは大きく、どちらが望ま
しいかははっきりしているからである。
注意： このアルゴリズムは、ゲートウエイまたはプロキシーで行なわれるメ
ディアの変換の負荷については考慮していない。これは重要な問題ではあるが、
クライアントとサーバーの間での交信でゲートウエイやプロキシーが透過的であ
ることを維持することの方が重要であると考えたからである。
9. 基本アクセス認証法
ここで述べる基本アクセス認証法は、HTTPサーバー上のリソースの不正な
アクセスを制限する方法として十分とはいえない。クライアントとサーバーの
コネクションが信頼するに足る伝送経路から成り立っているという前提に基づい
ているからである。この前提は、インターネットでは一般的に事実ではないので、
このことを知った上で基本アクセス認証法を使用するべきである。しかし、クラ
イアントは基本アクセス認証法を用いるサーバーと交信するためにこの機能を
実装すべきである。
基本アクセス認証法では、クライアントはオリジンサーバーの機能としての
user-ID、パスワード、サーバー上のセキュリティー区分を用いて自分自身を
認証しなければならない。サーバーは、URIとして同定されたリソースの属する
セキュリティー区分のuser-IDとパスワードを妥当と認めた場合にのみ、リクエ
ストに答えるべきである。サーバー上の保護されたリソースは、異なったパス
ワードファイルを持つセキュリティー区分に分類することができる。これは、
異なったセキュリティー区分に対して異なったユーザーがアクセスできるよう
にするためである。
典型的な認証のリクエストは、以下の２つのプロファイルのうちのどちらかで
ある。
o クライアントがAuthorizationフィールドなしに文書へのリクエストを送る。
o サーバーは、6.3.3節で記述されている "401 Unauthorized"というステータス
コードとWWW-Authenticateヘッダーフィールドを送る。
o クライアントは、既にWWW-Authenticateヘッダーフィールドの有効なuser-IDと
パスワードを知っているか、またはユーザーに入力するように促す。
o クライアントは、 Authorizationヘッダーフィールドを含む新しいリクエスト
を送る。
o サーバーはこれに答えて、要求されたオブジェクトを送信する。
以上例では、クライアントは最初のリクエストの前には認証情報をもっていな
い。以下の例では、サーバーから指定されるセキュリティー区分への以前のリクエ
ストに基づく情報をクライアントが持っている。
o クライアントは、Authorizationヘッダーをつけて文書を要求する。
o サーバーは、要求されたオブジェクトを送ることにより答える。
このHTTPの仕様では、同様な枠組もしくは付加的なヘッダーフィールドの使用
により、他の認証法を実装することが可能である。しかし、他の認証法を、この
仕様に従うアプリケーションがサポートしていることを想定すべきではない。
クライアントは、リクエストするリソースのURIがauthorizationヘッダーフィー
ルドにより妥当であるとされたセキュリティー区分内にあることが確認された後は、
２つ目の方法だけを用いることが望まれる。もしセキュリティー区分が指定されて
いないのであれば、２つめのアプローチは、以前のリクエストから区分がわかる場
合にのみ用いるべきである。
1.2節で記述したように、この仕様書では個々のリクエストの後にコネクションを
閉じることを要求していない。しかし、TCPのトップレベルでHTTPが用いられる場合
には、１番目と２番目のリクエストの間でコネクションを切ることを勧める。
proxyは、基本認証法については完全に透過的であるべきである。つまり、proxy
は、WWW-AuthenticateヘッダーとAuthorizationヘッダーの内容を変更してはならな
い。もしproxyがサーバーへ転送される前にクライアントを認証したいのであれば、
Proxy-AuthenticateヘッダーとProxy-Authorizationヘッダーを使用することができる。
10. 登録管理機関（Registration Authority）
HTTP登録管理機関は、以下のリストを保守する責任がある。
o 認証の方法(９節で述べてある)
o HTTPリクエストとレスポンスで使われるメソッドの意味
o データフォーマットの名前(MIMEのContent-TypesまたはInternet Media Types
として)
o データのコード化法の名称(MIMEのContent-Encodingとして)
Internet Assigned Numbers Authority(IANA)[15]または、それを受け継いだ組織が
この役割をはたすことを提案されている。
11. セキュリティーへの配慮
この章では、アプリケーションの開発者、情報提供者、利用者に対して、HTTP/1.0
のセキュリティー上の限界を伝えることを意図している。ここでの議論は、明らかに
なった問題への決定的な解決法を含んではないが、セキュリティー上のリスクを減少
させるためのいくつかの提案を行なっている。
11.1 クライアントの認証
９章で言及したように、HTTP/1.0の基本認証法は、ユーザー認証の方法として安
全とはみなされていないし、媒体として使われる物理ネットワークにおいてオブ
ジェクトボディーがテキストとしてそのままの形で転送されることを防ぐものでは
ない。プロトコールは、セキュリティーのレベルを上げるために、他の認証法や
暗号の導入を行なうことを許容している。
11.2 ユーザーの操作とネットワーク上で発生する行為
クライアントソフトウエアを書く人は、ソフトウエアがネットワーク上でのユー
ザーの行為を表現していることに注意すべきである。そして、ユーザーや他の人
にとって予期しない意味を持つ可能性のある動作については、事前にユーザーが
それについて意識できるように注意して実装すべきである。
特にGETとHEADは、その作用により何か意味のある行為を引きおこしてはならな
いという習慣が定着してきた。「ここをクリックすれば購読できます」（特別な
マジック文書を読むことをひきおこす）などというリンクは、「ここをクリック
すれば素敵な絵が見られます」などのような形で悪用されやすい。GETとHEADは
「安全」と考えられており、副作用をもつべきでない。このことは、クライアン
トソフトウエアが他のメソッド（POST,PUTやDELETEのような）を特別なやりかた
で表現することを可能にするものであり、ユーザーはアクションがリクエスト
されたという事実を意識できるようにしている。
11.3 サーバーのログ情報の悪用
サーバーは、リクエストのあった情報についての個人情報を保管する立場にある。
この情報は、その性格からして明確な機密情報であり、その取り扱いはいくつかの
国では法による制約を受ける。サーバーの提供者は、公表された情報から特定可能な
すべての個人の許諾なくして配布されないように気をつけるべきである。
この場合、RefererとFromの２つのヘッダーフィールドに特に注意が必要である。
Refererフィールドにより、読み込みのパターンの検討や逆リンクを張ることが
可能となる。それ自体は非常に有用であるが、Refererに含まれる情報がユーザー
に関する詳細情報と分離されていない場合には悪用される可能性がある。たとえ
個人情報が削除されていたとしても、Refererフィールドは機密文書のURIを示し
ているかもしれない。その開示は、それ自体セキュリティーの侵害となるであろう。
Fromフィールドで送られる情報は、ユーザーのプライバシーや各サイトのセ
キュリティーポリシーと間で摩擦をひきおこすかもしれない。このため、リクエ
ストを送る前にユーザーがFromフィールドの送付を停止したり、開始したり、こ
のフィールドの内容を変更したりできるようになっていない場合には、この
フィールド転送するべきではない。
12. 謝辞
この仕様は、拡張BNF記法とDavid H. Crockerによって作成されたRFC 822[7]の
一般構文(generic constructs)をかなり多用している。同様にNathaniel Borenstein
とNed FreedによるMIME [4]によって作成されたContent-Typeの定義を再利用してい
る。これらの利用により、HTTP/1.0とインターネットメールの間の関係にかつて見
られた混乱が減少することを望んでいる。
HTTPプロトコールは、過去の３年の間に大変な発展を遂げた。これは、大きく
活発な開発者のコミュニティ、即ちwww-talkメーリングリストへ参加した多くの
人たちによるものである。このコミュニティこそ、HTTPとWWWの成功へもっとも貢
献してきた人たちである。Marc Andreessen, Dan Connolly, Ari Luotonen,
Rob McCool, Dave Raggett, Tony Sanders, Marc VanHeningenのこの仕様の初期
の版のおけるプロトコールの定義への努力は、特記するに値する。Bob Dennyは、
この仕様の校正を援助し、更にほとんど書きなおすまでに文書をなおしてくれた。
13. 参考文献
[1] F. Anklesaria, M. McCahill, P. Lindner, D. Johnson, D. Torrey,
and B. Alberti. "The Internet Gopher Protocol: A distributed
document search and retrieval protocol." RFC 1436, University
of Minnesota, <URL:http://ds.internic.net/rfc/rfc1436.txt>,
March 1993.
[2] T. Berners-Lee. "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web." RFC
1630, CERN, <URL:http://ds.internic.net/rfc/rfc1630.txt>,
June 1994.
[3] T. Berners-Lee, L. Masinter, and M. McCahill. "Uniform Resource
Locators (URL)." Internet-Draft (work in progress), CERN, Xerox
PARC, University of Minnesota, <URI:http://ds.internic.net/
internet-drafts/draft-ietf-uri-url-08.txt>, October 1994.
[4] N. Borenstein and N. Freed. "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies." RFC 1521, Bellcore,
Innosoft, <URL:http://ds.internic.net/rfc/rfc1521.ps>,
September 1993.
[5] K. Moore. "MIME (Multipurpose Internet Mail Extensions) Part
Two: Message Header Extensions for Non-ASCII Text." RFC 1522,
University of Tennessee,
<URL:http://ds.internic.net/rfc/rfc1522.txt>, September 1993.
[6] R. Braden. "Requirements for Internet hosts - application and
support." STD 3, RFC 1123, IETF,
<URL:http://ds.internic.net/rfc/rfc1123.txt>, October 1989.
[7] D. H. Crocker. "Standard for the Format of ARPA Internet Text
Messages." STD 11, RFC 822, UDEL,
<URL:http://ds.internic.net/rfc/rfc822.txt>, August 1982.
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
Functional Specification." (v1.5), Thinking Machines Corp.,
<URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>,
April 1990.
[9] R. T. Fielding. "Relative Uniform Resource Locators."
Internet-Draft (work in progress), UC Irvine,
<URL:http://ds.internic.net/internet-drafts/
draft-ietf-uri-relative-url-02.txt>, November 1994.
[10] M. Horton and R. Adams. "Standard for interchange of USENET
messages." RFC 1036 (Obsoletes RFC 850), AT&T Bell
Laboratories, Center for Seismic Studies,
<URL:http://ds.internic.net/rfc/rfc1036.txt>, December 1987.
[11] B. Kantor and P. Lapsley. "Network News Transfer Protocol: A
Proposed Standard for the Stream-Based Transmission of News."
RFC 977, UC San Diego, UC Berkeley,
<URL:http://ds.internic.net/rfc/rfc977.txt>, February 1986.
[12] J. Postel. "Simple Mail Transfer Protocol." STD 10, RFC 821,
USC/ISI, <URL:http://ds.internic.net/rfc/rfc821.txt>, August
1982.
[13] J. Postel. "Media Type Registration Procedure." RFC 1590,
USC/ISI, <URL:http://ds.internic.net/rfc/rfc1590.txt>, March
1994.
[14] J. Postel and J. K. Reynolds. "File Transfer Protocol (FTP)."
STD 9, RFC 959, USC/ISI,
<URL:http://ds.internic.net/rfc/rfc959.txt>, October 1985.
[15] J. Reynolds and J. Postel. "Assigned Numbers." STD 2, RFC 1700,
USC/ISI, <URL:http://ds.internic.net/rfc/rfc1700.txt>, October
1994.
[16] T. Berners-Lee, D. Connolly, et al. "HyperText Markup Language
Specification - 2.0." Internet-Draft (work in progress), CERN,
HaL Computer Systems,
<URL:http://www.ics.uci.edu/pub/ietf/html/>, November 1994.
[17] US-ASCII. "Coded Character Set - 7-Bit American Standard Code
for Information Interchange." Standard ANSI X3.4-1986, ANSI,
1986.
14. 著者のアドレス
Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Tel: +1 (617) 253 9670
Fax: +1 (617) 258 8682
Email: timbl@w3.org
Roy T. Fielding
Department of Information and Computer Science
University of California
Irvine, CA 92717-3425, U.S.A.
Tel: +1 (714) 824-4049
Fax: +1 (714) 824-4056
Email: fielding@ics.uci.edu
Henrik Frystyk Nielsen
World-Wide Web Project
CERN,
1211 Geneva 23, Switzerland
Tel: +41 (22) 767 8265
Fax: +41 (22) 767 8730
Email: frystyk@w3.org
付録
以下の付録は、情報提供の目的だけのためにつけてある。従って、HTTP/1.0の
仕様の一部ではない。
A.（プロトコルからの若干の逸脱に）寛容なアプリケーション
アプリケーションがこの仕様に完全に合致しているかどうか検証することは適切
ではあるが、現実のアプリケーションは仕様からの逸脱を許容するようにすること
が推奨される。この付録は、許容が求められるもっとも重要な話題について述べる。
A.1 リクエストライン、ステータスライン、ヘッダーフィールド
クライアントによるステータスラインの解析とサーバーによるリクエストライ
ンの解析にはある程度の仕様からの逸脱が許容されるべきである。特にフィール
ドの間の区切りは、仕様上はSPが１つだけと決められているが、SPやHTABがいく
つあっても処理できるようにするべきである。
HTTPヘッダーの行末は、CRLFである。しかし、ヘッダーを解析するときにアプ
リケーションプログラムは、LFが単独であらわれた場合にも行末と認識し、また
LFの前に複数のCRがある場合には無視するべきである。
意味がわからないHTTPヘッダーは、4.3.4節に記述されているMandatoryフィー
ルドにリストされているものを除いては無視するべきである。
URIには、派生的な文字記号（その具体的な表現は国毎の派生的な文字セット
により異なる）、区切り文字及びスペース文字を使用しないで表現することを
推奨する。こうすることにより、必要が生じた場合に（例えば、ハイパーテキ
ストでないシステム介してデバッグや転送を行なう場合等）人間がURIを取り扱
うことを容易にする。
Content-Typeヘッダーがオブジェクトヘッダーには存在しない場合に、望まし
い動作は、オブジェクトボディーの最初の部分をみてメディアタイプを推測する
ことである。この仕様書では、メディアタイプを判断するアルゴリズムを提供し
ていない。メディアタイプがわからない場合には、アプリケーションはファイル
の拡張子（URLが利用可能な場合）から判断してもよいし、デフォルトのタイプで
ある"application/octet-stream"を利用してもよい。
A.2 オブジェクトボディー
HTTPを用いて転送された場合には、メディアのタイプに関係なくオブジェクトボ
ディーを正準形(cannonical form)に変換することは要求されていないので、クラ
イアントは"text/*"タイプのオブジェクトボディーを解析する場合にかなり寛容
に対処しなければならない。以下の記号が、行末記号として認識されるようにす
ることが推奨される。
CR, LF, CRLF
もし行の終了がCRCFであれば、CRは無視されるべきである。
A.3 後ろ向きの互換性
サーバーは、シンプルリクエストの受けつけとシンプルレスポンスの生成をでき
るようにすべきである。フルリクエストが推奨されれてはいるものの、多くのクラ
イアントはシンプルリクエストで十分目的を果たすことができる。汎用目的のクラ
イアントプログラムでは、HTTP/0.9サーバーと交信するためにシンプルリクエスト
を生成し、シンプルレスポンスを理解できるようにすることが望まれる。
関連記事
- プログラムでもっとも正確に日本の祝日を求める方法(内閣府公表CSVの過去3度の改訂履歴)
- FAT(File Allocation Table)ファイルシステムの仕様 FAT16 FAT32 exFAT VFAT
- SDカード・microSDカードの規格
- Raspberry Pi 4 Model Bのチップ・無線LANアンテナ
- Raspberry Pi Zero WHのチップ・無線LANアンテナ(大きなチップはCPUではありません)
- 各ストレージの速度一覧 規格速度や実効速度(HDD/SSD/M2/NVMe/USBメモリ)
- メールテキストの1行の文字数制限(最大1,000文字、78文字以下であるべき)
- サイトマップ(sitemap.xml)のつくり方とちょっとしたテクニック
- Mobile Network Code(MNC)の一覧[V-Z]
- Mobile Network Code(MNC)の一覧[T-U]
- Mobile Network Code(MNC)の一覧[S]
- Mobile Network Code(MNC)の一覧[O-R]
- Mobile Network Code(MNC)の一覧[M-N]
- Mobile Network Code(MNC)の一覧[J-L]
- Mobile Network Code(MNC)の一覧[H-I]
- Mobile Network Code(MNC)の一覧[E-G]
- Mobile Network Code(MNC)の一覧[C-D]
- Mobile Network Code(MNC)の一覧[A-B]
- Mobile Country Code(MCC)の一覧
- コードページの一覧
- オープンソースライセンスの一覧と日本語訳(全52種類)
- ASCIIコード表
- IPアドレス サブネットマスク プレフィックス 早見表
- [暗号化]ブロック暗号とは(AES/DES/Blowfish PKCS5Padding ECB/CBC IV)
- 文字実体参照(実体参照)の一覧
- 各地域、各国に割り振られているIPアドレス
- トラックバックの仕様
- webサイト巡回ツールのユーザーエージェント一覧
- whoisに表示されるステータス一覧
- Whoisサーバー一覧
- IANAによる文字コードの定義
- UTFとは
- 文字コード表(コード対応表) 0x0-0x4
- 文字コード表(コード対応表) 0x5-0x6
- 文字コード表(コード対応表) 0x7-0x8
- 文字コード表(コード対応表) 0x9-0xA
- 文字コード表(コード対応表) 0xB-0xC
- 文字コード表(コード対応表) 0xD-0xF
- インターネット初期に日本に割り振られたIPアドレス一覧
- 画面解像度の一覧
- Perl互換の正規表現(PCRE)に関する仕様
- HTTP/1.0
- 文字コード表(EUC-JP) [12836/12836]
- 文字コード表(Unicode UTF-8 UTF-16) [21420/21420]
- 文字コード表(コード対応表) 0xF
- 文字コード表(コード対応表) 0xE
- 文字コード表(コード対応表) 0xD
- 文字コード表(コード対応表) 0xC
- 文字コード表(コード対応表) 0xB
- 文字コード表(コード対応表) 0xA
- 文字コード表(コード対応表) 0x9
- 文字コード表(コード対応表) 0x8
- 文字コード表(コード対応表) 0x7
- 文字コード表(コード対応表) 0x6
- 文字コード表(コード対応表) 0x5
- 文字コード表(コード対応表) 0x4
- 文字コード表(コード対応表) 0x3
- 文字コード表(コード対応表) 0x2
- 文字コード表(コード対応表) 0x1
- 文字コード表(コード対応表) 0x0
- 文字コード表(Unicode UTF-8 UTF-16) [14000/21420]
- Unicode文字のブロックの範囲
- 文字コード表(EUC-JP) [6000/12836]
- 文字コード表(JIS)
- 文字コード表(Shift-JIS)
- 文字コード表(Unicode UTF-8 UTF-16) [7000/21420]
- RFC
- 電車路線、駅の一覧
- Google Developers
- Rainmeter
- Git
- fail2ban
スポンサーリンク
