17. References (参考文献)
17 参考文献
以下の参考文献は、RFC 原文の書誌情報をそのまま保持しています。引用の 正確性を損なわないため、著者名、文献表題、RFC 番号、出版情報および URL は英語の原表記に従います。
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D. and B. Alberti, "The Internet Gopher Protocol (a distributed document search and retrieval protocol)", RFC 1436, March 1993.
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC 1630, June 1994.
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1123, October 1989.
[9] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype Functional Specification," (v1.5), Thinking Machines Corporation, April 1990.
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[20] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[22] ISO-8859. International Standard -- Information Processing -- 8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin alphabet No. 1, ISO-8859-1:1987. Part 2: Latin alphabet No. 2, ISO-8859-2, 1987. Part 3: Latin alphabet No. 3, ISO-8859-3, 1988. Part 4: Latin alphabet No. 4, ISO-8859-4, 1988. Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988. Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987. Part 7: Latin/Greek alphabet, ISO-8859-7, 1987. Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988. Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, (original report dated Aug. 1996), USC/Information Sciences Institute, August 1998.
[28] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[30] S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html.
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997.
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[35] Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO-10646", RFC 2279, January 1998. [jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes France, September 1997.[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998. [jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers," Work in Progress. [jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997.
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
18 著者のアドレス (Authors' Addresses)
Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA
Fax: +1 (949) 824-1715 EMail: [email protected]
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA
EMail: [email protected]
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA
EMail: [email protected]
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
EMail: [email protected]
Tim Berners-Lee Director, World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Fax: +1 (617) 258 8682 EMail: [email protected]
19 付録 (Appendices)
19.1 Internet Media Type message/http and application/http (インターネットメディアタイプ message/http および application/http)
本ドキュメントは、HTTP/1.1 プロトコルを定義することに加えて、インター ネットメディアタイプ "message/http" および "application/http" の仕様と しての役割も果たします。message/http タイプは、行長およびエンコーディン グに関するすべての "message" タイプについての MIME 制約に従う限り、単一 の HTTP リクエストメッセージまたはレスポンスメッセージを包含するために 使用できます。application/http タイプは、1 つ以上の HTTP リクエストメッ セージまたはレスポンスメッセージのパイプライン (混在させないもの) を包含 するために使用できます。以下の内容が IANA [17] に登録されます。
Media Type name: message
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
Media Type name: application
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
version: The HTTP-Version number of the enclosed messages
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
Encoding considerations: HTTP messages enclosed by this type
are in "binary" format; use of an appropriate
Content-Transfer-Encoding is required when
transmitted via E-mail.
Security considerations: none
19.2 Internet Media Type multipart/byteranges (インターネットメディアタイプ multipart/byteranges)
HTTP 206 (Partial Content) レスポンスメッセージが複数の範囲のコンテンツ (重なり合わない複数範囲に対するリクエストへのレスポンス) を含む場合、 これらはマルチパートメッセージボディとして送信されます。この目的のための メディアタイプは "multipart/byteranges" と呼ばれます。
multipart/byteranges メディアタイプは 2 つ以上のパートを含み、各パートは それぞれ独自の Content-Type フィールドおよび Content-Range フィールドを 持ちます。必須の boundary パラメータは、各ボディパートを区切るために使用 される境界文字列を指定します。
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary
Optional parameters: none
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
例:
HTTP/1.1 206 Partial Content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
注:
1) エンティティ内において、最初の境界文字列の前に追加の CRLF が存在
してもかまいません。
2) RFC 2046 [40] は境界文字列を引用符で囲むことを許可していますが、
既存の実装の中には、引用符で囲まれた境界文字列を正しく処理しない
ものがあります。
3) 多くのブラウザおよびサーバは、byteranges 仕様の初期ドラフトに
基づいて実装され、メディアタイプ multipart/x-byteranges を使用
しています。これは HTTP/1.1 で文書化されているバージョンとほぼ
互換性がありますが、完全に同一ではありません。
19.3 Tolerant Applications (寛容なアプリケーション)
本ドキュメントは HTTP/1.1 メッセージの生成に関する要件を規定しています が、すべてのアプリケーションがその実装において正確であるとは限りません。 したがって、逸脱が一義的に解釈できる場合には、運用中のアプリケーションが その逸脱に対して寛容であることを推奨します。
クライアントは Status-Line の解析において寛容であるべきであり (SHOULD)、 サーバは Request-Line の解析において寛容であるべきです。特に、単一の SP のみが要求されている場合でも、フィールド間の任意の数の SP 文字または HT 文字を受け入れるべきです (SHOULD)。
メッセージヘッダフィールドの行終端子は CRLF のシーケンスです。ただし、 アプリケーションがそのようなヘッダを解析する際には、単一の LF を行終端子 として認識し、先頭の CR を無視することを推奨します。
エンティティボディの文字セットは、そのボディ内で使用される文字コードの 最小公分母としてラベル付けされるべきです (SHOULD)。ただし、エンティティ を US-ASCII または ISO-8859-1 というラベルでラベル付けするよりも、ラベル 付けしないほうが望ましいという例外があります。セクション 3.7.1 および 3.4.1 を参照してください。
日付の解析およびエンコーディングに関する要件、ならびに日付エンコーディン グに関するその他の潜在的な問題についての追加規則には、以下が含まれます。
- HTTP/1.1 クライアントおよびキャッシュは、50 年以上future (未来) に
あると思われる RFC-850 日付は、実際には過去のものであると想定すべき
です (SHOULD) (これは "西暦 2000 年" 問題の解決に役立ちます)。
- HTTP/1.1 実装は、解析された Expires 日付を内部的に適正な値よりも
早い時刻として表現してもかまいません (MAY) が、適正な値よりも遅い
時刻として内部的に表現してはなりません (MUST NOT)。
- すべての有効期限に関連する計算は GMT で行われなければなりません
(MUST)。ローカルタイムゾーンが、経過時間または有効期限時刻の計算
または比較に影響を与えてはなりません (MUST NOT)。
- HTTP ヘッダが誤って GMT 以外のタイムゾーンを持つ日付値を伝送して
いる場合、可能な限り保守的な変換を用いて GMT に変換されなければ
なりません (MUST)。
19.4 Differences Between HTTP Entities and RFC 2045 Entities (HTTP エンティティと RFC 2045 エンティティの相違点)
HTTP/1.1 は、エンティティが多様な表現形式かつ拡張可能なメカニズムに よって送信されることを可能にするため、インターネットメール (RFC 822 [9]) および Multipurpose Internet Mail Extensions (MIME [7]) のために定義され た多くの構成要素を使用しています。しかしながら、RFC 2045 はメールについ て論じており、HTTP には RFC 2045 に記述されているものとは異なるいくつか の機能があります。これらの相違点は、バイナリ接続上での性能を最適化し、 新しいメディアタイプの使用においてより大きな自由度を許容し、日付比較を 容易にし、また初期の一部の HTTP サーバおよびクライアントの慣行を追認する ために、慎重に選択されたものです。
この付録では、HTTP が RFC 2045 と異なる特定の領域について説明します。 厳格な MIME 環境へのプロキシおよびゲートウェイは、これらの相違点を認識し (SHOULD)、必要な場合には適切な変換を提供すべきです。MIME 環境から HTTP へのプロキシおよびゲートウェイも、いくつかの変換が必要となる可能性がある ため、これらの相違点を認識する必要があります。
19.4.1 MIME-Version
HTTP は MIME 準拠のプロトコルではありません。しかしながら、HTTP/1.1 メッセージは、メッセージの構築に使用された MIME プロトコルのバージョンを 示すために、単一の MIME-Version 一般ヘッダフィールドを含んでもかまいませ ん (MAY)。MIME-Version ヘッダフィールドの使用は、そのメッセージが (RFC 2045[7] で定義されている) MIME プロトコルに完全に準拠していることを 示します。プロキシ/ゲートウェイは、HTTP メッセージを厳格な MIME 環境に エクスポートする際に、(可能な場合には) 完全な準拠を保証する責任を負い ます。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME バージョン "1.0" が HTTP/1.1 における使用のデフォルトです。ただし、 HTTP/1.1 メッセージの解析とセマンティクスは、MIME 仕様ではなく本ドキュメ ントによって定義されます。
19.4.2 Conversion to Canonical Form (正規形への変換)
RFC 2045 [7] は、RFC 2049 [48] のセクション 4 に記述されているとおり、 インターネットメールエンティティが転送される前に正規形に変換されることを 要求しています。本ドキュメントのセクション 3.7.1 では、HTTP 上で送信され る場合の "text" メディアタイプのサブタイプに許可される形式について説明し ています。RFC 2046 は、"text" タイプのコンテンツが改行を CRLF として表現 することを要求し、改行シーケンス以外での CR または LF の使用を禁止して います。HTTP では、メッセージが HTTP 上で送信される場合、テキストコンテン ツ内の改行を示すために CRLF、単独の CR、および単独の LF を使用できます。
可能な場合には、HTTP から厳格な MIME 環境へのプロキシまたはゲートウェイ は、本ドキュメントのセクション 3.7.1 に記述されているテキストメディア タイプ内のすべての改行を、RFC 2049 の正規形である CRLF に変換すべきです (SHOULD)。ただし、これは Content-Encoding の存在により、また HTTP が一部 のマルチバイト文字セットの場合のように CR および LF を表現するためにオク テット 13 および 10 を使用しない文字セットの使用を許可しているという事実 により、複雑になる可能性があることに注意してください。
実装者は、元のコンテンツが既に正規形になっていない限り、変換によって元の コンテンツに適用された暗号学的チェックサムが破壊されることに注意すべきで す。したがって、HTTP でそのようなチェックサムを使用するコンテンツについて は、正規形が推奨されます。
19.4.3 Conversion of Date Formats (日付形式の変換)
HTTP/1.1 は、日付比較のプロセスを簡素化するために、限定された日付形式の 集合 (セクション 3.3.1) を使用します。他のプロトコルからのプロキシおよび ゲートウェイは、メッセージ内に存在するあらゆる Date ヘッダフィールドが HTTP/1.1 の形式のいずれかに準拠していることを保証し、必要な場合には日付を 書き換えるべきです (SHOULD)。
19.4.4 Introduction of Content-Encoding (Content-Encoding の導入)
RFC 2045 には、HTTP/1.1 の Content-Encoding ヘッダフィールドに相当する
概念は含まれていません。これはメディアタイプに対する修飾子として機能する
ため、HTTP から MIME 準拠プロトコルへのプロキシおよびゲートウェイは、
Content-Type ヘッダフィールドの値を変更するか、メッセージを転送する前に
エンティティボディをデコードするかのいずれかを行わなければなりません
(MUST)。(インターネットメール向けの Content-Type の実験的な適用の一部で
は、Content-Encoding と同等の機能を実行するために、メディアタイプパラメー
タ ";conversions=<content-coding>" が使用されてきました。しかしながら、
このパラメータは RFC 2045 の一部ではありません。)
19.4.5 No Content-Transfer-Encoding (Content-Transfer-Encoding の不使用)
HTTP は RFC 2045 の Content-Transfer-Encoding (CTE) フィールドを使用しま せん。MIME 準拠プロトコルから HTTP へのプロキシおよびゲートウェイは、 レスポンスメッセージを HTTP クライアントに配信する前に、非 identity の CTE ("quoted-printable" または "base64") エンコーディングをすべて除去し なければなりません (MUST)。
HTTP から MIME 準拠プロトコルへのプロキシおよびゲートウェイは、そのプロト コル上での安全な転送のために、メッセージが正しい形式およびエンコーディン グであることを保証する責任を負います。ここで "安全な転送" とは、使用され るプロトコルの制約によって定義されます。そのようなプロキシまたはゲート ウェイは、そうすることが宛先プロトコル上での安全な転送の可能性を高める 場合には、適切な Content-Transfer-Encoding をデータにラベル付けすべきです (SHOULD)。
19.4.6 Introduction of Transfer-Encoding (Transfer-Encoding の導入)
HTTP/1.1 は Transfer-Encoding ヘッダフィールド (セクション 14.41) を導入 します。プロキシ/ゲートウェイは、MIME 準拠プロトコル経由でメッセージを 転送する前に、あらゆる transfer-coding を除去しなければなりません (MUST)。
"chunked" transfer-coding (セクション 3.6) をデコードするプロセスは、 擬似コードで次のように表現できます。
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
19.4.7 MHTML and Line Length Limitations (MHTML と行長の制限)
MHTML [45] 実装とコードを共有する HTTP 実装は、MIME の行長制限を認識する 必要があります。HTTP にはこの制限がないため、HTTP は長い行を折り返しませ ん。HTTP によって転送される MHTML メッセージは、行長制限や折り返し、正規 化などを含む MHTML のすべての慣例に従います。これは、HTTP がすべての メッセージボディをペイロードとして転送し (セクション 3.7.2 を参照)、 その中に含まれる可能性のあるコンテンツや MIME ヘッダ行を解釈しないため です。
19.5 Additional Features (追加機能)
RFC 1945 および RFC 2068 は、一部の既存の HTTP 実装によって使用されている プロトコル要素を文書化していますが、これらはほとんどの HTTP/1.1 アプリ ケーションにおいて一貫して正しく実装されているわけではありません。実装者 はこれらの機能を認識しておくことが望まれますが、他の HTTP/1.1 アプリケー ションにおけるそれらの存在や相互運用性に依存することはできません。これら のうちいくつかは提案された実験的機能を記述しており、またいくつかは実験的 な配備によって不十分であることが判明し、現在では HTTP/1.1 基本仕様の中で 対処されている機能を記述しています。
Content-Disposition や Title など、SMTP および MIME に由来する他の多くの ヘッダも、しばしば実装されています (RFC 2076 [37] を参照)。
19.5.1 Content-Disposition
Content-Disposition レスポンスヘッダフィールドは、ユーザがコンテンツを ファイルに保存することを要求した場合に、オリジンサーバがデフォルトの ファイル名を提案するための手段として提案されました。この用法は、RFC 1806 [35] における Content-Disposition の定義に由来します。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
例を示します。
Content-Disposition: attachment; filename="fname.ext"
受信側のユーザエージェントは、filename-parm パラメータ内に存在するいかな るディレクトリパス情報も尊重すべきではありません (SHOULD NOT)。この パラメータは、現時点で HTTP 実装に適用されると考えられている唯一のパラ メータです。ファイル名は末端の構成要素としてのみ扱われるべきです (SHOULD)。
このヘッダが application/octet-stream の content-type を伴うレスポンスで 使用される場合、暗黙の提案は、ユーザエージェントがレスポンスを表示せず、 直接 `save response as...' ダイアログに入るべきだということです。
Content-Disposition のセキュリティ問題については、セクション 15.5 を参照 してください。
19.6 Compatibility with Previous Versions (以前のバージョンとの互換性)
以前のバージョンへの準拠を義務付けることは、プロトコル仕様の範囲を超えて います。しかしながら、HTTP/1.1 は以前のバージョンのサポートを容易にする よう意図的に設計されました。本仕様の作成時点 (1996 年) において、商用の HTTP/1.1 サーバには以下が期待されることに留意する価値があります。
- HTTP/0.9、1.0、および 1.1 リクエストの Request-Line の形式を認識
すること。
- HTTP/0.9、1.0、または 1.1 の形式による任意の有効なリクエストを理解
すること。
- クライアントが使用したものと同じメジャーバージョンのメッセージで
適切に応答すること。
また、HTTP/1.1 クライアントには以下が期待されます。
- HTTP/1.0 および 1.1 レスポンスの Status-Line の形式を認識すること。
- HTTP/0.9、1.0、または 1.1 の形式による任意の有効なレスポンスを理解
すること。
HTTP/1.0 のほとんどの実装では、各接続はリクエストに先立ってクライアントに よって確立され、レスポンスの送信後にサーバによって閉じられます。一部の 実装は、RFC 2068 [33] のセクション 19.7.1 に記述されている Keep-Alive バージョンの持続的接続を実装しています。
19.6.1 Changes from HTTP/1.0 (HTTP/1.0 からの変更点)
このセクションでは、HTTP/1.0 と HTTP/1.1 のバージョン間の主要な相違点を 要約します。
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses (マルチホーム Web サーバを簡素化し IP アドレスを節約するための変更)
クライアントおよびサーバが Host リクエストヘッダをサポートすること、 HTTP/1.1 リクエストから Host リクエストヘッダ (セクション 14.23) が欠落 している場合にエラーを報告すること、および絶対 URI (セクション 5.1.2) を 受け入れることという要件は、本仕様によって定義される最も重要な変更点の 一つです。
旧来の HTTP/1.0 クライアントは、IP アドレスとサーバとの間に一対一の関係が あると想定していました。リクエストの宛先となる IP アドレス以外に、その リクエストが意図するサーバを区別するための確立されたメカニズムは存在しま せんでした。上記に概説した変更は、旧来の HTTP クライアントが一般的でなく なった時点で、単一の IP アドレスから複数の Web サイトをサポートすることを インターネットにおいて可能にし、単一のホストへの多数の IP アドレスの割り 当てが深刻な問題を引き起こしている大規模運用 Web サーバを大幅に簡素化しま す。また、インターネットは、特殊用途のドメイン名をルートレベルの HTTP URL で使用できるようにするためだけに割り当てられてきた IP アドレスを回収でき るようにもなります。Web の成長率と既に配備されているサーバの数を考慮する と、HTTP のすべての実装 (既存の HTTP/1.0 アプリケーションへの更新を含む) が以下の要件を正しく実装することが極めて重要です。
- クライアントとサーバの双方が Host リクエストヘッダをサポートしなけ
ればなりません (MUST)。
- HTTP/1.1 リクエストを送信するクライアントは Host ヘッダを送信しなけ
ればなりません (MUST)。
- サーバは、HTTP/1.1 リクエストが Host リクエストヘッダを含まない場合、
400 (Bad Request) エラーを報告しなければなりません (MUST)。
- サーバは絶対 URI を受け入れなければなりません (MUST)。
19.6.2 Compatibility with HTTP/1.0 Persistent Connections (HTTP/1.0 持続的接続との互換性)
一部のクライアントおよびサーバは、HTTP/1.0 クライアントおよびサーバに おける持続的接続の以前の実装のいくつかとの互換性を望む場合があります。 HTTP/1.0 における持続的接続はデフォルトの動作ではないため、明示的に ネゴシエートされます。HTTP/1.0 の持続的接続の実験的実装には欠陥があり、 HTTP/1.1 の新しい機能はこれらの問題を是正するように設計されています。 問題は、一部の既存の 1.0 クライアントが、Connection を理解しないプロキシ サーバに Keep-Alive を送信している可能性があることでした。そのプロキシは それを次のインバウンドサーバに誤って転送し、そのサーバが Keep-Alive 接続 を確立した結果、HTTP/1.0 プロキシがレスポンスのクローズを待ってハングして しまいます。その結果、HTTP/1.0 クライアントはプロキシと通信する際に Keep-Alive を使用しないようにしなければなりません。
しかしながら、プロキシとの通信は持続的接続の最も重要な用途であるため、 そのような禁止は明らかに受け入れられません。したがって、Connection を 無視する旧来のプロキシと通信する場合でも安全に使用できる、持続的接続が 望まれていることを示すための別のメカニズムが必要です。持続的接続は HTTP/1.1 メッセージにおけるデフォルトです。非持続性を宣言するために、 新しいキーワード (Connection: close) を導入します。セクション 14.10 を 参照してください。
HTTP/1.0 における元の形式の持続的接続 (Connection: Keep-Alive および Keep-Alive ヘッダ) は、RFC 2068 に文書化されています。[33]
19.6.3 Changes from RFC 2068 (RFC 2068 からの変更点)
本仕様は、キーワードの用法を修正し曖昧さを解消するために慎重に監査されま した。RFC 2068 には、RFC 2119 [34] で規定された慣例に関して多くの問題が ありました。
インバウンドサーバの障害 (例: DNS 障害) に対してどのエラーコードを使用 すべきかを明確化しました。(セクション 10.5.5)
CREATE には、リソースが最初に作成された際に Etag が送信されることを要求 する競合状態がありました。(セクション 10.2.2)
Content-Base は仕様から削除されました。これは広く実装されておらず、堅牢 な拡張メカニズムなしにこれを導入する単純かつ安全な方法が存在しないため です。加えて、MHTML [45] においては類似しているが同一ではない方法で使用 されています。
transfer-coding とメッセージ長は、(自己区切りでない可能性のある転送 エンコーディングに対応するため) chunked エンコーディングがいつ使用される かを正確に修正することを要する形で相互作用します。メッセージ長がどのよう に計算されるかを正確に整理することが重要でした。(セクション 3.6、4.4、 7.2.2、13.5.2、14.13、14.16)
キャッシングで発見された問題を解決するために、"identity" の content-coding が導入されました。(セクション 3.5)
クライアントが表現を拒否できるようにするため、品質値ゼロは "それを望まな い" ことを示すべきです。(セクション 3.9)
HTTP バージョン番号の使用と解釈は RFC 2145 によって明確化されました。 HTTP/1.0 実装で発見された問題に対処するため、プロキシがサポートする最高 のプロトコルバージョンにリクエストをアップグレードすることを要求します。 (セクション 3.1)
accept ヘッダにおける文字セット名の爆発的増加を避けるため、文字セットの ワイルドカード指定が導入されました。(セクション 14.2)
HTTP/1.1 の Cache-Control モデルにおいて 1 つのケースが見落とされていま した。この欠落したケースを追加するために s-maxage が導入されました。 (セクション 13.4、14.8、14.9、14.9.3)
Cache-Control: max-age ディレクティブは、レスポンスに対して適切に定義され ていませんでした。(セクション 14.9.3)
サーバ (特にプロキシ) がレスポンスの完全な長さを知らないものの、 byterange リクエストに応じる能力を持つ状況があります。したがって、メッ セージの完全な長さを示さない content-range を伴う byterange を許可する メカニズムが必要です。(セクション 14.16)
すべてのメタデータが常に返されるとすれば、Range リクエストのレスポンスは 非常に冗長になります。206 レスポンスにおいてサーバが必要なヘッダのみを 送信できるようにすることで、この問題を回避できます。(セクション 10.2.7、 13.5.3、および 14.27)
満たすことのできない range リクエストに関する問題を修正しました。2 つの ケースがあります。構文上の問題と、その範囲がドキュメント内に存在しない 場合です。ドキュメントの実際の内容の範囲外となるバイト範囲リクエストに 対するエラーを示すために必要な、この曖昧さを解決するために 416 ステータス コードが必要とされました。(セクション 10.4.17、14.16)
ここでの誤りの結果がインターネットに重大な影響を及ぼす可能性があるため、 実装者が誤りを犯しにくくするよう、また以下の問題に対処するために、 メッセージ送信要件を書き直しました。
1. 将来のバージョンの HTTP/1.x の実装の動作に対して誤って要件を課して
いた文脈において、"HTTP/1.1 or later" を "HTTP/1.1" に変更しま
した。
2. リクエストを再試行すべきなのは一般的な "クライアント" ではなく、
ユーザエージェントであることを明確化しました。
3. 予期しない 100 (Continue) レスポンスをクライアントが無視すること、
およびプロキシが 100 レスポンスを転送することについての要件を、
1xx レスポンスに関する一般的な要件に変換しました。
4. HTTP にとって非 TCP のトランスポートも可能であることをより明確に
するため、TCP 固有の記述の一部を修正しました。
5. オリジンサーバが、必要な 100 (Continue) レスポンスを送信する前に
リクエストボディを待ってはならない (MUST NOT) ことを要求します。
6. サーバが既にリクエストボディの一部を受信している場合に、100
(Continue) を省略することを、要求ではなく許可とします。
7. サーバがサービス拒否攻撃および壊れたクライアントから防御できるよう
にします。
この変更により Expect ヘッダと 417 ステータスコードが追加されます。 メッセージ送信要件の修正は、セクション 8.2、10.4.18、8.1.2.2、13.11、 および 14.20 にあります。
プロキシは適切な場合に Content-Length を追加できるべきです。 (セクション 13.5.2)
403 レスポンスと 404 レスポンスの間の混乱を整理しました。(セクション 10.4.4、10.4.5、および 10.4.11)
警告が誤ってキャッシュされたり、適切に更新されなかったりする可能性があり ました。(セクション 13.1.2、13.2.4、13.5.2、13.5.3、14.9.3、および 14.46) また、PUT や他のメソッドがリクエストにおいて警告を必要とする可能性がある ため、Warning は一般ヘッダである必要がありました。
transfer-coding には、特に chunked エンコーディングとの相互作用において 重大な問題がありました。その解決策は、transfer-coding を content-coding と同等に本格的なものにすることです。これには、(content coding とは別の) transfer-coding のための IANA レジストリの追加、新しいヘッダフィールド (TE)、および将来的なトレーラヘッダの有効化が含まれます。転送エンコーディ ングは大きな性能上の利点をもたらすため、修正する価値がありました [39]。 TE はまた、認証トレーラ、chunked エンコーディング、および HTTP/1.0 クライアントの間の相互作用によって発生し得た、別の分かりにくい下位互換性 の問題も解決します。(セクション 3.6、3.6.1、および 14.39)
PATCH、LINK、UNLINK メソッドは本仕様の以前のバージョンで定義されていまし たが、一般的には実装されていませんでした。RFC 2068 [33] を参照してくだ さい。
Alternates、Content-Version、Derived-From、Link、URI、Public、および Content-Base ヘッダフィールドは本仕様の以前のバージョンで定義されていま したが、一般的には実装されていませんでした。RFC 2068 [33] を参照してくだ さい。
20 索引 (Index)
INDEX については、本 RFC の PostScript 版を参照してください。
- Full Copyright Statement (完全な著作権表示)
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.