HTTP RFC

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

[21] 最新の情報は、 HTTP や RFC 723x を参照してください。

仕様書

[17] RFC 2068 - Hypertext Transfer Protocol -- HTTP/1.1 ( (2014-09-29 05:21:03 +09:00 版)) http://tools.ietf.org/html/rfc2068
[506] RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1 (2013-09-17 10:26:33 +09:00 版) http://tools.ietf.org/html/rfc2616

日本語訳

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

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 はこのプロトコルについて懸念しており、この文書が比較的早く標準化過程文書で置き換えられることを期待しています。

Abstract

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

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

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

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

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

RFC 1945 1.; RFC 2068・2616 1 Introduction

1.1 Purpose

The Hypertext Transfer Protocol (HTTP) is an application-level protocol ~~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. 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. 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, ~~and~~ 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.

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

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 よりも強い要件を含んでいます。

Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods {2616} and headers ~~to be used to~~ that indicate the purpose of a request {2616} [47] . It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) ~~{1945} [2]~~ {2068,2616} [3]], as a location (URL) [4] or name (URN) ~~{1945} [16]~~ {2616} [20] , for indicating the resource on to which a method is to be applied. Messages are passed in a format similar to that used by Internet ~~Mail [7] and~~ mail [9] as defined by the Multipurpose Internet Mail Extensions (MIME) ~~{1945} [5]~~ {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 ~~protocols, such as SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing~~ 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 ~~and simplifying the implementation of user agents~~.

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

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

RFC 2068・2616 1.2 Requirements

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

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]] で説明されている通り解釈します。

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

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

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 通信に関係したり、対象となったりする役割を指す数々の言葉を使います。

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

RFC 1945 1.3; RFC 2068・2616 1.4 Overall Operation

The HTTP protocol is ~~based on~~ a request/response ~~paradigm~~ protocol. A client ~~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 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 entity-body content. The relationship between HTTP and MIME is described in appendix 19.4.

HTTP プロトコルは、要求・応答プロトコルです。クライアントは、要求方式, URI, プロトコルの版, それに続けて要求修飾子・クライアント情報・場合によっては本体内容を含む MIME 的メッセージという書式で、鯖との接続上で鯖に要求を送ります。鯖は、メッセージのプロトコル版と成功または誤りの符号を含んだ状態行と、それに続けて鯖情報・実体のメタ情報・場合によっては 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 通信は、利用者エージェントによって初期化され、起源鯖の資源に適用される要求で構成します。最も単純な場合、これは利用者エージェント (UA) と起源鯖 (O) の間の一つの接続 (v) により達成されます。

   request chain ------------------------>
UA -------------------v------------------- O
   <----------------------- response chain

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

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

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

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

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

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

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

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;. ~~these~~ 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 の目標は、高い信頼性や、それが無理でも少なくても確実に失敗を示すことが必要なウェブ応用を構築する人の需要に合致するプロトコル構造を導入しつつ、既に用いられている多用な構成に対応することです。

~~On the Internet,~~ HTTP communication ~~generally~~ usually takes place over TCP/IP connections. The default port is TCP 80 ~~{1945} [15]~~ {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;~~, and~~ the mapping of the ~~HTTP/1.0~~ 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 要求・応答構造から件のプロトコルの輸送データ単位への写像はこの仕様書の適用範囲外です。

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

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 では、種々の理由で接続を閉じても構いませんが、一つの接続を一つ以上の要求・応答交換に使っても構いません。

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

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 ~~{1945} HTTP/1.0~~ 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 ~~{1945} should~~ SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they ~~{1945} should~~ SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.

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

The line terminator for ~~{1945} HTTP-header~~ 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.

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

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

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

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

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

o - HTTP/1.1 clients and caches ~~should~~ 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).
o - An HTTP/1.1 implementation ~~may~~ 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.
o - All expiration-related calculations ~~must~~ MUST be done in GMT. The local time zone MUST NOT influence the calculation or comparison of an age or expiration time.
o - If an HTTP header incorrectly carries a date value with a time zone other than GMT, it ~~must~~ MUST be converted into GMT using the most conservative possible conversion.

HTTP/1.1 クライアントおよびキャッシュは、50年よりも将来に見える RFC850 日付は実際は過去のものとみなすべきです (これは2000年問題を解決するのを助けます)。
HTTP/1.1 実装は解析した Expires 日付を適切な値よりも前のものとして内部的に表現しても構いませんが、解析した Expires 日付を適切な値よりも後のものとして内部的に表現してはいけません。
すべての満期関連の計算は GMT で行わなければなりません。地方時間帯が齢や満期時刻の計算や比較に影響してはなりません。
HTTP 頭が不正に GMT 以外の時間帯で日付値を伝達しているときは、最も用心深い可能な変換を用いて GMT に変換しなければなりません。

RFC 1945 (HTTP/1.0) D.; RFC 2068 (HTTP/1.1) 19.6; RFC 2616 (HTTP/1.1) 19.5 Additional Features

~~This appendix documents~~ {2616} RFC 1945 and RFC 2068 document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most ~~HTTP/1.0~~ HTTP/1.1 applications. ~~~~Implementors~~ Implementers should~~ Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability with, other ~~HTTP/1.0~~ HTTP/1.1 applications. 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 応用との相互通信性はあてにはなりません。そのうちの幾つかは提案されている実験的機能を説明するもので、幾つかは実験的展開が欠けていることを発見した機能で今は基底 HTTP/1.1 仕様書に言及されているものを説明しています。

{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 からの他の多くの頭、例えば Content-Disposition や Title のようなものもしばしば実装されています (RFC2076 参照)。

RFC 1945 (HTTP/1.0) D.1; RFC 2068 (HTTP/1.1) 19.6.1 Additional Request Methods

→PUT, PATCH, DELETE, LINK, UNLINK

RFC 1945 (HTTP/1.0) D.2; RFC 2068 (HTTP/1.1) 19.6.2 Additional Header Field Definitions

→Alternates, Content-Version, Derived-From, Link, Title, URI, Accept, Accept-Charset, Accept-Encoding, Accept-Language, Content-Language, MIME-Version, Retry-After

RFC 2616 (HTTP/1.1) 19.5.1 Content-Disposition

→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, the time of composing this specification (1996), we would expect commercial HTTP/1.1 servers to:

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

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

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

And we would expect HTTP/1.1 clients to:

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

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

HTTP/1.0 および 1.1 の応答の 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. ~~A few~~ Some implementations implement the Keep-Alive version of persistent connections described in section ~~19.7.1.1~~ 19.7.1 of RFC 2068 [33] .

HTTP/1.0 のほとんどの実装では、各接続はクライアントが要求の前に確立し、鯖が応答を送信した後に閉じます。幾つかの実装は 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.

クライアントと鯖が Host 要求頭に対応し、 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 応用の更新も含む。) が次の要件を正しく実装することがきわめて重要であります。

o -

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

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

RFC 2068 19.7.1; RFC 2616 19.6.2 Compatibility with HTTP/1.0 Persistent Connections

→Connection

RFC 2068 19.7.1.1 The Keep-Alive Header

→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 (訳注: 201 (作成済み) 応答) は資源が最初に作成される時に 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].

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)

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

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

キャッシュの問題を解決するために identity 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 Cache-Control 模型で場合が抜けていました。この抜けていた場合を追加するために s-maxage を導入しました。

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

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)

鯖 (特に串) が応答の完全な長さを知らないけどバイト範囲要求を給仕することはできるという状況があります。従って、メッセージの完全な長さを示さない 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)

範囲要求応答ですべてのメタ・データが常に返されるとすると非常にやかましくなります。 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)

満足不能範囲要求についての問題を解決。これには二つの場合があります。構文的な問題の場合と、文書に存在しない範囲の場合です。この曖昧性を解決するために、文書の実際の内容の外側のバイト範囲要求の誤りを示すのに必要な 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.x の実装の動作についての要件を誤って課していた箇所で「HTTP/1.1 以降」を「HTTP/1.1」に変更。
「クライアント」一般ではなく利用者エージェントが要求を再試行するべきであることを明確化。
クライアントが予期せぬ 100 (継続) 応答を無視することおよび串が 100 応答を転送することについての要件を 1xx 応答一般の要件に変更。
非 TCP 転送路で HTTP を使うのが可能であることを明らかにするために TCP 特有の言葉を修正。
起源鯖が必須の 100 (継続) 応答を送る前に要求本体を待ってはならないことを要求。
鯖が既に要求本体の幾らかを見ているときには 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.

この変更は、 Expect 頭と 417 状態符号を追加します。

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

串は適切な時には Content-Length を追加することができるべきです。

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

403 応答と 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.

Warning を間違ってキャッシュすることや不適切に更新しないことができた。 Warning は一般頭である必要もありました。 PUT や他の方式は要求中で 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)

transfer-coding は、特に chunked 符号化の相互作用に関して、重大な問題がありました。解決策として、 transfer-coding は完全に content-coding を覆うものとします。これは、 transfer-coding の IANA 登録簿と新しい頭欄 (TE) の追加、将来 trailer 頭を可能にすることを含みます。転送符号化は大きな効率上の利益があり、修正する価値がありました。 TE は、他の、認証 trailer や 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].

PATCH, LINK, 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].

Alternates, Content-Version, Derived-From, Link, URI, Public, 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.

License

RFCのライセンス。

メモ

HTTP

RFC 1945

仕様書