858.txt

@@
[507] このページで紹介するのは、 [[HTTP]] の旧仕様である [[RFC 1945]]、
[[RFC 2068]]、[[RFC 2616]] です。 [[HTTP]] の現行仕様は [[RFC 7230]] 他です。

* 仕様書

[REFS[
- [506] [CITE@en[RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1]] ([TIME[2013-09-17 10:26:33 +09:00]] 版) <http://tools.ietf.org/html/rfc2616>
]REFS]

* 日本語訳

[4]
'''HTTP — Hypertext Transfer Protocol'''
[[RFC 1945]], [[RFC 2068]], [[RFC 2616]] の和訳


[3]
[DEL[
* RFC 1945 IESG Note:
> The IESG has concerns about this protocol, and expects this document
to be replaced relatively soon by a standards track document.

[[IESG]] はこのプロトコルについて懸念しており、
この文書が比較的早く[[標準化過程]]文書で置き換えられることを期待しています。
]DEL]

* Abstract
> The Hypertext Transfer Protocol (HTTP) is an application-level
protocol [DEL[[INS[{1945}]] with the lightness and speed necessary]]
for distributed, collaborative, hypermedia information systems. It is a generic,
stateless[DEL[, [INS[{1945,2068}]] object-oriented]] protocol which can be used for many tasks [INS[[INS[{2616}]] beyond its use for hypertext]], such as
name servers and distributed object management systems, through extension of its request methods [DEL[[INS[{1945}]] (commands)]][INS[, [INS[{2616}]] error codes and headers [47] ]]. A feature of HTTP is the typing [INS[[INS[{2068,2616}]] and negotiation]]
of data representation, allowing systems to be built independently of the data being transferred.

ハイパーテキスト転送プロトコル (HTTP) は、分散協調ハイパー媒体情報システム用[DEL[に必要な軽さと速さを備えた]]応用層プロトコルです。
HTTP は一般的で状態を持たない[DEL[オブジェクト指向の]]プロトコルであり、要求方式 [DEL[(命令)]] [INS[や誤り符号や頭群]]の拡張を通じて、[INS[ハイパーテキストのための使用にとどまらず、]]名前鯖や分散物体管理システムのような種々の仕事のために使うことができます。
HTTP の特徴はデータ表現の型付け[INS[および折衝]]であり、
これによって転送されるデータとは独立にシステムを構築できます。

> HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification [DEL[[INS[{1945}]] reflects common usage of the protocol referred to as "HTTP/1.0"]] [INS[[INS[{2068,2616}]] defines the protocol referred to as "HTTP/1.1"[INS[, and is an update to RFC 2068 [33] ]]]].

HTTP は World Wide Web 大域情報活動で 1990 年以来使われています。
この仕様書は [DEL[「HTTP/1.0」と呼ばれるプロトコルの共通の使用法を反映しています]] [INS[「HTTP/1.1」と呼ばれるプロトコルを定義[INS[しますが、この文書は RFC 2068 の更新であり]]ます。]]。

* 目次
= 1   Introduction ...................................................7
== 1.1    Purpose......................................................7
== 1.2   Requirements .................................................8
== 1.3   Terminology ..................................................8
--- 和訳 (部分) : [CODE(WikiPage)[[[接続]]]], [CODE(WikiPage)[[[メッセージ]]]], [CODE(WikiPage)[[[要求]]]], [CODE(WikiPage)[[[応答]]]], [CODE(WikiPage)[[[資源]]]], [CODE(WikiPage)[[[実体]]]], [CODE(WikiPage)[[[表現]]]], [CODE(WikiPage)[[[内容折衝]]]], [CODE(WikiPage)[[[変種]]]], [CODE(WikiPage)[[[クライアント]]]], [CODE(WikiPage)[[[利用者エージェント]]]], [CODE(WikiPage)[[[サーバー]]]], [CODE(WikiPage)[[[起源サーバー]]]],[CODE(WikiPage)[[[串]]]],  [CODE(WikiPage)[[[関門]]]], [CODE(WikiPage)[[[トンネル]]]], [CODE(WikiPage)[[[キャッシュ]]]], [CODE(WikiPage)[[[キャッシュ可能]]]], [CODE(WikiPage)[[[初手]]]], [CODE(WikiPage)[[[明示満期時刻]]]], [CODE(WikiPage)[[[発見的満期時刻]]]], [CODE(WikiPage)[[[齢]]]], [CODE(WikiPage)[[[新鮮寿命]]]], [CODE(WikiPage)[[[新鮮]]]], [CODE(WikiPage)[[[腐敗]]]], [CODE(WikiPage)[[[意味的透過]]]], [CODE(WikiPage)[[[検証子]]]], [CODE(WikiPage)[[[上流]]]], [CODE(WikiPage)[[[上り]]]]
== 1.4   Overall Operation ...........................................12
= 2   Notational Conventions and Generic Grammar ....................14
== 2.1   Augmented BNF ...............................................14
--- 参考 : [CODE(WikiPage)[[[HTTPのABNF]]]]
== 2.2   Basic Rules .................................................15
--- 和訳 : [CODE(WikiPage)[[[HTTP//メッセージ]]]]
--- 参考 : [CODE(WikiPage)[[[token]]]], [CODE(WikiPage)[[[tspecials]]]], [CODE(WikiPage)[[[quoted-string]]]], [CODE(WikiPage)[[[comment]]]], [CODE(WikiPage)[[[ctext]]]]
= 3   Protocol Parameters ...........................................17
== 3.1   HTTP Version ................................................17 [CODE(WikiPage)[[[HTTP-Version]]]]
== 3.2   Uniform Resource Identifiers ................................18 [CODE(WikiPage)[[[HTTP//URI]]]]
=== 3.2.1    General Syntax ...........................................19
=== 3.2.2    http URL .................................................19 [CODE(WikiPage)[[[http]]]]
=== 3.2.3    URI Comparison ...........................................20
== 3.3   Date/Time Formats ...........................................20 [CODE(WikiPage)[[[HTTPの日付形式]]]]
=== 3.3.1    Full Date ................................................20
=== 3.3.2    Delta Seconds ............................................21
== 3.4   Character Sets ..............................................21 [CODE(WikiPage)[[[charset//HTTP]]]]
=== 3.4.1    Missing Charset ..........................................22
== 3.5   Content Codings .............................................23
--- 和訳 : [CODE(WikiPage)[[[内容符号化]]]], [CODE(WikiPage)[[[content-coding]]]]
== 3.6   Transfer Codings ............................................24
--- 和訳 : [CODE(WikiPage)[[[転送符号化]]]], [CODE(WikiPage)[[[transfer-coding]]]]
=== 3.6.1    Chunked Transfer Coding ..................................25
---- 和訳 : [CODE(WikiPage)[[[chunked]]]]
== 3.7   Media Types .................................................26 [CODE(WikiPage)[[[媒体型]]]]
=== 3.7.1    Canonicalization and Text Defaults .......................27
----[CODE(WikiPage)[[[text/*//正規化]]]]
=== 3.7.2    Multipart Types ..........................................27 [CODE(WikiPage)[[[multipart/*//HTTP]]]]
== 3.8   Product Tokens ..............................................28 [CODE(WikiPage)[[[product]]]]
== 3.9   Quality Values ..............................................29
---[CODE(WikiPage)[[[qvalue]]]]
== 3.10  Language Tags ...............................................29 [CODE(WikiPage)[[[言語札]]]]
== 3.11  Entity Tags .................................................30
---[CODE(WikiPage)[[[entity-value]]]]
== 3.12  Range Units .................................................30
= 4   HTTP Message ..................................................31 [CODE(WikiPage)[[[メッセージ]]]]
== 4.1   Message Types ...............................................31
== 4.2   Message Headers .............................................31 [CODE(WikiPage)[[[HTTP//頭欄]]]]
== 4.3   Message Body ................................................32 [CODE(WikiPage)[[[message-body]]]]
== 4.4   Message Length ..............................................33 [CODE(WikiPage)[[[メッセージ//長さ]]]]
== 4.5   General Header Fields .......................................34 [CODE(WikiPage)[[[一般頭欄]]]]
= 5   Request .......................................................35 [CODE(WikiPage)[[[要求]]]]
== 5.1   [[Request-Line]] ................................................35
=== 5.1.1    Method ...................................................36 [CODE(WikiPage)[[[HTTP//method]]]]
=== 5.1.2    [[Request-URI]] ..............................................36
== 5.2   The Resource Identified by a Request ........................38
== 5.3   Request Header Fields .......................................38 [CODE(WikiPage)[[[要求頭欄]]]]
= 6   Response ......................................................39 [CODE(WikiPage)[[[HTTP応答]]]]
== 6.1   [[Status-Line]] .................................................39
=== 6.1.1    Status Code and Reason Phrase ............................39
-- [CODE(WikiPage)[[[HTTP応答]]]]
== 6.2   Response Header Fields ......................................41 [CODE(WikiPage)[[[応答頭欄]]]]
= 7   Entity ........................................................42 [CODE(WikiPage)[[[HTTP//実体]]]]
== 7.1   Entity Header Fields ........................................42 [CODE(WikiPage)[[[実体頭欄]]]]
== 7.2   Entity Body .................................................43 [CODE(WikiPage)[[[entity-body]]]]
=== 7.2.1    Type .....................................................43 [CODE(WikiPage)[[[Content-Type]]]]
=== 7.2.2    Entity Length ............................................43 [CODE(WikiPage)[[[Content-Length]]]]
= 8   Connections ...................................................44
== 8.1   Persistent Connections ......................................44 [CODE(WikiPage)[[[持続接続]]]]
=== 8.1.1    Purpose ..................................................44
=== 8.1.2    Overall Operation ........................................45
=== 8.1.3    Proxy Servers ............................................46
=== 8.1.4    Practical Considerations .................................46
== 8.2   Message Transmission Requirements ...........................47
=== 8.2.1    Persistent Connections and Flow Control ..................47
=== 8.2.2    Monitoring Connections for Error Status Messages .........48
=== 8.2.3    Use of the 100 (Continue) Status .........................48 [CODE(WikiPage)[[[100]]]]
=== 8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
= 9   Method Definitions ............................................51 [CODE(WikiPage)[[[HTTP//method]]]]
== 9.1   Safe and Idempotent Methods .................................51
=== 9.1.1    Safe Methods .............................................51 [CODE(WikiPage)[[[安全]]]]
=== 9.1.2    Idempotent Methods  .......................................51 [CODE(WikiPage)[[[冪等]]]]
== 9.2   [[OPTIONS]] .....................................................52
== 9.3   [[GET]] .........................................................53
== 9.4   [[HEAD]] ........................................................54
== 9.5   [[POST]] ........................................................54
== 9.6   [[PUT]] .........................................................55
== 9.7   [[DELETE]] ......................................................56
== 9.8   [[TRACE]] .......................................................56
== 9.9   [[CONNECT]] .....................................................57
= 10   Status Code Definitions ......................................57 [CODE(WikiPage)[[[状態符号]]]]
== 10.1  Informational [[1xx]] ...........................................57
=== 10.1.1   [[100]] Continue .............................................58
=== 10.1.2   [[101]] Switching Protocols ..................................58
== 10.2  Successful [[2xx]] ..............................................58
=== 10.2.1   [[200]] OK ...................................................58
=== 10.2.2   [[201]] Created ..............................................59
=== 10.2.3   [[202]] Accepted .............................................59
=== 10.2.4   [[203]] Non-Authoritative Information ........................59
=== 10.2.5   [[204]] No Content ...........................................60
=== 10.2.6   [[205]] Reset Content ........................................60
=== 10.2.7   [[206]] Partial Content ......................................60
== 10.3  Redirection [[3xx]] .............................................61
=== 10.3.1   [[300]] Multiple Choices .....................................61
=== 10.3.2   [[301]] Moved Permanently ....................................62
=== 10.3.3   [[302]] Found ................................................62
=== 10.3.4   [[303]] See Other ............................................63
=== 10.3.5   [[304]] Not Modified .........................................63
=== 10.3.6   [[305]] Use Proxy ............................................64
=== 10.3.7   [[306]] (Unused) .............................................64
=== 10.3.8   [[307]] Temporary Redirect ...................................65
== 10.4  Client Error [[4xx]] ............................................65
=== 10.4.1    [[400]] Bad Request .........................................65
=== 10.4.2    [[401]] Unauthorized ........................................66
=== 10.4.3    [[402]] Payment Required ....................................66
=== 10.4.4    [[403]] Forbidden ...........................................66
=== 10.4.5    [[404]] Not Found ...........................................66
=== 10.4.6    [[405]] Method Not Allowed ..................................66
=== 10.4.7    [[406]] Not Acceptable ......................................67
=== 10.4.8    [[407]] Proxy Authentication Required .......................67
=== 10.4.9    [[408]] Request Timeout .....................................67
=== 10.4.10   [[409]] Conflict ............................................67
=== 10.4.11   [[410]] Gone ................................................68
=== 10.4.12   [[411]] Length Required .....................................68
=== 10.4.13   [[412]] Precondition Failed .................................68
=== 10.4.14   [[413]] Request Entity Too Large ............................69
=== 10.4.15   [[414]] Request-URI Too Long ................................69
=== 10.4.16   [[415]] Unsupported Media Type ..............................69
=== 10.4.17   [[416]] Requested Range Not Satisfiable .....................69
=== 10.4.18   [[417]] Expectation Failed ..................................70
== 10.5  Server Error [[5xx]] ............................................70
=== 10.5.1   [[500]] Internal Server Error ................................70
=== 10.5.2   [[501]] Not Implemented ......................................70
=== 10.5.3   [[502]] Bad Gateway ..........................................70
=== 10.5.4   [[503]] Service Unavailable ..................................70
=== 10.5.5   [[504]] Gateway Timeout ......................................71
=== 10.5.6   [[505]] HTTP Version Not Supported ...........................71
= 11   Access Authentication ........................................71
= 12   Content Negotiation ..........................................71
--[CODE(WikiPage)[[[内容折衝]]]]
== 12.1  Server-driven Negotiation ...................................72
---[CODE(WikiPage)[[[サーバー駆動折衝]]]]
== 12.2  Agent-driven Negotiation ....................................73
---[CODE(WikiPage)[[[エージェント駆動折衝]]]]
== 12.3  Transparent Negotiation .....................................74
---[CODE(WikiPage)[[[透過折衝]]]]
= 13   Caching in HTTP ..............................................74
-- [[HTTP//キャッシュ]]
=== 13.1.1   Cache Correctness ........................................75
=== 13.1.2   Warnings .................................................76
=== 13.1.3   Cache-control Mechanisms .................................77
=== 13.1.4   Explicit User Agent Warnings .............................78
=== 13.1.5   Exceptions to the Rules and Warnings .....................78
=== 13.1.6   Client-controlled Behavior ...............................79
== 13.2  Expiration Model ............................................79
=== 13.2.1   Server-Specified Expiration ..............................79
=== 13.2.2   Heuristic Expiration .....................................80
=== 13.2.3   Age Calculations .........................................80
=== 13.2.4   Expiration Calculations ..................................83
=== 13.2.5   Disambiguating Expiration Values .........................84
=== 13.2.6   Disambiguating Multiple Responses ........................84
=== 13.3  Validation Model ............................................85
=== 13.3.1   Last-Modified Dates ......................................86
=== 13.3.2   Entity Tag Cache Validators ..............................86
=== 13.3.3   Weak and Strong Validators ...............................86
=== 13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
=== 13.3.5   Non-validating Conditionals ..............................90
== 13.4  Response Cacheability .......................................91
== 13.5  Constructing Responses From Caches ..........................92
=== 13.5.1   End-to-end and Hop-by-hop Headers ........................92
=== 13.5.2   Non-modifiable Headers ...................................92
=== 13.5.3   Combining Headers ........................................94
=== 13.5.4   Combining Byte Ranges ....................................95
== 13.6  Caching Negotiated Responses ................................95
--- [CODE(WikiPage)[[[内容折衝//キャッシュ]]]]
== 13.7  Shared and Non-Shared Caches ................................96
== 13.8  Errors or Incomplete Response Cache Behavior ................97
== 13.9  Side Effects of GET and HEAD ................................97
== 13.10   Invalidation After Updates or Deletions ...................97
== 13.11   Write-Through Mandatory ...................................98
== 13.12   Cache Replacement .........................................99
== 13.13   History Lists .............................................99
= 14   Header Field Definitions ....................................100
== 14.1  [[Accept]] .....................................................100
== 14.2  [[Accept-Charset]] .............................................102
== 14.3  [[Accept-Encoding]] ............................................102
== 14.4  [[Accept-Language]] ............................................104
== 14.5  [[Accept-Ranges]] ..............................................105
== 14.6  [[Age]] ........................................................106
== 14.7  [[Allow]] ......................................................106
== 14.8  [[Authorization]] ..............................................107
== 14.9  [[Cache-Control]] ..............................................108
=== 14.9.1   What is Cacheable .......................................109
=== 14.9.2   What May be Stored by Caches ............................110
=== 14.9.3   Modifications of the Basic Expiration Mechanism .........111
=== 14.9.4   Cache Revalidation and Reload Controls ..................113
=== 14.9.5   No-Transform Directive ..................................115
=== 14.9.6   Cache Control Extensions ................................116
== 14.10   [[Connection]] ...............................................117
== 14.11   [[Content-Encoding]] .........................................118
== 14.12   [[Content-Language]] .........................................118
== 14.13   [[Content-Length]] ...........................................119
== 14.14   [[Content-Location]] .........................................120
== 14.15   [[Content-MD5]] ..............................................121
== 14.16   [[Content-Range]] ............................................122
== 14.17   [[Content-Type]] .............................................124
---[CODE(WikiPage)[[[Content-Type//仕様書から]]]]
== 14.18   [[Date]] .....................................................124
=== 14.18.1   Clockless Origin Server Operation ......................125
== 14.19   [[ETag]] .....................................................126
== 14.20   [[Expect]] ...................................................126
== 14.21   [[Expires]] ..................................................127
== 14.22   [[From]] .....................................................128
== 14.23   [[Host]] .....................................................128
== 14.24   [[If-Match]] .................................................129
== 14.25   [[If-Modified-Since]] ........................................130
== 14.26   [[If-None-Match]] ............................................132
== 14.27   [[If-Range]] .................................................133
== 14.28   [[If-Unmodified-Since]] ......................................134
== 14.29   [[Last-Modified]] ............................................134
== 14.30   [[Location]] .................................................135
== 14.31   [[Max-Forwards]] .............................................136
== 14.32   [[Pragma]] ...................................................136
== 14.33   [[Proxy-Authenticate]] .......................................137
== 14.34   [[Proxy-Authorization]] ......................................137
== 14.35   [[Range]] ....................................................138
=== 14.35.1    Byte Ranges ...........................................138
=== 14.35.2    Range Retrieval Requests ..............................139
== 14.36   [[Referer]] ..................................................140
== 14.37   [[Retry-After]] ..............................................141
== 14.38   [[Server]] ...................................................141
== 14.39   [[TE]] .......................................................142
== 14.40   [[Trailer]] ..................................................143
== 14.41  [[Transfer-Encoding]]..........................................143
== 14.42   [[Upgrade]] ..................................................144
== 14.43   [[User-Agent]] ...............................................145
== 14.44   [[Vary]] .....................................................145
== 14.45   [[Via]] ......................................................146
== 14.46   [[Warning]] ..................................................148
== 14.47   [[WWW-Authenticate]] .........................................150
= 15 Security Considerations .......................................150
== 15.1      Personal Information....................................151
=== 15.1.1   Abuse of Server Log Information .........................151
=== 15.1.2   Transfer of Sensitive Information .......................151 [CODE(WikiPage)[[[HTTP//URI]]]], [CODE(WikiPage)[[[Referer:]]]] (抜粋)
=== 15.1.3   Encoding Sensitive Information in URI's .................152 [CODE(WikiPage)[[[HTTP//URI]]]]
=== 15.1.4   Privacy Issues Connected to Accept Headers ..............152
----[CODE(WikiPage)[[[Accept-Language]]]]
== 15.2  Attacks Based On File and Path Names .......................153
== 15.3  DNS Spoofing ...............................................154
== 15.4  Location Headers and Spoofing ..............................154
== 15.5  Content-Disposition Issues .................................154 [CODE(WikiPage)[[[Content-Disposition]]]]
== 15.6  Authentication Credentials and Idle Clients ................155
== 15.7  Proxies and Caching ........................................155
=== 15.7.1    Denial of Service Attacks on Proxies....................156
= 16   Acknowledgments .............................................156
= 17   References ..................................................158
= 18   Authors' Addresses ..........................................162
= 19   Appendices ..................................................164
== 19.1  Internet Media Type message/http and application/http ......164 [CODE(WikiPage)[[[message/http]]]]
== 19.2  Internet Media Type [[multipart/byteranges]] ...................165
== 19.3  Tolerant Applications ......................................166
---[CODE(WikiPage)[[[2桁西暦年号の解釈]]]] (抜粋)
== 19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
---[CODE(WikiPage)[[[実体//HTTP実体とMIME実体]]]]
=== 19.4.1   MIME-Version ............................................167
=== 19.4.2   Conversion to Canonical Form ............................167
=== 19.4.3   Conversion of Date Formats ..............................168
=== 19.4.4   Introduction of Content-Encoding ........................168
=== 19.4.5   No Content-Transfer-Encoding ............................168
=== 19.4.6   Introduction of Transfer-Encoding .......................169
=== 19.4.7   MHTML and Line Length Limitations .......................169
== 19.5  Additional Features ........................................169
=== 19.5.1   [[Content-Disposition]] .....................................170
== 19.6  Compatibility with Previous Versions .......................170
=== 19.6.1   Changes from HTTP/1.0 ...................................171
=== 19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
=== 19.6.3   Changes from RFC 2068 ...................................172
= 20   Index .......................................................175
= 21   Full Copyright Statement ....................................176
--[CODE(WikiPage)[[[[RFCのライセンス]]]]

* RFC 1945 1.; RFC 2068・2616 1 Introduction
**1.1 Purpose
> The Hypertext Transfer Protocol (HTTP) is an application-level protocol [DEL[with the lightness and speed necessary]]
for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. [DEL[This specification reflects common usage of the protocol referred too as "HTTP/1.0". This specification describes the features that seem to be consistently implemented in most HTTP/1.0 clients and servers. The specification is split into two sections. Those features of HTTP for which implementations are usually consistent are described in the main body of this document. Those features which have few or inconsistent implementations are listed in Appendix D.]] [INS[The first version of HTTP, referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration the effects of hierarchical proxies, caching, the need for persistent connections, [DEL[and]] [INS[or]] virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.]]

[DFN[ハイパーテキスト転送プロトコル (HTTP)]] は、分散協調[[ハイパー媒体]]情報システム用[DEL[に必要な軽さと速さを備えた]][[応用層]][[プロトコル]]です。
HTTP は World Wide Web 大域情報活動で 1990 年以来使われています。 [DEL[この仕様書は 「HTTP/1.0」と呼ばれるプロトコルの共通の使用法を反映しています。この仕様書は、ほとんどの HTTP/1.0 [[クライアント]]および[[鯖]]で安定して実装されていると思われる機能を説明します。仕様書は2つの部分に分けられます。実装が通常安定している HTTP の機能はこの文書の本体で説明します。余り実装されていないか不安定に実装されている機能は附属書 D に挙げます。]][INS[最初の版の HTTP は、 HTTP/0.9 と呼ばれますが、インターネットを通して生のデータ転送を行う単純なプロトコルでした。 HTTP/1.0 は、 RFC 1945 で定義されていますが、プロトコルを改良してメッセージを MIME 的な書式の、転送されるデータについてのメタ情報や要求・応答の意味についての修飾子を含んだメッセージとできるようにしました。しかし、 HTTP/1.0 は階層的な[[串]], [[キャッシュ]], [[持続接続]]の必要性や[[仮想ホスト]]の影響についての十分な考慮がなされていません。加えて、自身を「HTTP/1.0」と呼ぶ不完全に実装された応用の増殖から、二つの通信応用がお互いの真の能力を決定するために、プロトコルの版を変更することが必要となっています。]]

[INS[
> This specification defines the protocol referred to as "HTTP/1.1".
This protocol includes more stringent requirements than HTTP/1.0 in
order to ensure reliable implementation of its features.

この仕様書は、「HTTP/1.1」と呼ぶプロトコルを定義します。
このプロトコルは、その機能の信頼できる実装を確保するために、 HTTP/1.0
よりも強い要件を含んでいます。
]INS]

> Practical information systems require more functionality than simple
retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods [INS[[INS[{2616}]] and headers]] [DEL[to be used to]] [INS[that]]
indicate the purpose of a request [INS[[INS[{2616}]] [47] ]]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [DEL[[INS[{1945}]] [2] ]][INS[[INS[{2068,2616}]] [3] [DEL[ [20] ]]]], as a location (URL) [4] or name (URN) [DEL[[INS[{1945}]] [16] ]] [INS[[INS[{2616}]] [20] ]], for indicating the resource [DEL[on]] [INS[to]]
which a method is to be applied. Messages are passed in a format similar to that used by Internet [DEL[Mail [7] and]] [INS[mail [INS[ [9] ]] as defined by]]
the Multipurpose Internet Mail Extensions (MIME) [DEL[[INS[{1945}]] [5] ]][INS[[INS[{2616}]] [7] ]].

実際の情報システムは、単純な[[取出し]]以上の、[[検索]]や前置更新や[[注記]]などの機能性を必要とします。
HTTP は、要求の目的を示す[[方式]]や[[頭]]の開集合を認めています。
HTTP は、位置 ([[URL]]) や名前 ([[URN]]) として、方式が適用される[[資源]]を示す、
統一資源識別子 ([[URI]]) によって提供される参照を土台にしています。
[[メッセージ]]は、多目的インターネット・メイル拡張 ([[MIME]])
によって定義された、インターネット・メイルで使用されるものと似た書式で渡します。

> HTTP is also used as a generic protocol for communication between
user agents and proxies/gateways to other Internet [DEL[protocols, such as SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing]] [INS[systems, including those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2], and WAIS [10] protocols. In this way, HTTP allows]]
basic hypermedia access to resources available from diverse applications [DEL[and simplifying the implementation of user agents]].

HTTP は、[[利用者エージェント]]と [[SMTP]], [[NNTP]], [[FTP]], [[Gopher]], [[WAIS]] のようなプロトコルによって支援されるものを含む、
他のインターネット・システムとの[[串]]・[[関門]]との間の通信のための汎用プロトコルとしても使われます。
この方法では、 HTTP は異なった応用から利用可能な資源への基本ハイパー媒体接続を認めます。

[INS[
注意: 注記なき変更点は、 RFC 1945 → RFC 2068 のもの。
]INS]

** RFC 2068・2616 1.2 Requirements
[DEL[
> This specification uses the same words as RFC 1123 [8] for defining
the significance of each particular requirement. These words are:

この仕様書は、各々の要件の重要度を定義するために [[RFC1123]]
と同じ言葉を使います。

>
: MUST :
This word or the adjective "required" means that the item is an
absolute requirement of the specification.
: SHOULD :
This word or the adjective "recommended" means that there may
exist valid reasons in particular circumstances to ignore this
item, but the full implications should be understood and the case
carefully weighed before choosing a different course.
: MAY :
This word or the adjective "optional" means that this item is
truly optional. One vendor may choose to include the item because
a particular marketplace requires it or because it enhances the
product, for example; another vendor may omit the same item.

: '''しなければなりません''' : この言葉や「必須」は、
その項目が仕様の絶対要件であることを意味します。
: '''するべきです''' : この言葉や「推奨」は、特定の境遇においてはその項目を無視する妥当な理由が存在するかもしれないけれども、完全な実装は異なる道を選ぶ前に理解し、注意深く重み付けするべきであることを意味します。
: '''して構いません''' : この言葉や「任意選択」は、その項目が本当に任意選択であることを意味します。ある販売者は特定の市場がそれを必要としているからとか製品を普及させるからとかそんなような理由でその項目を含めることを選ぶかもしれません。他の販売者はその項目を省くかもしれません。
]DEL]

[INS[
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [34].

この文書中の見出し語 '''しなければなりません''', '''してはなりません''',
'''する必要があります''', '''するべきです''', '''するべきではありません''',
'''推奨します''', '''して構いません''', ''''任意選択'''は、 [[RFC2119]]]]
で説明されている通り解釈します。
]INS]

> An implementation is not compliant if it fails to satisfy one or more
of the MUST [INS[or REQUIRED level]] requirements for the protocols it implements. An
implementation that satisfies all the MUST [INS[or REQUIRED level]] and all the SHOULD [INS[level]]
requirements for its protocols is said to be "unconditionally
compliant"; one that satisfies all the MUST [INS[level]] requirements but not all
the SHOULD [INS[level]] requirements for its protocols is said to be
"conditionally compliant."

ある実装は、その実装するプロトコルの'''しなければなりません'''や'''する必要があります'''の水準の要件を一つでも満足していなければ、適合しません。
プロトコルのすべての'''しなければなりません'''や'''する必要があります'''の水準の要件並びにすべての'''するべきです'''水準の要件を満足する実装は、
[DFN[非条件付適合]]といいます。プロトコルのすべての'''しなければなりません'''水準の要件を満たすもののすべての'''するべきです'''水準の要件は満足しないものは[DFN[条件付適合]]といいます。

** RFC 1945 1.2; RFC 2068・2616 1.3 Terminology
> This specification uses a number of terms to refer to the roles
played by participants in, and objects of, the HTTP communication.

この仕様書は、 HTTP 通信に関係したり、対象となったりする役割を指す数々の言葉を使います。

[CODE(WikiPage)[[[接続]]]], [CODE(WikiPage)[[[メッセージ]]]], [CODE(WikiPage)[[[要求]]]], [CODE(WikiPage)[[[応答]]]], [CODE(WikiPage)[[[資源]]]], [CODE(WikiPage)[[[実体]]]], [CODE(WikiPage)[[[表現]]]], [CODE(WikiPage)[[[内容折衝]]]], [CODE(WikiPage)[[[変種]]]], [CODE(WikiPage)[[[クライアント]]]], [CODE(WikiPage)[[[利用者エージェント]]]], [CODE(WikiPage)[[[サーバー]]]], [CODE(WikiPage)[[[起源サーバー]]]],[CODE(WikiPage)[[[串]]]],  [CODE(WikiPage)[[[関門]]]], [CODE(WikiPage)[[[トンネル]]]], [CODE(WikiPage)[[[キャッシュ]]]], [CODE(WikiPage)[[[キャッシュ可能]]]], [CODE(WikiPage)[[[初手]]]], [CODE(WikiPage)[[[明示満期時刻]]]], [CODE(WikiPage)[[[発見的満期時刻]]]], [CODE(WikiPage)[[[齢]]]], [CODE(WikiPage)[[[新鮮寿命]]]], [CODE(WikiPage)[[[新鮮]]]], [CODE(WikiPage)[[[腐敗]]]], [CODE(WikiPage)[[[意味的透過]]]], [CODE(WikiPage)[[[検証子]]]], [CODE(WikiPage)[[[上流]]]], [CODE(WikiPage)[[[上り]]]]

** RFC 1945 1.3; RFC 2068・2616 1.4 Overall Operation
> The HTTP protocol is [DEL[based on]] a request/response [DEL[paradigm]] [INS[protocol]]. A client [DEL[establishes a connection with a server and]]
sends a request to the server in the form of a request method, URI, and
protocol version, followed by a MIME-like message containing request
modifiers, client information, and possible body
content [INS[over a connection with a server]].
The server responds with a status line, including the message's protocol version
and a success or error code, followed by a MIME-like message containing server
information, entity metainformation, and possible [INS[entity-]]body content. [INS[The relationship between HTTP and MIME is described in appendix 19.4.]]

HTTP プロトコルは、要求・応答プロトコルです。
クライアントは、要求[[方式]], [[URI]], プロトコルの版,
それに続けて要求修飾子・クライアント情報・場合によっては[[本体]]内容を含む MIME 的メッセージという書式で、鯖との[[接続]]上で鯖に要求を送ります。
鯖は、メッセージのプロトコル版と成功または誤りの符号を含んだ[[状態行]]と、
それに続けて鯖情報・実体のメタ情報・場合によっては [CODE(ABNF)[[[entity-body]]]]
内容を含んだ MIME 的メッセージで応答します。

> Most HTTP communication is initiated by a user agent and consists of
a request to be applied to a resource on some origin server. In the
simplest case, this may be accomplished via a single connection (v)
between the user agent (UA) and the origin server (O).

ほとんどの HTTP 通信は、[[利用者エージェント]]によって初期化され、
[[起源鯖]]の[[資源]]に適用される要求で構成します。
最も単純な場合、これは利用者エージェント ([VAR[UA]]) と起源鯖
([VAR[O]]) の間の一つの接続 ([VAR[v]]) により達成されます。

>
[PRE[
   request chain ------------------------>
UA -------------------v------------------- O
   <----------------------- response chain
]PRE]

> A more complicated situation occurs when one or more intermediaries
are present in the request/response chain. There are three common
forms of intermediary: proxy, gateway, and tunnel. A proxy is a
forwarding agent, receiving requests for a URI in its absolute form,
rewriting all or part[DEL[s]] of the message, and forwarding the reformatted
request toward the server identified by the URI. A gateway is a
receiving agent, acting as a layer above some other server(s) and, if
necessary, translating the requests to the underlying server's
protocol. A tunnel acts as a relay point between two connections
without changing the messages; tunnels are used when the
communication needs to pass through an intermediary (such as a
firewall) even when the intermediary cannot understand the contents of the messages.

もっと複雑な状況は、一つ以上の中間媒介者が要求・応答鎖にいるときに起こります。
媒介者には3つの共通形態: [[串]], [[関門]], [[トンネル]]があります。
[DFN[串]]は、転送エージェントで、 [[URI]] への要求を絶対形で受け取り、
メッセージの全部又は一部を書き換え、その再書式付けした要求を URI
で識別される鯖の方向に転送します。[DFN[関門]]は、
受信エージェントで、他の鯖(群)上の層として働き、必要であれば要求をその鯖への湯汲に翻訳します。
[DFN[トンネル]]は、メッセージを変更せず、二つの接続の間の中継点として動作します。
トンネルは、媒介者 (例えば[[防火壁]]) がメッセージの内容を理解できないときであっても通信がその媒介者を通過する必要があるときに使います。

>
[PRE[
   request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
   <------------------------------------- response chain
]PRE]

> The figure above shows three intermediaries (A, B, and C) between the
user agent and origin server. A request or response message that
travels the whole chain [DEL[must]] [INS[will]] pass through four separate connections.
This distinction is important because some HTTP communication options
may apply only to the connection with the nearest, non-tunnel
neighbor, only to the end-points of the chain, or to all connections
along the chain.  Although the diagram is linear, each participant may
be engaged in multiple, simultaneous communications. For example, B
may be receiving requests from many clients other than A, and/or
forwarding requests to servers other than C, at the same time that it is handling A's request.

上の図は、利用者エージェントと鯖の間の3つの媒介者 ([VAR[A]], [VAR[B]], [VAR[C]])
を示しています。鎖全体を旅する要求や応答のメッセージは、4つの別個の接続を通過します。
HTTP 通信選択肢の中には直近の非トンネル隣人との接続にだけ適用されるものや鎖の終端ののみ適用されるものや鎖に沿うすべての接続に適用されるものがありますから、
この区別は重要です。図は線形ですが、各関係は複数同時通信であっても構いません。
例えば、 [VAR[B]] は、 [VAR[A]] の要求を扱うのと同時に、 [VAR[A]] 以外の多くのクライアントから要求を受信するかもしれませんし、 [VAR[C]] 以外の鯖へ要求を転送するかもしれません。

> Any party to the communication which is not acting as a tunnel may
employ an internal cache for handling requests. The effect of a cache
is that the request/response chain is shortened if one of the
participants along the chain has a cached response applicable to that
request. The following illustrates the resulting chain if B has a
cached copy of an earlier response from O (via C) for a request which
has not been cached by UA or A.

トンネルとして動作しているのではない任意の通信当事者は、
要求を扱うために内部[[キャッシュ]]を使用しても構いません。
キャッシュの効果は、鎖上の誰かがその要求に適用可能なキャッシュされた応答を持っていれば要求・応答鎖が短絡することです。
次は、 [VAR[UA]] や [VAR[A]] がキャッシュしていないけれども [VAR[B]] が前の [VAR[O]] からの ([VAR[C]] を介した) 応答のキャッシュ複製を持っていた場合の結果の鎖を描いています。

>
[PRE[
   request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
   <--------- response chain
]PRE]

> Not all responses are [INS[usefully]]
cach[INS[e]]able [INS[{2616}]], and some requests may contain modifiers which place special requirements on cache behavior. [DEL[Some HTTP/1.0 applications use heuristics to describe what is or is not a "cachable" response, but these rules are not standardized.]] [INS[HTTP requirements for cache behavior and cach[INS[e]]able responses are defined in section 13.]]

すべての応答が有用に[[キャッシュ可能]]であるわけではなく、
要求はキャッシュの振舞いに特別な要件を課す修飾子を含むかもしれません。[DEL[HTTP/1.0 応用の中には何が「キャッシュ可能」で何がそうでないかを記述する発見的方法を使うものもありますが、その規則は標準化されていません。]] [INS[キャッシュの振舞いやキャッシュ可能応答についての HTTP の要件は13章で定義します。]]

[INS[
> In fact, there are a wide variety of architectures and configurations
of caches and proxies currently being experimented with or deployed
across the World Wide Web[DEL[;]][INS[.]] [DEL[these]] [INS[These]] systems include national hierarchies
of proxy caches to save transoceanic bandwidth, systems that
broadcast or multicast cache entries, organizations that distribute
subsets of cached data via CD-ROM, and so on. HTTP systems are used
in corporate intranets over high-bandwidth links, and for access via
PDAs with low-power radio links and intermittent connectivity. The
goal of HTTP/1.1 is to support the wide diversity of configurations
already deployed while introducing protocol constructs that meet the
needs of those who build web applications that require high
reliability and, failing that, at least reliable indications of failure.

実際、様々な種類のキャッシュや串の体系や構成が現在 World Wide Web
で実験されたり使用されたりしています。それらのシステムには、
渡海帯域を節約するための串キャッシュの国家的階層や、
キャッシュ項目を broadcast や multicast するシステム、
キャッシュデータの部分集合を [[CD-ROM]] で配布する組織などなどを含みます。
HTTP システムは広帯域連結上の[[イントラネット]]と協同して使われたり、
低力無線連結や断続的接続の [[PDA]] を介して接続されたりします。
HTTP/1.1 の目標は、高い信頼性や、それが無理でも少なくても確実に失敗を示すことが必要なウェブ応用を構築する人の需要に合致するプロトコル構造を導入しつつ、既に用いられている多用な構成に対応することです。
]INS]

> [DEL[On the Internet,]] HTTP communication [DEL[generally]] [INS[usually]]
takes place over TCP/IP connections. The default port is TCP 80 [DEL[[INS[{1945}]] [15] ]][INS[[INS[{2616}]] [19] ]], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on
the Internet, or on other networks. HTTP only presumes a reliable
transport; any protocol that provides such guarantees can be used[INS[;]][DEL[, and]] the mapping of the [DEL[HTTP/1.0]] [INS[HTTP/1.1]]
request and response structures onto the transport data units of the protocol in
question is outside the scope of this specification.

HTTP 通信は通常 [[TCP/IP]] 接続上で行われます。既定[[ポート]]は TCP [[80]]
ですが、他のポートを使うこともできます。
これは、 HTTP をインターネットのほかのプロトコルや他のネットワークの上に実装することを妨げるものではありません。 HTTP は、信頼できる輸送路だけを仮定します。
それを保証できる任意のプロトコルを使うことができます。
HTTP 要求・応答構造から件のプロトコルの輸送データ単位への写像はこの仕様書の適用範囲外です。

[DEL[
> Except for experimental applications, current practice requires that
the connection be established by the client prior to each request and
closed by the server after sending the response. Both clients and
servers should be aware that either party may close the connection
prematurely, due to user action, automated time-out, or program
failure, and should handle such closing in a predictable fashion. In
any case, the closing of the connection by either or both parties
always terminates the current request, regardless of its status.

実験的応用を除き、現在の運用では接続はクライアントが各要求の前に確立し、
鯖が応答を送った後に閉じることを必要としています。
クライアントも鯖も、どちらもが利用者の動作や自動時間切れやプログラムの失敗によって接続を早く閉じても構わないことに注意するべきであり、
そのような閉じ方を想定して取り扱うべきです。どんな場合でも、
当事者の一方又は両方が接続を閉じることは常に現在の要求をその状態にかかわらず終端させます。
]DEL]

[INS[
> In HTTP/1.0, most implementations used a new connection for each
request/response exchange. In HTTP/1.1, a connection may be used for
one or more request/response exchanges, although connections may be
closed for a variety of reasons (see section 8.1).

HTTP/1.0 では、ほとんどの実装は各要求・応答交換に新しい接続を使っていました。
HTTP/1.1 では、種々の理由で接続を閉じても構いませんが、
一つの接続を一つ以上の要求・応答交換に使っても構いません。
]INS]

[INS[
注: 注記のない変更点は、 RFC 1945 → RFC 2068 でのもの。
]INS]

** RFC 1945 1.4  HTTP and MIME
> HTTP/1.0 uses many of the constructs defined for MIME, as defined in
RFC 1521 [5]. Appendix C describes the ways in which the context of
HTTP allows for different use of Internet Media Types than is
typically found in Internet mail, and gives the rationale for those differences.

HTTP/1.0 は、 MIME で定義された多くの構造を使っています。
附属書 C は、インターネット[[媒体型]]が HTTP という文脈でインターネット・メイルで典型的に見られる場合とどう違って使われることを認めているかを説明し、その差異の理由を解説します。
** RFC 1945 (HTTP/1.0) B.; RFC 2068・RFC 2616 (HTTP/1.1) 19.3 Tolerant Applications
> Although this document specifies the requirements for the generation
of [DEL[[INS[{1945}]] HTTP/1.0]] [INS[HTTP/1.1]] messages, not all applications will be correct in their
implementation. We therefore recommend that operational applications
be tolerant of deviations whenever those deviations can be
interpreted unambiguously.

この文書は HTTP メッセージの生成での要件を規定していますが、
すべての[[応用]]が正しく実装してはいません。従って、
運用応用は逸脱に寛容であっても曖昧なく解釈できるのであるときには常に[[寛容]]であることを推奨します。

> Clients [DEL[[INS[{1945}]] should]] [INS[SHOULD]] be tolerant in parsing the Status-Line and servers
tolerant when parsing the Request-Line. In particular, they [DEL[[INS[{1945}]] should]] [INS[SHOULD]]
accept any amount of SP or HT characters between fields, even though
only a single SP is required.

[[クライアント]]は [CODE(ABNF)[[[Status-Line]]]] の解析において、
[[鯖]]は [CODE(ABNF)[[[Request-Line]]]] の解析において、それぞれ寛容である'''べきです'''。
特に、単一の [CODE(ABNF)[[[SP]]]] のみが必要である場合であっても、
任意の量の [CODE(ABNF)[SP]] や [CODE(ABNF)[[[HT]]]] を受け入れる'''べきです'''。

> The line terminator for [DEL[[INS[{1945}]] HTTP-header]] [INS[message-header]] fields is the sequence CRLF.
However, we recommend that applications, when parsing such headers,
recognize a single LF as a line terminator and ignore the leading CR.

[CODE(ABNF)[message-header]] 欄の行終端子は、列 [CODE(ABNF)[[[CRLF]]]]
です。しかし、応用は、そのような頭を解析するときには、
単一の [CODE(ABNF)[LF]] を行終端子と認識し、先導する [CODE(ABNF)[CR]]
を無視することを推奨します。

[INS[
> The character set of an entity-body [DEL[should]] [INS[SHOULD]] be labeled as the lowest
common denominator of the character codes used within that body, with
the exception that [DEL[no label]] [INS[not labeling the entity]] is preferred over [INS[labeling the entity with]] the labels US-ASCII or ISO-8859-1. [INS[See section 3.7.1 and 3.4.1.]]

[CODE(ABNF)[[[entity-body]]]] の[[文字集合]]は、
その本体で使われている文字符号の最小公倍数で札付けする'''べきです'''。
但し、実体を札 [CODE(charset)[[[US-ASCII]]]] や札
[CODE(charset)[[[ISO-8859-1]]]] で札付けするよりは札付けしないほうが好ましいです。

> Additional rules for requirements on parsing and encoding of dates
and other potential problems with date encodings include:

日付を構文解析するに当たっての追加の規則や日付符号化の他の問題の可能性:

>
-[DEL[o]] [INS[-]] HTTP/1.1 clients and caches [DEL[should]] [INS[SHOULD]] assume that an RFC-850 date
which appears to be more than 50 years in the future is in fact
in the past (this helps solve the "year 2000" problem).
-[DEL[o]] [INS[-]] An HTTP/1.1 implementation [DEL[may]] [INS[MAY]] internally represent a parsed
Expires date as earlier than the proper value, but MUST NOT
internally represent a parsed Expires date as later than the proper value.
-[DEL[o]] [INS[-]] All expiration-related calculations [DEL[must]] [INS[MUST]] be done in GMT. The
local time zone MUST NOT influence the calculation or comparison
of an age or expiration time.
-[DEL[o]] [INS[-]] If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it [DEL[must]] [INS[MUST]] be converted into GMT using the most
conservative possible conversion.

- HTTP/1.1 クライアントおよびキャッシュは、50年よりも将来に見える [[RFC850]]
日付は実際は過去のものとみなす'''べきです''' (これは[[2000年問題]]を解決するのを助けます)。
- HTTP/1.1 実装は解析した [CODE(HTTP)[[[Expires]]]] 日付を適切な値よりも前のものとして内部的に表現しても'''構いません'''が、解析した [CODE(HTTP)[Expires]] 日付を適切な値よりも後のものとして内部的に表現しては'''いけません'''。
- すべての[[満期]]関連の計算は [[GMT]] で行わなければ'''なりません'''。
[[地方時間]]帯が[[齢]]や[[満期時刻]]の計算や比較に影響しては'''なりません'''。
-HTTP 頭が不正に GMT 以外の時間帯で日付値を伝達しているときは、
最も用心深い可能な変換を用いて GMT に変換しなければ'''なりません'''。
]INS]
** RFC 1945 (HTTP/1.0) D.; RFC 2068 (HTTP/1.1) 19.6; RFC 2616 (HTTP/1.1) 19.5 Additional Features
> [DEL[This appendix documents]] [INS[[INS[{2616}]] RFC 1945 and RFC 2068 document]] protocol elements used by some existing HTTP
implementations, but not consistently and correctly across most [DEL[HTTP/1.0]] [INS[HTTP/1.1]] applications. [DEL[[DEL[Implementors]] [INS[Implementers]] should]] [INS[Implementors are advised to]] be aware of these
features, but cannot rely upon their presence in, or interoperability
with, other [DEL[HTTP/1.0]] [INS[HTTP/1.1]] applications. [INS[Some of these describe proposed experimental features, and some describe features that experimental deployment found lacking that are now addressed in the base HTTP/1.1 specification.]]

[[RFC1945]] と [[RFC2068]] は、既存の HTTP 実装で使われているものの、
ほとんどの HTTP 実装に渡って安定して正しく実装されていないプロトコル要素を文書化しています。
実装者は、それらの機能を知っておくことをお勧めしておきますが、
その存在や他の HTTP 応用との相互通信性はあてにはなりません。[INS[そのうちの幾つかは提案されている実験的機能を説明するもので、幾つかは実験的展開が欠けていることを発見した機能で今は基底 HTTP/1.1 仕様書に言及されているものを説明しています。]]

[INS[
> [INS[{2616}]]  A number of other headers, such as Content-Disposition and Title,
from SMTP and MIME are also often implemented (see RFC 2076 [37]).

[[SMTP]] や [[MIME]] からの他の多くの頭、例えば [CODE(HTTP)[[[Content-Disposition]]]]
や [CODE(HTTP)[[[Title]]]] のようなものもしばしば実装されています
([[RFC2076]] 参照)。
]INS]

*** RFC 1945 (HTTP/1.0) D.1; RFC 2068 (HTTP/1.1) 19.6.1 Additional Request Methods
→[CODE(WikiPage)[[[PUT]]]], [CODE(WikiPage)[[[PATCH]]]], [CODE(WikiPage)[[[DELETE]]]], [CODE(WikiPage)[[[LINK]]]], [CODE(WikiPage)[[[UNLINK]]]]
*** RFC 1945 (HTTP/1.0) D.2; RFC 2068 (HTTP/1.1) 19.6.2 Additional Header Field Definitions
→[CODE(WikiPage)[[[Alternates]]]], [CODE(WikiPage)[[[Content-Version]]]], [CODE(WikiPage)[[[Derived-From]]]], [CODE(WikiPage)[[[Link]]]], [CODE(WikiPage)[[[Title]]]], [CODE(WikiPage)[[[URI]]]], [CODE(WikiPage)[[[Accept]]]], [CODE(WikiPage)[[[Accept-Charset]]]], [CODE(WikiPage)[[[Accept-Encoding]]]], [CODE(WikiPage)[[[Accept-Language]]]], [CODE(WikiPage)[[[Content-Language]]]], [CODE(WikiPage)[[[MIME-Version]]]], [CODE(WikiPage)[[[Retry-After]]]]
*** RFC 2616 (HTTP/1.1) 19.5.1 Content-Disposition
→[CODE(WikiPage)[[[Content-Disposition]]]]
** RFC 2068 (HTTP/1.1) 19.7; RFC 2616 (HTTP/1.1) 19.6 Compatibility with Previous Versions
> It is beyond the scope of a protocol specification to mandate
compliance with previous versions. HTTP/1.1 was deliberately
designed, however, to make supporting previous versions easy. It is
worth noting that at[INS[,]] the time of composing this specification [INS[(1996)]],
we would expect commercial HTTP/1.1 servers to:

以前の版への適合を強制するのはプロトコル仕様書の適用範囲外です。
しかし、 HTTP/1.1 は以前の版に容易に対応できるように故意に設計しています。
この仕様書の編纂 (1996年) の時点では、商用 HTTP/1.1
鯖に次のことを期待していると注記する価値はあるでしょう。

>
- [DEL[o]] [INS[-]]
recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
- [DEL[o]] [INS[-]]
understand any valid request in the format of HTTP/0.9, 1.0, or 1.1;
- [DEL[o]] [INS[-]]
respond appropriately with a message in the same major version
used by the client.

- HTTP/0.9, 1.0 および 1.1 の [CODE(ABNF)[[[Request-Line]]]] の書式を認識すること
- HTTP/0.0, 1.0 および 1.1 の書式の任意の妥当な[[要求]]を理解すること
- クライアントが使っているのと同じ大版のメッセージに適切に応答するこ

> And we would expect HTTP/1.1 clients to:

そして、 HTTP/1.1 には次のことを期待します。

>
- [DEL[o]] [INS[-]]
recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
- [DEL[o]] [INS[-]]
understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.

- HTTP/1.0 および 1.1 の応答の [CODE(ABNF)[[[Status-Line]]]]
の書式を認識すること
- HTTP/0.9, 1.0 または 1.1 の任意の妥当な応答を理解すること

> For most implementations of HTTP/1.0, each connection is established
by the client prior to the request and closed by the server after
sending the response. [DEL[A few]] [INS[Some]] implementations implement the Keep-Alive
version of persistent connections described in section [DEL[19.7.1.1]] [INS[19.7.1 of RFC 2068 [33] ]].

HTTP/1.0 のほとんどの実装では、各[[接続]]はクライアントが[[要求]]の前に確立し、
[[鯖]]が[[応答]]を送信した後に閉じます。幾つかの実装は
[CODE(HTTP)[[[Keep-Alive]]]] 版の[[持続接続]]を実装しています。

***RFC 2068 19.5; RFC 2616 19.6.1 Changes from HTTP/1.0
> This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.

この節では、 HTTP/1.0 と HTTP/1.1 の間の大きな違いをまとめます。

**** RFC 2068 19.5.1; RFC 2616 19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
> The requirements that clients and servers support the Host request-header, report an error if the Host request-header (section 14.23) is
missing from an HTTP/1.1 request, and accept absolute URIs (section
5.1.2) are among the most important changes defined by this specification.

クライアントと鯖が [CODE(HTTP)[[[Host]]]] 要求頭に対応し、
[CODE(HTTP)[Host]] 要求頭が HTTP/1.1 要求で欠けていたら誤りを報告し、
[[絶対URI]] を受け入れるという要件がこの仕様書で定義される中でもっとも重要な変更です。

> Older HTTP/1.0 clients assumed a one-to-one relationship of IP
addresses and servers; there was no other established mechanism for
distinguishing the intended server of a request than the IP address
to which that request was directed. The changes outlined above will
allow the Internet, once older HTTP clients are no longer common, to
support multiple Web sites from a single IP address, greatly
simplifying large operational Web servers, where allocation of many
IP addresses to a single host has created serious problems. The
Internet will also be able to recover the IP addresses that have been
allocated for the sole purpose of allowing special-purpose domain
names to be used in root-level HTTP URLs. Given the rate of growth of
the Web, and the number of servers already deployed, it is extremely
important that all implementations of HTTP (including updates to
existing HTTP/1.0 applications) correctly implement these requirements:

古めの HTTP/1.0 クライアントは、 IP 番地と鯖の一対一対応関係を仮定しています。
要求が向けられた IP 番地以外に要求の意図している鯖を区別する確立された方法はありませんでした。
上に概説した変更は、ひとたび古い HTTP クライアントがもう広くは使われなくなれば、
インターネットが複数の [[Webサイト]]を一つの IP 番地で対応することを認めるものです。
多くの IP 番地を一つのホストに割当てることは重大な問題を起こしているところですが、
大規模運用 [[Web鯖]]が非常に単純化されます。特別な目的のドメイン名を根水準
HTTP URL で使用することを認める目的だけで割当てられている IP
番地をインターネットが回復することもできます。 [[Web]]
の成長率と既に使われている鯖の数を鑑みると、 HTTP
のすべての実装 (既存の HTTP/1.0 応用の更新も含む。) が次の要件を正しく実装することがきわめて重要であります。

>
- [DEL[o]] [INS[-]]
 Both clients and servers MUST support the Host request-header.
- [DEL[o Host request-headers are required in HTTP/1.1 requests.]] [INS[- A client that sends an HTTP/1.1 request MUST send a Host header.]]
- [DEL[o]] [INS[-]]
Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header.
- [DEL[o]] [INS[-]]
Servers MUST accept absolute URIs.

- クライアントと鯖の両方が [CODE(HTTP)[[[Host]]]] 要求頭に対応しなければ'''ならない'''。
- HTTP/1.1 要求を送信するクライアントは [CODE(HTTP)[Host]] 頭を送らなければ'''ならない'''。
- 鯖は、 HTTP/1.1 要求が [CODE(HTTP)[Host]] 要求頭を含まないなら [CODE(HTTP)[[[400]]]]
(悪い要求) 誤りを報告しなければ'''ならない'''。

*** RFC 2068 19.7.1; RFC 2616 19.6.2 Compatibility with HTTP/1.0 Persistent Connections
→[CODE(WikiPage)[[[Connection]]]]
***** RFC 2068 19.7.1.1 The Keep-Alive Header
→[CODE(WikiPage)[[[Keep-Alive]]]]
*** RFC 2616 19.6.3 Changes from RFC 2068
> This specification has been carefully audited to correct and
disambiguate key word usage; RFC 2068 had many problems in respect to
the conventions laid out in RFC 2119 [34].

この仕様書は、注意深く精査して修正し、見出し語の使用に曖昧さがないようにしています。
RFC 2068 は、[[RFC2119]] で示された表記法に関して多くの問題を抱えていました。

> Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 10.5.5).

[[上り]]鯖失敗 (例えば [[DNS]] 失敗) でどの誤り符号を使うべきかを明確化。

> CREATE had a race that required an Etag be sent when a resource is
first created. (Section 10.2.2).

CREATE [INS[(訳注: [CODE(HTTP)[[[201]]]] (作成済み) 応答)]] は[[資源]]が最初に作成される時に [CODE(HTTP)[Etag]] を送ることを必要としている点で競合がありました。

> Content-Base was deleted from the specification: it was not
implemented widely, and there is no simple, safe way to introduce it
without a robust extension mechanism. In addition, it is used in a
similar, but not identical fashion in MHTML [45].

[CODE(HTTP)[[[Content-Base]]]] は仕様書から削除しました。
この欄は広く実装されていませんでしたし、
強力な拡張機構抜きでこれを導入するための簡単で安全な方法はありません。
加えて、この欄は [[MHTML]] でも似ているものの同じではない方法で使われています。

>Transfer-coding and message lengths all interact in ways that
required fixing exactly when chunked encoding is used (to allow for
transfer encoding that may not be self delimiting); it was important
to straighten out exactly how message lengths are computed. (Sections
3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)

[CODE(ABNF)[transfer-coding]] とメッセージの長さはすべて、
(自己区切的でないかもしれない[[転送符号化]]を認めるために)
正確にいつ [CODE(HTTP)[[[chunked]]]] 符号化が使われるかを修正することが必要な形で相互作用します。
正確にどうメッセージの長さを計算するかを調整することが重要でした。

> A content-coding of "identity" was introduced, to solve problems
discovered in caching. (section 3.5)

[[キャッシュ]]の問題を解決するために [CODE(HTTP)[[[identity]]]]
[CODE(ABNF)[[[content-coding]]]] が導入されました。

> Quality Values of zero should indicate that "I don't want something"
to allow clients to refuse a representation. (Section 3.9)

[[品質値]]零は、利用者が[[表現]]を拒絶することを認めるために、
「私は何も望みません」を示すべきです。

>The use and interpretation of HTTP version numbers has been clarified
by RFC 2145. Require proxies to upgrade requests to highest protocol
version they support to deal with problems discovered in HTTP/1.0
implementations (Section 3.1)

HTTP 版番号の使用と解釈が [[RFC2145]] で明確化されています。
串は、 HTTP/1.0 実装に見つかった問題に対処するために、
最高のプロトコルの版に更新することが必要です。

>Charset wildcarding is introduced to avoid explosion of character set
names in accept headers. (Section 14.2)

文字集合名が受入れ頭で爆発するのを避けるために charset
[[鬼札]]を導入します。

> A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, 14.9.3)

HTTP/1.1 [CODE(HTTP)[[[Cache-Control]]]] 模型で場合が抜けていました。
この抜けていた場合を追加するために [CODE(HTTP)[[[s-maxage]]]]
を導入しました。

>The Cache-Control: max-age directive was not properly defined for
responses. (Section 14.9.3)

[CODE(HTTP)[Cache-Control: max-age]] 指令が応答について適切に定義されていませんでした。

> There are situations where a server (especially a proxy) does not
know the full length of a response but is capable of serving a
byterange request. We therefore need a mechanism to allow byteranges
with a content-range not indicating the full length of the message. (Section 14.16)

鯖 (特に串) が応答の完全な長さを知らないけどバイト範囲要求を給仕することはできるという状況があります。
従って、メッセージの完全な長さを示さない [CODE(ABNF)[content-range]]
のバイト範囲を認める気候が必要です。

> Range request responses would become very verbose if all meta-data
were always returned; by allowing the server to only send needed
headers in a 206 response, this problem can be avoided. (Section 10.2.7, 13.5.3, and 14.27)

範囲要求応答ですべてのメタ・データが常に返されるとすると非常にやかましくなります。
[CODE(HTTP)[[[206]]]] 応答では鯖が必要な頭だけを送信するのを認めることにより、
この問題は避けることができます。

> Fix problem with unsatisfiable range requests; there are two cases:
syntactic problems, and range doesn't exist in the document. The 416
status code was needed to resolve this ambiguity needed to indicate
an error for a byte range request that falls outside of the actual
contents of a document. (Section 10.4.17, 14.16)

満足不能範囲要求についての問題を解決。これには二つの場合があります。
構文的な問題の場合と、文書に存在しない範囲の場合です。
この曖昧性を解決するために、文書の実際の内容の外側のバイト範囲要求の誤りを示すのに必要な 
[CODE(HTTP)[[[416]]]] [[状態符号]]が必要でした。

> Rewrite of message transmission requirements to make it much harder
for implementors to get it wrong, as the consequences of errors here
can have significant impact on the Internet, and to deal with the following problems:

メッセージ転送要件を、
ここでの誤りの結果はインターネットに大きな衝撃を与え得るので、
間違って実装するのがより難しくなるように、
そして次の問題に対処するために書き換え。

>
- 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
this was incorrectly placing a requirement on the behavior of
an implementation of a future version of HTTP/1.x
- 2. Made it clear that user-agents should retry requests, not "clients" in general.
- 3. Converted requirements for clients to ignore unexpected 100
(Continue) responses, and for proxies to forward 100 responses,
into a general requirement for 1xx responses.
- 4. Modified some TCP-specific language, to make it clearer that
non-TCP transports are possible for HTTP.
- 5. Require that the origin server MUST NOT wait for the request
body before it sends a required 100 (Continue) response.
- 6. Allow, rather than require, a server to omit 100 (Continue) if
it has already seen some of the request body.
- 7. Allow servers to defend against denial-of-service attacks and broken clients.

- 将来の版の HTTP/1.[VAR[x]] の実装の動作についての要件を誤って課していた箇所で「HTTP/1.1 以降」を「HTTP/1.1」に変更。
- 「クライアント」一般ではなく利用者エージェントが要求を再試行するべきであることを明確化。
- クライアントが予期せぬ [CODE(HTTP)[[[100]]]] (継続) 応答を無視することおよび串が
[CODE(HTTP)[100]] 応答を転送することについての要件を [CODE(HTTP)[[[1xx]]]]
応答一般の要件に変更。
- 非 [[TCP]] 転送路で HTTP を使うのが可能であることを明らかにするために
TCP 特有の言葉を修正。
- [[起源鯖]]が必須の [CODE(HTTP)[100]] (継続) 応答を送る前に要求本体を待っては'''ならない'''ことを要求。
- 鯖が既に要求本体の幾らかを見ているときには [CODE(HTTP)[100]] (継続)
を省略することを (要求するのではなく) 認める。
- 鯖が[[サービス拒否攻撃]]と壊れたクライアントから防御するのを認める。

> This change adds the Expect header and 417 status code. The message
transmission requirements fixes are in sections 8.2, 10.4.18, 8.1.2.2, 13.11, and 14.20.

この変更は、 [CODE(HTTP)[[[Expect]]]] 頭と [CODE(HTTP)[[[417]]]]
状態符号を追加します。

> Proxies should be able to add Content-Length when appropriate. (Section 13.5.2)

串は適切な時には [CODE(HTTP)[[[Content-Length]]]] を追加することができるべきです。

> Clean up confusion between 403 and 404 responses. (Section 10.4.4, 10.4.5, and 10.4.11)

[CODE(HTTP)[[[403]]]] 応答と [CODE(HTTP)[[[404]]]] 応答の混乱を明確化。

> Warnings could be cached incorrectly, or not updated appropriately.
(Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
also needed to be a general header, as PUT or other methods may have need for it in requests.

[CODE(HTTP)[Warning]] を間違ってキャッシュすることや不適切に更新しないことができた。
[CODE(HTTP)[[[Warning]]]] は一般頭である必要もありました。 [CODE(HTTP)[[[PUT]]]]
や他の方式は要求中で [CODE(HTTP)[Warning]] が必要かもしれませんから。

> Transfer-coding had significant problems, particularly with
interactions with chunked encoding. The solution is that transfer-codings become as full fledged as content-codings. This involves
adding an IANA registry for transfer-codings (separate from content
codings), a new header field (TE) and enabling trailer headers in the
future. Transfer encoding is a major performance benefit, so it was
worth fixing [39]. TE also solves another, obscure, downward
interoperability problem that could have occurred due to interactions
between authentication trailers, chunked encoding and HTTP/1.0
clients.(Section 3.6, 3.6.1, and 14.39)

[CODE(ABNF)[[[transfer-coding]]]] は、特に [CODE(HTPT)[[[chunked]]]]
符号化の相互作用に関して、重大な問題がありました。
解決策として、 [CODE(ABNF)[transfer-coding]] は完全に [CODE(ABNF)[[[content-coding]]]]
を覆うものとします。これは、 [CODE(ABNF)[transfer-coding]] の
[[IANA]] 登録簿と新しい頭欄 ([CODE(HTTP)[[[TE]]]]) の追加、
将来 trailer 頭を可能にすることを含みます。
転送符号化は大きな効率上の利益があり、修正する価値がありました。
[CODE(HTTP)[TE]] は、他の、認証 trailer や [CODE(HTTP)[chunked]] 符号化や HTTP/1.0
クライアントとの相互作用について起こり得る、不明瞭な下方相互運用性問題も解決します。

> The PATCH, LINK, UNLINK methods were defined but not commonly
implemented in previous versions of this specification. See RFC 2068 [33].

[CODE(HTTP)[[[PATCH]]]], [CODE(HTTP)[[[LINK]]]],
[CODE(HTTP)[[[UNLINK]]]] 各方式はこの仕様書の以前の版で定義されていましたが、広く実装されませんでした。
[[RFC2068]] を参照。

> The Alternates, Content-Version, Derived-From, Link, URI, Public and
Content-Base header fields were defined in previous versions of this
specification, but not commonly implemented. See RFC 2068 [33].

[CODE(HTTP)[[[Alternates]]]], [CODE(HTTP)[[[Content-Version]]]],
[CODE(HTTP)[[[Derived-From]]]], [CODE(HTTP)[[[Link]]]],
[CODE(HTTP)[[[URI]]]], [CODE(HTTP)[[[Public]]]], 
[CODE(HTTP)[[[Content-Base]]]] 各頭欄はこの仕様書の以前の版で定義されていましたが、広く実装されませんでした。
RFC 2068 を参照。

* 20 Index
> Please see the PostScript version of this RFC for the INDEX.

索引はこの RFC の 「「PostScript]] 版を参照してください。

* 21.  Full Copyright Statement
> Copyright (C) The Internet Society (1999).  All Rights Reserved.

以下略。 [[RFCのライセンス]]を参照。

* Acknowledgement
> Funding for the RFC Editor function is currently provided by the Internet Society.

* メモ
- [1] [WEAK[2003-10-09 09:38:41 +00:00]] ''[[名無しさん]]'': エラーコード
- [2] >>1 HTTP 応答に使われる3桁数字は、[[状態符号]], 応答符号, [RUBY[誤り符号] [エラー・コード]]などと呼ばれます。