この頁では、HTTPに関するRFCを日本語訳したリソースを公開しています。
以下は、[Studying HTTP] のRFC日本語訳を利用するにあたっての注意事項です。 以下に同意される場合のみ、日本語訳をご利用下さい。 なお、以下の同意事項は予告なく変更される場合がありますので、常に最新の内容をご確認いただきますようお願いいたします。
各日本語訳文書、及びそれに適用されるスタイルシートの著作権は、このサイトを管理・運営する橋本英彦 (H-Hash) に帰属します。 これらの一部または全部を、当方に無断で営利目的で使用する事を禁じます。 上記目的で使用したい方、及び各文書についてのご質問・ご要望などがございましたら、管理人までお問い合わせください。
正式なるRFCは英語版のみです。 当サイトのものに限らず、一般にRFCを日本語訳したものはそのRFCの参考に過ぎず、従ってそのリソース中の全ての情報は、その正確性・有効性は保証されません。 特に、技術的必要性から以下の日本語訳を参照する場合は、必ず原典にてご確認下さい。
日本語訳のフォーマットは、XHTML 1.1とHTML 4.01の2種類を用意しています。 また、内容コーディングとして“gzip”が利用可能です。 http://www.studyinghttp.net/rfc_ja/rfcXXXX（但し、“XXXX”はRFC番号）にアクセスすると、HTTP ヘッダの内容をネゴシエーションする事により適切なリソースを返します。
日本語訳が難しい、あるいは一般的でない用語などは、差分エンコーディング {delta encoding}のように、英単語を併記しています。 原典内の“MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, “OPTIONAL”各キーワード（これらの意味については、RFC 2119を参照）にあたる日本語は、その語を<em>要素にて強調マークアップしています。 原典内のヘッダ、フッタ、改ページ制御文字などは削除しています。
[Studying HTTP] のRFC日本語訳を無変更のまま配布する行為は、条件付で認めます。 ここで、「[Studying HTTP] のRFC日本語訳」とは、以下のリソースを指します。
(※) 本文書（http://www.studyinghttp.net/rfc_ja/）を含めた、上記以外の当サイト内のリソースの扱いは全て著作権についてに記述されている通りです。
「[Studying HTTP] のRFC日本語訳を無変更のまま配布する場合」とは、以下のような行為を指します。
各日本語訳の配布は、該当文書に一切の改変を加えない事を条件とします。 ただし、これは原文から新たな日本語訳を作成し公開することを妨げるものではありません。 また、これは各日本語訳を適切な範囲で引用することを妨げるものではありません。
各日本語訳は、現時点のものであり、不定期に更新される可能性があります。 配布をする場合は、その内容を定期的に確認し、極力古い日本語訳を公開しないように努め、これができないのであればURIの紹介に留めて下さい。 各日本語訳へのURIとしては、以下のうちいずれかを使用して下さい。
メディアタイプを限定したURI（例：http://www.studyinghttp.net/rfc_ja/rfc2616.ja.xhtml.gz）は推奨しません。 禁止もしませんが、その場合もその形式が存在するかを定期的に確認し、これができないのであればコンテントネゴシエーションが可能なURI（上記リストのうちいずれか）を使用して下さい。
ここでは、HTTPに関するRFCを独自に日本語訳し、公開しています。 [Studying HTTP] のRFC日本語訳を利用する場合は、必ず「[Studying HTTP] の RFC日本語訳を利用するにあたって」をお読みいただき、同意の上でご利用下さい。
現在のハイパーテキスト転送プロトコル（HTTP）ヘッダフィールドで用いられる文字セットは、ISO-8859-1（ASCIIの拡張）しかありません。 本書では、上記文字セットにに含まれない文字を使用するために、UTF-8を使用できる仕組みを提案しています。
現在のハイパーテキスト転送プロトコル（HTTP）では、リソースの書き換えを行うためのメソッドとしては、「リソースの完全な置き換え」を行うPUTメソッドしかありません。 本書では、既存のHTTPリソースに対して「リソースの部分的な修正」を行うために、新たなHTTPメソッドであるPATCHを提案しています。
この文書は、現在までに RFC やそれ以外の仕様書で提案されてきた HTTP ヘッダフィールドを集積し、IANA レポジトリとして登録する事を目的としています。
Uniform Resource Identifier (URI) は、抽象的あるいは物理的なリソースを識別するための簡潔な文字列です。 この仕様書は、一般的な URI の構文と相対的形式である URI 参照を解決するための手順を定義し、更にインターネット上での URI の使用のついての指針やセキュリティについての考察を示します。 URI の構文では、全ての妥当な URI の上位集合{superset} である文法を定義し、実装が取り得る全ての識別子についてのスキーム特有な必要条件を知らなくても URI 参照の共通の構成要素{component} を解析する事を可能にします。 その代わり、この仕様書では各 URI の生成文法は定義されません。 その作業は各 URI スキームについてのそれぞれの仕様書が行います。
Common Gateway Interface (CGI) は、プラットフォームに依存しない方法で情報サーバのもとで、外部プログラム、ソフトウェア、ゲートウェイを動かするための単純なインタフェースであり、1993 年以来 World Wide Web (WWW) にて広く使用されています。 この仕様書は、the U.S. National Centre for Supercomputing Applications にて開発、文書化された 'CGI/1.1' インタフェースの '現在の慣習' のパラメータを定義し、UNIX ® や、他の同様のシステム上での CGI/1.1 インタフェースの使用方法も定義します。
"アダルト" や "安全でない" データ等のために、例えば .sex や .xxx といった特別なトップレベルドメインや IP アドレスのビットの使用を要求するような提案が定期的に出てきますが、この文書では、法的、哲学的、そして特に技術的視点から、何故これが有害とされる考えなのかを示します。
この文書では、MIME ボディ部分や Web 文書等で使用されている自然言語を示すための Content-Language ヘッダ、及びそれらリソースのうちより望むものを識別したい場合に使用するための Accept-Language ヘッダを定義します。
HTTP/1.1 では、サーバがレスポンスボディのダイジェストを含む事ができる Content-MD5 ヘッダを定義していますが、このレスポンスが Content-Range だったり、差分エンコーディングを使用していた場合、これらは全く異なるものになるでしょう。 また、Content-MD5 は一つの特定のダイジェストアルゴリズムに限定されており、場合によっては、例えば SHA-1 (Secure Hash Standard) のような他のアルゴリズムを使ったほうがいいかもしれません。 更に、HTTP/1.1 ではクライアントがダイジェストを要求できるような明示的なメカニズムが提供されていないのです。 この文書では、これらの問題を解決するための HTTP の拡張を提案します。
多くの HTTP リクエストは、クライアントが既にキャッシュエントリに保持しているようなリソースのわずかに修正されたインスタンスを取得するため行われます。 そのような更新は頻繁に行われており、またその修正部分のだいたいは実際のエンティティよりも非常に小さいものです。 そのような場合、もし記述の変更部分の最低限を転送できれば、リソースの新しいインスタンス全体を転送するよりも、効率的にネットワーク帯域幅を使用できるでしょう。 これを差分エンコーディング{delta encoding}と呼び、その差分エンコーディングが HTTP/1.1 と互換性を持つ拡張としてどのようにサポートされるかを記述します。
最近、他のアプリケーション層のプロトコルのための (特にファイル転送の処理するための) 基層{substrate} としてハイパーテキスト転送プロトコル (HTTP) を使う事に広く関心が持たれてきていますが、この文書では、既定のポート、URL スキーム、HTTP セキュリティメカニズムの使用を含む、HTTP の使用についての技術的事項を推奨します。
この文書は、ある情報オブジェクト中に使用される自然言語 (例えば「日本語」や「英語」等) を示したい場合に使用する言語タグ、及びこの言語タグ中に使用される値や、そのような言語タグに一致しているようなものを登録する方法を記述します。
この文書は HTTP のリクエストとレスポンスの中で状態を持つセッションを構築する方法、具体的には Netscape の Cookie 提案を発展させたもので、RFC 2109 の実装による経験を反映し、更にそれを廃案にするものです。
"HTTP 状態管理メカニズム" は様々な目的のために使用できますが、ユーザのプライバシーやセキュリティに関わりを持つためにその使われ方のいくつかについては、議論を呼んでいます。 この文書は、(a) IETF によって推奨されていない、(b) 有害であり、やめるように考えられている、というようなハイパーテキスト転送プロトコル (HTTP) 状態管理プロトコルの特有の使い方を示します。
ユーザのブラウザに、どんな MIME タイプのハンドラがインストールされているか、例えば Internet Open Trading Protocol (IOTP) や VRML や SET やいくつかのストリーミングメディアのハンドラが利用可能かどうかを知りたい場合、現実的にどうすべきをかを示したものです。
この文書は、インターネット上の HTTP 接続をセキュアにするための TLS の使用法を記述します。 現在の慣例では、http 通信と https 通信は異なるサーバポート番号の使用によって区別されていますが、この文書はその用法について記述します。 この文書の対になる文書の RFC2817 では、通常の HTTP と同じポート番号 (通常 80) で HTTP/TLS を使用するための方法を記述しています。
この文書は、既存のTCP接続を通してトランスポート層セキュリティ（TLS）を始めるためのHTTP/1.1におけるUpgradeメカニズムの使い方を説明するものです。 これによって、全てのhttp/https通信を同じポート番号（通常80）にて行うことができます。 更に、RFC 2616にて予約だけされていたCONNECTメソッドについて具体的な定義を与えます。 最後に、この文書は、公的なHTTPステータスコードのための、及び公的・私的なUpgrade製品トークンのためのIANAレジストリを設立します。
HTTP の様々な拡張が提案されていますが、この拡張を定義するための標準の枠組みが無かったため、この文書は HTTP についての共通拡張メカニズムを記述し、非公式な合意と公式の仕様との間の均衡を知らしめ、HTTP を使っているアプリケーションの拡張をクライアント、サーバ、プロクシが用立てる事ができるようにするものです。
"HTTP/1.0" は、基本{Basic} アクセス認証スキームのための仕様を含んでいますが、このスキームは、ユーザー名及びパスワードが明文としてネットワーク上を通るので、(SSL のような外部のセキュアなシステムと併用されるのでなければ) ユーザ認証の方法として安全であると考える事はできません。 そこで、この文書はその基本認証スキームと、それに置き換わるべき "ダイジェスト{Digest} アクセス認証" と呼ばれる、暗号化ハッシュに基づくスキームを示すもので、これは RFC 2069 を置き換えるものとして意図されています。
HTTP は、分散・共同体ハイパーメディア情報システムのアプリケーションレベルプロトコルであり、World-Wide Web グローバル情報利用の先進として、1990 年から使われています。 それ以降、リクエストメソッド、エラーコード、ヘッダ等の拡張を経て、ネームサーバや分散オブジェクト管理システム等、ハイパーテキストのために使う以上に多くの作業のために用いる事ができる、一般的でステートレスなプロトコルです。 この仕様書は、"HTTP/1.1" と呼ばれるプロトコルを定義し、RFC 2068 を更新するものです。
この仕様書は、ユーザがフォームに入力したデータと、あるいはユーザが選択するファイルに含まれた情報を含んだフォームを記述した時に、それを様々なプロトコルによって転送できるようにするためにする、インターネットメディアタイプ multipart/form-data を定義します。
この文書は、HTTP を拡張した「コーヒーポットを制御、監視、診断するためのプロトコルである HTCPCP」 について記述された、いわゆるジョーク RFC です。
この文書は、HTTP リクエストを繰り返しても安全であるという事を示すために使用する事ができる Safe という HTTP レスポンスヘッダフィールドを定義するものです。 これによって、ユーザエージェントは、いくつかの安全なリクエスト、特に安全な POST リクエストの再試行を、よりユーザにやさしい方法で、扱えるようになるでしょう。
HTTP では、web サイトの作者が単一の URI に属する同じ情報の複数のバージョンを置く事を許していますが、透過的内容ネゴシエーションとは、そのURL がアクセスされた時に最善のものを自動的に選択するための仕組みです。 これによって、新たな web データフォーマットやマークアップタグを障害なく導入する事も可能になるでしょう。
この文書は、あらゆる MIME エンティティ ("message" あるいは "body part") においてオプショナルであり、MIME 仕様に従うメッセージが提示的情報{presentational information} を運ぶために使用できる、Content-Disposition ヘッダについて記述しています。 この文書は、RFC 1806 にて定義された試験的プロトコルの改訂版です。
HTTP リクエストとレスポンスの各メッセージは HTTP のプロトコルのバージョン番号を含んでいますが、その HTTP バージョン番号の適切な使用や解釈についていくつかの混乱があります。 この文書はその状況を明確にする事を目的としています。
多くの標準化過程文書において、いくつかの語がその仕様の要求度を示すために使われており、これらの語句はしばしば大文字で書かれています。 この文書は、これらの語句を IETF 文書において解釈されるべきように定義します。
この仕様書では、広く利用される GZIP ユーティリィティと互換性をもつような可逆圧縮のデータフォーマットを定義します。 このフォーマットは、データ改ざんの検知のための巡回冗長検査 (CRC) 値を含んでいます。 このフォーマットでは現在、圧縮に DEFLATE 方式を使用していますが、他の圧縮方式を使用するために容易に拡張する事ができます。 このフォーマットは、特許によって保護されない方法において容易に実装する事ができます。
現在、HTML のフォームによって、その製作者はフォームを読み込むユーザから情報を要求する事ができます。 この文書では、ファイルのアップロードは多くのアプリケーションに利益を与えるであろう機能なので、情報提供者が一定の形式でファイルアップロードの要求を表現できるようにするための HTML の拡張と、ファイルアップロードレスポンスのための MIME 互換の表現を提案します。 この提案は、これが組み入れられる HTML のバージョンとは無関係です。
IETF では、RFC が新規発行される毎に RFC INDEX というファイルを更新しています。 これは、その名の通り、RFC の目録となるファイルで、その冒頭部分は、RFC INDEX 内の記述の解説になっています。
このファイルは、全ての RFC について番号順に列挙したものを収めている。
RFC の列挙は、以下の形式で記述するものとする:
#### RFC の題名. 筆者 1, 筆者 2, 筆者 3. 発行日. (Format: ASCII) (Obsoletes xxx) (Obsoleted by xxx) (Updates xxx) (Updated by xxx) (Also FYI ####) (Status: ssssss)あるいは
#### 発行されず.例えば:
1129 Internet Time Synchronization: The Network Time Protocol. D.L. Mills. Oct-01-1989. (Format: TXT=298, PS=551697, PDF=197036 bytes) (Also RFC1119) (Status: UNKNOWN)この文書のキーポイント:
#### は RFC 番号を表す。
RFC 番号に続いて、題名、筆者、RFC 発行日である。 これらはそれぞれ、ピリオドで区切られる。
数に続いて、題名 (ピリオドで終わる)、筆者、あるいは複数筆者のリスト (ピリオドで終わる)、そして日付 (ピリオドで終わる) となる。
続いて、形式と長さが、丸括弧の中に記述される。 選択可能な形式が一つ以上列挙される: ASCII テキスト (TXT)、ポストスクリプト (PS)、Adobe(PDF)。 各形式は、等号とそのバージョンのバイト数を伴う。 例えば、(Format: TXT=aaaaa, PS=bbbbbb bytes) は ASCII テキストバージョンが aaaaa バイトであり、その RFC のポストスクリプトバージョンが bbbbbb バイトである事を示す。
Obsoletes xxxx は、この RFC が他の RFC を差し替える事を表し、Obsoleted by xxxx は、他の RFC がこの RFC を差し替えた事を表す。 Updates xxxx は、この RFC が他の RFC を単に更新する (しかし差し替えはしない) 事を表し、Updated by xxxx は、他の RFC がこの RFC を更新する (しかし差し替えはしない) 事を表す。 一般に、それに関連する歴史上の全ての過去あるいは未来の RFC ではなく、直近の後続する、あるいは先行する RFC のみが示される。
その RFC が同時に FYI、STD、BCP のいずれかの系列に含まれるものであれば、それに対応する FYI、STD、BCP 番号をもって (Also FYI ##) あるいは (Also STD ##) あるいは (Also BCP ##) の句が与えられる。 最後に、Status の欄は、その文書の現在の状態を示す (RFC 2026 参照)。
RFCs は、HTTP、FTP、あるいは電子メールといった、多くの方法を使用する事により入手できる。 RFC エディタ Web ページ http://www.rfc-editor.org 参照。
RFC INDEX には、現在発行されている全ての RFC についての情報が、番号順に載っています。 RFC 番号は 4 桁で記述されます。 番号が 1000 未満の場合は、その前に 0 が付加されます。 発行されていない RFC については、既に発行されない事が確定している場合「発行されず (Not Issued)」と明記されますが、番号のみ予約済みで発行予定のものについては、その番号が飛ばされています。
形式は、TXT, PS, PDF の一つ以上で利用可能とされていますが、ほとんどの RFC では TXT のみしか用意されていません。 但し、IETF Tools を利用する事で、TXT の RFC を HTML に変換する事が可能です。
RFC は時代の中で、置き換えられ、あるいは更新されます。 「Obsolete (廃案)」とは、ある仕様について記述された文書について、元文書ではなく、今後は新文書がその文書を指すという事を表します。 例えば、「HTTP/1.1 の仕様書」という場合、かつて RFC 2068 がそれを意味していた時代もありましたが、2008 年現在は RFC 2616 のみがそれに該当し、それ以外は「HTTP/1.1 の仕様書」とは呼ばないという事を意味しています。
一方、「Update (更新)」とは、ある仕様について記述された部分について、元文書の該当部分を破棄し、今後は新文書の該当部分がその仕様となるという事を示します。 例えば、「HTTP/1.1 の仕様書」のうち、「Upgrade ヘッダ」等、その一部の内容のみを置き換える事を目的にした文書である RFC 2817 が発行された場合が、これに該当します。 この場合、「HTTP/1.1 の仕様書」という言葉が指す文書は、RFC 2616 のままとなります。
Obsolete/Update についての情報は、直近の関連文書についてのみ記述される傾向にあります。 例えば、RFC 3066 は RFC 1766 を廃案し、また RFC4646 と RFC4647 によって廃案にされましたが、RFC 4646 及び RFC 4647 の欄には「RFC 3066 を廃案にした」事は書いてあっても、「RFC 1766 を廃案にした」事は書かれていません。
RFC は、その内容や状態によって、以下のように分類されています。
RFC は、HTTP 経由、FTP 経由、電子メール経由等様々な方法で手に入れることができます。 但し、現在ほとんどが Web ブラウザを利用して、HTTP あるいは FTP 越しに取得されています。
, All Rights Reserved.