RFC2068 日本語訳
2068 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys,J. Mogul, H. Frystyk, T. Berners-Lee. January 1997. (Format: TXT=378114 bytes) (Obsoleted by RFC2616) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Fielding
Request for Comments: 2068 UC Irvine
Category: Standards Track J. Gettys
J. Mogul
DEC
H. Frystyk
T. Berners-Lee
MIT/LCS
January 1997
コメントを求める要求をさばいて、作業部会R.をネットワークでつないでください: 2068年のUCアーバインカテゴリ: 標準化過程J.Gettys J.要人12月のH.Frystyk T.バーナーズ・リーMIT/LCS1997年1月
Hypertext Transfer Protocol -- HTTP/1.1
ハイパーテキスト転送プロトコル--HTTP/1.1
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
ハイパーテキストTransferプロトコル(HTTP)は分配されて、協力的なハイパーメディアインフォメーションシステムのためのアプリケーションレベルプロトコルです。それは多くのタスクに使用できる、一般的で、国がなくて、オブジェクト指向のプロトコルです、ネームサーバや分散オブジェクトマネージメントシステムのように、要求方法の拡大で。 HTTPの特徴は、データ表現のタイプと交渉です、システムが移されるデータの如何にかかわらず構築されるのを許容して。
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".
1990年以来HTTPはWWWのグローバルな情報イニシアチブで使用中です。 この仕様は「HTTP/1.1インチ」と呼ばれたプロトコルを定義します。
Table of Contents
目次
1 Introduction.............................................7
1.1 Purpose ..............................................7
1.2 Requirements .........................................7
1.3 Terminology ..........................................8
1.4 Overall Operation ...................................11
2 Notational Conventions and Generic Grammar..............13
2.1 Augmented BNF .......................................13
2.2 Basic Rules .........................................15
3 Protocol Parameters.....................................17
3.1 HTTP Version ........................................17
1つの序論…7 1.1目的…7 1.2の要件…7 1.3用語…8 1.4 総合的な操作…11 2 記号法のコンベンションと一般的な文法…13 2.1はBNFを増大させました…13 2.2 基本的な規則…15 3 パラメタについて議定書の中で述べてください…17 3.1 HTTPバージョン…17
Fielding, et. al. Standards Track [Page 1] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[1ページ]RFC2068HTTP/1997年1月1.1日
3.2 Uniform Resource Identifiers ........................18
3.2.1 General Syntax ...................................18
3.2.2 http URL .........................................19
3.2.3 URI Comparison ...................................20
3.3 Date/Time Formats ...................................21
3.3.1 Full Date ........................................21
3.3.2 Delta Seconds ....................................22
3.4 Character Sets ......................................22
3.5 Content Codings .....................................23
3.6 Transfer Codings ....................................24
3.7 Media Types .........................................25
3.7.1 Canonicalization and Text Defaults ...............26
3.7.2 Multipart Types ..................................27
3.8 Product Tokens ......................................28
3.9 Quality Values ......................................28
3.10 Language Tags ......................................28
3.11 Entity Tags ........................................29
3.12 Range Units ........................................30
4 HTTP Message............................................30
4.1 Message Types .......................................30
4.2 Message Headers .....................................31
4.3 Message Body ........................................32
4.4 Message Length ......................................32
4.5 General Header Fields ...............................34
5 Request.................................................34
5.1 Request-Line ........................................34
5.1.1 Method ...........................................35
5.1.2 Request-URI ......................................35
5.2 The Resource Identified by a Request ................37
5.3 Request Header Fields ...............................37
6 Response................................................38
6.1 Status-Line .........................................38
6.1.1 Status Code and Reason Phrase ....................39
6.2 Response Header Fields ..............................41
7 Entity..................................................41
7.1 Entity Header Fields ................................41
7.2 Entity Body .........................................42
7.2.1 Type .............................................42
7.2.2 Length ...........................................43
8 Connections.............................................43
8.1 Persistent Connections ..............................43
8.1.1 Purpose ..........................................43
8.1.2 Overall Operation ................................44
8.1.3 Proxy Servers ....................................45
8.1.4 Practical Considerations .........................45
8.2 Message Transmission Requirements ...................46
9 Method Definitions......................................48
9.1 Safe and Idempotent Methods .........................48
3.2のUniform Resource Identifier…18 3.2 .1の一般構文…18 3.2 .2http URL…19 3.2 .3 URI比較…20 3.3 日付/時間形式…21 3.3 .1 いっぱいに、デートしてください…21 3.3 .2 デルタ秒…22 3.4の文字コード…22 3.5 満足しているコーディング…23 3.6 コーディングを移してください…24 3.7のメディアタイプ…25 3.7 .1 Canonicalizationとテキストはデフォルトとします…26 3.7 .2 複合タイプ…27 3.8 製品象徴…28 3.9 上質の値…28 3.10 言語タグ…28 3.11 実体タグ…29 3.12 範囲ユニット…30 4HTTPメッセージ…30 4.1 メッセージタイプ…30 4.2 メッセージヘッダー…31 4.3メッセージ本体…32 4.4 メッセージの長さ…32 4.5 一般ヘッダーフィールド…34 5 要求します。34 5.1 要求線…34 5.1 .1方法…35 5.1 .2要求URI…35 5.2 要求で特定されたリソース…37 5.3 ヘッダーフィールドを要求してください…37 6応答…38 6.1状況表示行…38 6.1 .1のステータスコードと理由句…39 6.2 応答ヘッダーフィールド…41 7実体…41 7.1 実体ヘッダーフィールド…41 7.2実体本体…42 7.2 .1 タイプしてください…42 7.2 .2の長さ…43 8コネクションズ…43 8.1のパーシステントコネクション…43 8.1 .1目的…43 8.1 .2 総合的な操作…44 8.1 .3のProxyサーバ…45 8.1 .4の実用的な問題…45 8.2 メッセージトランスミッション要件…46 9 方法定義…48 9.1金庫とベキ等元方法…48
Fielding, et. al. Standards Track [Page 2] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[2ページ]RFC2068HTTP/1997年1月1.1日
9.1.1 Safe Methods .....................................48
9.1.2 Idempotent Methods ...............................49
9.2 OPTIONS .............................................49
9.3 GET .................................................50
9.4 HEAD ................................................50
9.5 POST ................................................51
9.6 PUT .................................................52
9.7 DELETE ..............................................53
9.8 TRACE ...............................................53
10 Status Code Definitions................................53
10.1 Informational 1xx ..................................54
10.1.1 100 Continue ....................................54
10.1.2 101 Switching Protocols .........................54
10.2 Successful 2xx .....................................54
10.2.1 200 OK ..........................................54
10.2.2 201 Created .....................................55
10.2.3 202 Accepted ....................................55
10.2.4 203 Non-Authoritative Information ...............55
10.2.5 204 No Content ..................................55
10.2.6 205 Reset Content ...............................56
10.2.7 206 Partial Content .............................56
10.3 Redirection 3xx ....................................56
10.3.1 300 Multiple Choices ............................57
10.3.2 301 Moved Permanently ...........................57
10.3.3 302 Moved Temporarily ...........................58
10.3.4 303 See Other ...................................58
10.3.5 304 Not Modified ................................58
10.3.6 305 Use Proxy ...................................59
10.4 Client Error 4xx ...................................59
10.4.1 400 Bad Request .................................60
10.4.2 401 Unauthorized ................................60
10.4.3 402 Payment Required ............................60
10.4.4 403 Forbidden ...................................60
10.4.5 404 Not Found ...................................60
10.4.6 405 Method Not Allowed ..........................61
10.4.7 406 Not Acceptable ..............................61
10.4.8 407 Proxy Authentication Required ...............61
10.4.9 408 Request Timeout .............................62
10.4.10 409 Conflict ...................................62
10.4.11 410 Gone .......................................62
10.4.12 411 Length Required ............................63
10.4.13 412 Precondition Failed ........................63
10.4.14 413 Request Entity Too Large ...................63
10.4.15 414 Request-URI Too Long .......................63
10.4.16 415 Unsupported Media Type .....................63
10.5 Server Error 5xx ...................................64
10.5.1 500 Internal Server Error .......................64
10.5.2 501 Not Implemented .............................64
9.1.1 確実な方法…48 9.1 .2 ベキ等元方法…49 9.2のオプション…49 9.3 得ます。50 9.4 向かってください…50 9.5 ポスト…51 9.6 置きます。52 9.7 削除します。53 9.8 跡…53 10のステータスコード定義…53 10.1 情報の1xx…54 10.1.1 100 続いてください…54 10.1.2 101 切り換えプロトコル…54 10.2 うまくいっている2xx…54 10.2.1 200 OK…54 10.2.2 201 作成される…55 10.2.3 202 受け入れられる…55 10.2.4 203 非信頼できる情報…55 10.2.5 204 内容がありません…55 10.2.6 205 内容をリセットしてください…56 10.2.7 206 部分的な内容…56 10.3リダイレクション3xx…56 10.3.1 300 選択式…57 10.3.2 301 永久に、動く…57 10.3.3 302 一時動かされました…58 10.3.4 303 別に見てください…58 10.3.5 304 変更されない…58 10.3.6 305 プロキシを使用してください…59 10.4 クライアント誤り4xx…59 10.4.1 400 悪い要求…60 10.4.2 401 権限のない…60 10.4.3 402 支払いが必要です…60 10.4.4 403 禁制…60 10.4.5 404 見つけられませんでした…60 10.4.6 405 許容されなかった方法…61 10.4.7 406 許容できない…61 10.4.8 407 プロキシ認証が必要です…61 10.4.9 408 タイムアウトを要求してください…62 10.4.10 409 闘争してください…62 10.4.11 410 過ぎ去る…62 10.4.12 411 長さが必要です…63 10.4.13 412 前提条件は失敗しました…63 10.4.14 413 大き過ぎる状態で実体を要求してください…63 10.4.15 414 要求URIも長さ…………………。63 10.4.16 415 サポートされないメディアタイプ…63 10.5 サーバ誤り5xx…64 10.5.1 500 内部サーバーエラー…64 10.5.2 501 実行されませんでした…64
Fielding, et. al. Standards Track [Page 3] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[3ページ]RFC2068HTTP/1997年1月1.1日
10.5.3 502 Bad Gateway .................................64
10.5.4 503 Service Unavailable .........................64
10.5.5 504 Gateway Timeout .............................64
10.5.6 505 HTTP Version Not Supported ..................65
11 Access Authentication..................................65
11.1 Basic Authentication Scheme ........................66
11.2 Digest Authentication Scheme .......................67
12 Content Negotiation....................................67
12.1 Server-driven Negotiation ..........................68
12.2 Agent-driven Negotiation ...........................69
12.3 Transparent Negotiation ............................70
13 Caching in HTTP........................................70
13.1.1 Cache Correctness ...............................72
13.1.2 Warnings ........................................73
13.1.3 Cache-control Mechanisms ........................74
13.1.4 Explicit User Agent Warnings ....................74
13.1.5 Exceptions to the Rules and Warnings ............75
13.1.6 Client-controlled Behavior ......................75
13.2 Expiration Model ...................................75
13.2.1 Server-Specified Expiration .....................75
13.2.2 Heuristic Expiration ............................76
13.2.3 Age Calculations ................................77
13.2.4 Expiration Calculations .........................79
13.2.5 Disambiguating Expiration Values ................80
13.2.6 Disambiguating Multiple Responses ...............80
13.3 Validation Model ...................................81
13.3.1 Last-modified Dates .............................82
13.3.2 Entity Tag Cache Validators .....................82
13.3.3 Weak and Strong Validators ......................82
13.3.4 Rules for When to Use Entity Tags and Last-
modified Dates..........................................85
13.3.5 Non-validating Conditionals .....................86
13.4 Response Cachability ...............................86
13.5 Constructing Responses From Caches .................87
13.5.1 End-to-end and Hop-by-hop Headers ...............88
13.5.2 Non-modifiable Headers ..........................88
13.5.3 Combining Headers ...............................89
13.5.4 Combining Byte Ranges ...........................90
13.6 Caching Negotiated Responses .......................90
13.7 Shared and Non-Shared Caches .......................91
13.8 Errors or Incomplete Response Cache Behavior .......91
13.9 Side Effects of GET and HEAD .......................92
13.10 Invalidation After Updates or Deletions ...........92
13.11 Write-Through Mandatory ...........................93
13.12 Cache Replacement .................................93
13.13 History Lists .....................................93
14 Header Field Definitions...............................94
14.1 Accept .............................................95
10.5.3 502 悪いゲートウェイ…64 10.5.4 503 入手できないサービス…64 10.5.5 504 ゲートウェイタイムアウト…64 10.5.6 505 バージョンが支持しなかったHTTP…65 11は認証にアクセスします…65 11.1の基本的な認証計画…66 11.2 認証計画を読みこなしてください…67 12の満足している交渉…67 12.1 サーバ駆動の交渉…68 12.2 エージェント駆動の交渉…69 12.3 わかりやすい交渉…HTTPでキャッシュされる70 13…70 13.1.1 正当性をキャッシュしてください…72 13.1.2 警告…73 13.1.3 キャッシュ制御メカニズム…74 13.1.4 明白なユーザエージェント警告…74 13.1.5 規則と警告への例外…75 13.1.6 クライアントによって制御された振舞い…75 13.2満了モデル…75 13.2.1 サーバで指定された満了…75 13.2.2 発見的な満了…76 13.2.3 計算の年をとってください…77 13.2.4 満了計算…79 13.2.5 満了値のあいまいさを除きます…80 13.2.6 複数の応答のあいまいさを除きます…80 13.3合法化モデル…81 13.3.1 最終更新日日付…82 13.3.2 実体タグキャッシュValidators…82 13.3.3 弱くて強いValidators…82 13.3.4 Use Entity TagsへのWhenとLastのための規則はDatesを変更しました…85 13.3.5 非の有効にするConditionals…86 13.4 応答Cachability…86 13.5 キャッシュから応答を構成します…87 13.5.1 終わりから終わりとホップごとのヘッダー…88 13.5.2 非修正できるヘッダー…88 13.5.3 ヘッダーを結合します…89 13.5.4 バイトを結合するのは及びます…90 13.6 キャッシュは応答を交渉しました…90 13.7 共有されて非共有されたキャッシュ…91 13.8の誤りか不完全な応答が振舞いをキャッシュします…91 13.9回の副作用、得て、上に立ちます。92 13.10無効にするアップデートか削除の後の…92 13.11 通じて書き義務的…93 13.12 交換をキャッシュしてください…93 13.13 歴史はリストアップされています…93 14のヘッダーフィールド定義…94 14.1 受け入れてください…95
Fielding, et. al. Standards Track [Page 4] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[4ページ]RFC2068HTTP/1997年1月1.1日
14.2 Accept-Charset .....................................97
14.3 Accept-Encoding ....................................97
14.4 Accept-Language ....................................98
14.5 Accept-Ranges ......................................99
14.6 Age ................................................99
14.7 Allow .............................................100
14.8 Authorization .....................................100
14.9 Cache-Control .....................................101
14.9.1 What is Cachable ...............................103
14.9.2 What May be Stored by Caches ...................103
14.9.3 Modifications of the Basic Expiration Mechanism 104
14.9.4 Cache Revalidation and Reload Controls .........105
14.9.5 No-Transform Directive .........................107
14.9.6 Cache Control Extensions .......................108
14.10 Connection .......................................109
14.11 Content-Base .....................................109
14.12 Content-Encoding .................................110
14.13 Content-Language .................................110
14.14 Content-Length ...................................111
14.15 Content-Location .................................112
14.16 Content-MD5 ......................................113
14.17 Content-Range ....................................114
14.18 Content-Type .....................................116
14.19 Date .............................................116
14.20 ETag .............................................117
14.21 Expires ..........................................117
14.22 From .............................................118
14.23 Host .............................................119
14.24 If-Modified-Since ................................119
14.25 If-Match .........................................121
14.26 If-None-Match ....................................122
14.27 If-Range .........................................123
14.28 If-Unmodified-Since ..............................124
14.29 Last-Modified ....................................124
14.30 Location .........................................125
14.31 Max-Forwards .....................................125
14.32 Pragma ...........................................126
14.33 Proxy-Authenticate ...............................127
14.34 Proxy-Authorization ..............................127
14.35 Public ...........................................127
14.36 Range ............................................128
14.36.1 Byte Ranges ...................................128
14.36.2 Range Retrieval Requests ......................130
14.37 Referer ..........................................131
14.38 Retry-After ......................................131
14.39 Server ...........................................132
14.40 Transfer-Encoding ................................132
14.41 Upgrade ..........................................132
14.2 Charsetを受け入れます…97 14.3 コード化を受け入れます…97 14.4 言語を受け入れます…98 14.5 範囲を受け入れます…99 14.6 年をとってください…99 14.7 許容します。100 14.8認可…100 14.9 キャッシュコントロール…101 14.9 .1 Cachableは何です…103 14.9 .2 どんな5月に、CachesによるStoredはそうであるか。103 14.9 基本的な満了メカニズム104 14.9.4のものの.3の変更が、Revalidationをキャッシュして、コントロールを再び積みます…105 14.9 .5 指示を変えないでください…107 14.9 .6 コントロール拡大をキャッシュしてください…108 14.10接続…109 14.11 満足している基地…109 14.12 内容をコード化しています…110 14.13 満足している言語…110 14.14 満足している長さ…111 14.15 満足している位置…112 14.16 満足しているMD5…113 14.17 内容に及んでください…114 14.18コンテントタイプ…116 14.19 デートしてください…116 14.20ETag…117 14.21 期限が切れます…117、14.22、…118 14.23 接待します。119 14.24 以来変更されるなら…119、14.25、-合ってください、…121 14.26 なにも合っていないなら…122、14.27、-及んでください、…123 14.28 以来変更されていないなら…124 14.29 最後、変更される…124 14.30位置…125 14.31 マックス-フォワード…125 14.32Pragma…126 14.33 …をプロキシで認証してください…127 14.34プロキシ認可…127 14.35公衆…127 14.36 及んでください…128 14.36 .1バイトは及びます…128 14.36 .2 範囲検索要求…130 14.37Referer…131 14.38 -後に再試行してください…131 14.39サーバ…132 14.40 転送をコード化しています…132 14.41 アップグレードしてください…132
Fielding, et. al. Standards Track [Page 5] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[5ページ]RFC2068HTTP/1997年1月1.1日
14.42 User-Agent .......................................134
14.43 Vary .............................................134
14.44 Via ..............................................135
14.45 Warning ..........................................137
14.46 WWW-Authenticate .................................139
15 Security Considerations...............................139
15.1 Authentication of Clients .........................139
15.2 Offering a Choice of Authentication Schemes .......140
15.3 Abuse of Server Log Information ...................141
15.4 Transfer of Sensitive Information .................141
15.5 Attacks Based On File and Path Names ..............142
15.6 Personal Information ..............................143
15.7 Privacy Issues Connected to Accept Headers ........143
15.8 DNS Spoofing ......................................144
15.9 Location Headers and Spoofing .....................144
16 Acknowledgments.......................................144
17 References............................................146
18 Authors' Addresses....................................149
19 Appendices............................................150
19.1 Internet Media Type message/http ..................150
19.2 Internet Media Type multipart/byteranges ..........150
19.3 Tolerant Applications .............................151
19.4 Differences Between HTTP Entities and
MIME Entities...........................................152
19.4.1 Conversion to Canonical Form ...................152
19.4.2 Conversion of Date Formats .....................153
19.4.3 Introduction of Content-Encoding ...............153
19.4.4 No Content-Transfer-Encoding ...................153
19.4.5 HTTP Header Fields in Multipart Body-Parts .....153
19.4.6 Introduction of Transfer-Encoding ..............154
19.4.7 MIME-Version ...................................154
19.5 Changes from HTTP/1.0 .............................154
19.5.1 Changes to Simplify Multi-homed Web Servers and
Conserve IP Addresses .................................155
19.6 Additional Features ...............................156
19.6.1 Additional Request Methods .....................156
19.6.2 Additional Header Field Definitions ............156
19.7 Compatibility with Previous Versions ..............160
19.7.1 Compatibility with HTTP/1.0 Persistent
Connections............................................161
14.42ユーザエージェント…134 14.43 異なってください…を通して134、14.44、…135 14.45 警告…137 14.46 …をWWW認証してください…139 15 セキュリティ問題…139 15.1 クライアントの認証…139 15.2 認証計画について好きなのを選んでよいといいます…140 サーバログ情報の15.3乱用…141 15.4 機密情報の転送…141 15.5の攻撃がファイルとパス名を基礎づけました…142 15.6 個人的な情報…143 15.7 プライバシー問題はヘッダーを受け入れるために接続しました…143 15.8DNSスプーフィング…144 15.9 位置のヘッダーとスプーフィング…144 16の承認…144 17の参照箇所…146 18人の作者のアドレス…149 19個の付録…150 19.1 インターネットメディアTypeメッセージ/http…150 19.2 インターネットのメディアのTypeの複合/byteranges…150 19.3 許容性があるアプリケーション…151 HTTP実体とMIME実体の19.4の違い…152 19.4 .1 正準への変換は形成されます…152 19.4 .2 日付の形式の変換…153 19.4 内容をコード化していることの.3導入…153 19.4 .4 満足している転送コード化しないこと…153 19.4 .5 複合身体部分のHTTPヘッダ分野…153 19.4 転送コード化の.6導入…154 19.4 .7MIMEバージョン…154 19.5 HTTP/1.0から、変化します…そして、154 19.5 簡素化する.1回の変化、マルチ、家へ帰り、ウェブサーバー、IPアドレスを保存してください…155 19.6 追加特徴…156 19.6 .1 追加要求方法…156 19.6 .2 追加ヘッダーフィールド定義…156 旧バージョンとの19.7の互換性…160 19.7 HTTP/1.0のパーシステントコネクションとの.1の互換性…161
Fielding, et. al. Standards Track [Page 6] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[6ページ]RFC2068HTTP/1997年1月1.1日
1 Introduction
1つの序論
1.1 Purpose
1.1 目的
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. 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 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.
ハイパーテキストTransferプロトコル(HTTP)は分配されて、協力的なハイパーメディアインフォメーションシステムのためのアプリケーションレベルプロトコルです。1990年以来HTTPはWWWのグローバルな情報イニシアチブで使用中です。 HTTP/0.9と呼ばれたHTTPの最初のバージョンはインターネット中の生データ転送のための簡単なプロトコルでした。 RFC1945[6]によって定義されるHTTP/1.0はMIMEのようなメッセージの形式にはあるメッセージを許容することによって、プロトコルを改良しました、要求/応答意味論にデータに関して移されたmetainformationと修飾語を含んでいて。 しかしながら、HTTP/1.0は階層的なプロキシ、キャッシュ、パーシステントコネクションの必要性、および事実上のホストの効果を十分考慮に入れません。 添加、自称する不完全に実行されたアプリケーションの増殖では、「2つの交信アプリケーションが互いの本当の能力を決定するように、HTTP/1インチはプロトコルバージョン変化を必要としました」。
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 that indicate the purpose of a request. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [3][20], as a location (URL) [4] or name (URN) , for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by Internet mail as defined by the Multipurpose Internet Mail Extensions (MIME).
実用的な情報システムは検索、フロントエンドアップデート、および注釈を含む簡単な検索より多くの機能性を必要とします。 HTTPは要求の目的を示す制限のない方法を許容します。 それはUniform Resource Identifier(URI)[3][20]によって提供された参照の規律に建てられます、位置の(URL)[4]か名前(URN)として、適用されている方法がことであるリソースを示すために。 メッセージはマルチパーパスインターネットメールエクステンション(MIME)によって定義されるようにインターネット・メールによって使用されたそれと同様の形式で通過されます。
HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet 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.
また、HTTPはユーザエージェントとプロキシ/ゲートウェイとの他のインターネット・システムへのコミュニケーションに一般的なプロトコルとして使用されます、SMTP[16]、NNTP[13]、FTP[18]、ゴーファー[2]、およびWAIS[10]プロトコルによって支持されたものを含んでいて。 このように、HTTPはさまざまのアプリケーションによって利用可能なリソースへの基本的なハイパーメディアアクセスを許します。
1.2 Requirements
1.2 要件
This specification uses the same words as RFC 1123 [8] for defining the significance of each particular requirement. These words are:
この仕様は、それぞれの特定の要件の意味を定義するのにRFC1123[8]と同じ単語を使用します。 これらの単語は以下の通りです。
MUST
This word or the adjective "required" means that the item is an
absolute requirement of the specification.
「必要である」というThis単語か形容詞が、項目が仕様に関する絶対条件であることを意味しなければなりません。
Fielding, et. al. Standards Track [Page 7] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[7ページ]RFC2068HTTP/1997年1月1.1日
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.
SHOULD This単語か形容詞がこの項目を無視する特定の事情の正当な理由を存在するかもしれない手段に「推薦しました」が、完全な含意は、理解されていて異なったコースを選ぶ前に慎重に熟慮されたケースであるべきです。
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.
この項目は、This単語か形容詞的「任意」の手段ですが、本当に、任意の状態でそうするかもしれません。 特定の市場がそれを必要とするか、または例えば製品を高めるので、1つの業者が、項目を含んでいるのを選ぶかもしれません。 別の業者は同じ項目を省略するかもしれません。
An implementation is not compliant if it fails to satisfy one or more of the MUST requirements for the protocols it implements. An implementation that satisfies all the MUST and all the SHOULD requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST requirements but not all the SHOULD requirements for its protocols is said to be "conditionally compliant."
1つか以上を満たさないなら実現が対応でない、それが実行するプロトコルのための要件はそうしなければなりません。 そして、すべてを満たす実現、プロトコルのためのすべてのSHOULD要件が「無条件に言いなりになる」と言われています;でなければならない すべてを満たすもの、プロトコルのためのすべてのSHOULD要件だけが「条件付きに言いなりになる」と言われているというわけではないという要件はそうしなければなりません。
1.3 Terminology
1.3 用語
This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.
この仕様は、HTTPコミュニケーションについて関係者によって果たされた役割について言及して、反対するのに項数を使用します。
connection
A transport layer virtual circuit established between two programs
for the purpose of communication.
接続のAトランスポート層の仮想のサーキットは2の間にコミュニケーションの目的のためのプログラムを設立しました。
message
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in section 4 and
transmitted via the connection.
HTTPコミュニケーションの原単位を通信させてください、セクション4で定義されて、接続で伝えられた構文に合っている八重奏の構造化された系列から成って。
request
An HTTP request message, as defined in section 5.
セクション5で定義されるようにAn HTTP要求メッセージを要求してください。
response
An HTTP response message, as defined in section 6.
セクション6で定義されるような応答An HTTP応答メッセージ。
resource
A network data object or service that can be identified by a URI,
as defined in section 3.2. Resources may be available in multiple
representations (e.g. multiple languages, data formats, size,
resolutions) or vary in other ways.
リソースAネットワークデータ・オブジェクトかセクション3.2で定義されるようにURIで特定できるサービス。 リソースは、複数の表現(例えば、複数の言語、データ形式、サイズ、解決)で利用可能であるか、または他の方法で異なるかもしれません。
Fielding, et. al. Standards Track [Page 8] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[8ページ]RFC2068HTTP/1997年1月1.1日
entity
The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-body, as
described in section 7.
情報が要求か応答のペイロードとして移した実体。 実体は実体本体の形で実体ヘッダーフィールドと内容の形でmetainformationから成ります、セクション7で説明されるように。
representation
An entity included with a response that is subject to content
negotiation, as described in section 12. There may exist multiple
representations associated with a particular response status.
セクション12で説明されるように満足している交渉を受けることがある応答で表現An実体を含んでいます。 特定の応答状態に関連している複数の表現が存在するかもしれません。
content negotiation
The mechanism for selecting the appropriate representation when
servicing a request, as described in section 12. The
representation of entities in any response can be negotiated
(including error responses).
満足している交渉は、要求を修理するときセクション12で説明されるように適切な表現を選択するためのメカニズムです。 どんな応答でも、実体の表現を交渉できます(誤り応答を含んでいて)。
variant
A resource may have one, or more than one, representation(s)
associated with it at any given instant. Each of these
representations is termed a `variant.' Use of the term `variant'
does not necessarily imply that the resource is subject to content
negotiation.
異形Aリソースには、どんな与えられた瞬間にもそれに関連している1、または1以上、表現があるかもしれません。 それぞれのこれらの表現は'異形'と呼ばれます。'異形'という用語のUseは、リソースが満足している交渉を受けることがあるのを必ず含意するというわけではありません。
client
A program that establishes connections for the purpose of sending
requests.
要求を送る目的のために関係を樹立するクライアントAプログラム。
user agent
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user tools.
ユーザエージェント、要求を開始するクライアント。 これらは、しばしばブラウザ、エディタ、クモ(ウェブを横断するロボット)、または他のエンドユーザツールです。
server
An application program that accepts connections in order to
service requests by sending back responses. Any given program may
be capable of being both a client and a server; our use of these
terms refers only to the role being performed by the program for a
particular connection, rather than to the program's capabilities
in general. Likewise, any server may act as an origin server,
proxy, gateway, or tunnel, switching behavior based on the nature
of each request.
応答を返送することによって要求を修理するために接続を受け入れるサーバAnアプリケーション・プログラム。 どんな与えられたプログラムもクライアントとサーバの両方であることができるかもしれません。 私たちのこれらの用語の使用は一般に、プログラムの能力にというよりむしろ特定の接続のためのプログラムで実行される役割だけについて言及します。 同様に、どんなサーバも起源サーバ、プロキシ、ゲートウェイ、またはトンネルとして務めるかもしれません、それぞれの要求の本質に基づく振舞いを切り換えて。
origin server
The server on which a given resource resides or is to be created.
起源サーバ、住んでいるか、または作成される与えられたリソースがことであるサーバ。
Fielding, et. al. Standards Track [Page 9] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[9ページ]RFC2068HTTP/1997年1月1.1日
proxy
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them on, with
possible translation, to other servers. A proxy must implement
both the client and server requirements of this specification.
他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として作動するプロキシAn仲介者プログラム。 要求は、内部的か可能な翻訳で他のサーバにそれらを伝えることによって、修理されます。 プロキシは、両方がこの仕様のクライアントとサーバ要件であると実装しなければなりません。
gateway
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
どれがある他のサーバのための仲介者として機能しますか?ゲートウェイAサーバ、aプロキシと異なって、ゲートウェイはまるでそれが要求されたリソースのための発生源サーバであるかのように要求を受け取ります。 要求しているクライアントはそれがゲートウェイで交信する予定であるのを意識していないかもしれません。
tunnel
An intermediary program which is acting as a blind relay between
two connections. Once active, a tunnel is not considered a party
to the HTTP communication, though the tunnel may have been
initiated by an HTTP request. The tunnel ceases to exist when both
ends of the relayed connections are closed.
ブラインドが2の間で接続をリレーするとき作動しているAn仲介者プログラムにトンネルを堀ってください。 一度アクティブです、トンネルはHTTPコミュニケーションへのパーティーであると考えられません、トンネルはHTTP要求で開始されたかもしれませんが。 トンネルは、リレーされた接続の両端が閉じられるとき、存在するのをやめます。
cache
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cachable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a cache
cannot be used by a server that is acting as a tunnel.
メッセージストレージ、検索、および削除を制御するAプログラムの応答メッセージとサブシステムの地元の小売店をキャッシュしてください。 キャッシュは、将来的で、同等な要求における応答時間とネットワーク回線容量消費を短縮するためにキャッシュ可能応答を保存します。 どんなクライアントやサーバもキャッシュを入れるかもしれません、トンネルとして機能しているサーバでキャッシュを使用できませんが。
cachable
A response is cachable if a cache is allowed to store a copy of
the response message for use in answering subsequent requests. The
rules for determining the cachability of HTTP responses are
defined in section 13. Even if a resource is cachable, there may
be additional constraints on whether a cache can use the cached
copy for a particular request.
キャッシュがその後の要求に答えることにおける使用のための応答メッセージのコピーを保存できるなら、キャッシュ可能A応答はキャッシュ可能です。 HTTP応答のcachabilityを決定するための規則はセクション13で定義されます。 リソースがキャッシュ可能であっても、キャッシュが特定の要求にキャッシュされたコピーを使用できるかどうかに関して追加規制があるかもしれません。
first-hand
A response is first-hand if it comes directly and without
unnecessary delay from the origin server, perhaps via one or more
proxies. A response is also first-hand if its validity has just
been checked directly with the origin server.
発生源サーバから直接と不要な遅れなしで来るなら、直のA応答は直です、恐らく1つ以上のプロキシを通して。 また、正当性がちょうど直接発生源サーバに問い合わせられたところであるなら、応答も直です。
explicit expiration time
The time at which the origin server intends that an entity should
no longer be returned by a cache without further validation.
明白な満了は発生源サーバが、実体がもうキャッシュによってさらなる合法化なしで返されるべきでないことを意図する時を調節します。
Fielding, et. al. Standards Track [Page 10] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[10ページ]RFC2068HTTP/1997年1月1.1日
heuristic expiration time
An expiration time assigned by a cache when no explicit expiration
time is available.
どんな明白な満了時間も有効でないときにキャッシュによって割り当てられた発見的な満了時間An満了時間。
age
The age of a response is the time since it was sent by, or
successfully validated with, the origin server.
応答がそれを送って以来の時間、または首尾よく有効にされるaの時代の年をとってください、発生源サーバ。
freshness lifetime
The length of time between the generation of a response and its
expiration time.
応答の世代とその満了の間の時間の長さが調節する新しさ生涯。
fresh
A response is fresh if its age has not yet exceeded its freshness
lifetime.
時代がまだ新しさ生涯を超えていないなら、新鮮なA応答は新鮮です。
stale
A response is stale if its age has passed its freshness lifetime.
時代が新しさ生涯を通過したなら、聞き古したA応答は聞き古したです。
semantically transparent
A cache behaves in a "semantically transparent" manner, with
respect to a particular response, when its use affects neither the
requesting client nor the origin server, except to improve
performance. When a cache is semantically transparent, the client
receives exactly the same response (except for hop-by-hop headers)
that it would have received had its request been handled directly
by the origin server.
意味的に透明なAキャッシュは「意味的に透明な」態度で振る舞います、特定の応答に関して、使用が要求しているクライアントも発生源サーバも影響しないと、性能を向上させるのを除いて。 キャッシュが意味的に透明であるときに、クライアントはまさに要求が直接発生源サーバによって扱われたならそれが受けたのと同じ応答(ホップごとのヘッダーを除いた)を受けます。
validator
A protocol element (e.g., an entity tag or a Last-Modified time)
that is used to find out whether a cache entry is an equivalent
copy of an entity.
キャッシュエントリーが実体の同等なコピーであるかどうか見つけるのに使用されるvalidator Aプロトコル要素(例えば、実体タグか最終更新日時間)。
1.4 Overall Operation
1.4 総合的な操作
The HTTP protocol is a request/response protocol. A client 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プロトコルは要求/応答プロトコルです。 クライアントはサーバとの関係の上に要求修飾語、クライアント情報、および可能なボディー内容を含むMIMEのようなメッセージがあとに続いた要求メソッド、URI、およびプロトコルバージョンの形で要求をサーバに送ります。サーバは状況表示行で反応します、サーバ情報、実体metainformation、および可能な実体本体内容を含むMIMEのようなメッセージがあとに続いたメッセージのプロトコルバージョンと成功かエラーコードを含んでいて。 HTTPとMIMEとの関係は付録19.4で説明されます。
Fielding, et. al. Standards Track [Page 11] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[11ページ]RFC2068HTTP/1997年1月1.1日
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
チェーンを要求してください。------------------------>Ua-------------------v------------------- ○ <。----------------------- 応答チェーン
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 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.
1人以上の仲介者が要求/応答チェーンで出席しているとき、より複雑な状況は起こります。 仲介者の3つの一般的なフォームがあります: プロキシ、ゲートウェイ、およびトンネル。 プロキシは小口運送業者です、絶対フォームにURIを求める要求を受け取って、メッセージのすべてか一部を書き直して、URIによって特定されたサーバに向かって再フォーマットされた要求を転送して。 ゲートウェイは受信エージェントです、層としてある他のサーバを超えて機能して、必要なら、基本的なサーバのプロトコルに要求を翻訳して。 メッセージを変えないで、トンネルは2つの接続の間のリレーポイントとして作動します。 仲介者がメッセージのコンテンツを理解できないならコミュニケーションが、仲介者(ファイアウォールなどの)を通り抜ける必要があるとき、トンネルは使用されています。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
チェーンを要求してください。-------------------------------------->Ua-----v----- A-----v----- B-----v----- C-----v----- ○ <。------------------------------------- 応答チェーン
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 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.
上の図形はユーザエージェントと発生源サーバの間に(A、B、およびC)を3人の仲介者に示しています。全体のチェーンを旅行する要求か応答メッセージが4つの別々の接続を通り抜けるでしょう。 いくつかのHTTPコミュニケーションオプションが最も近くて、非トンネルの隣人との接続だけ、または、チェーンのエンドポイント、または、チェーンに沿ったすべての接続だけに適用されるかもしれないので、この区別は重要です。 ダイヤグラムは直線的ですが、各関係者は複数の、そして、同時のコミュニケーションに従事するかもしれません。 例えば、BはA以外の多くのクライアント、そして/または、推進要求からCを除いたサーバまでの要求を受け取っているかもしれません、それが取り扱いのA要求であるのと同時に。
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.
トンネルとして機能していないコミュニケーションへのどんなパーティーも取り扱い要求のための内部キャッシュを使うかもしれません。 キャッシュの効果はキャッシュされた応答がチェーンに沿った関係者のひとりでその要求に適切になるなら要求/応答チェーンが短くされるということです。 BにUAかAによってキャッシュされていない要求のためのO(Cを通した)からの以前の応答のキャッシュされたコピーがあるなら、以下は結果として起こるチェーンを例証します。
Fielding, et. al. Standards Track [Page 12] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[12ページ]RFC2068HTTP/1997年1月1.1日
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
チェーンを要求してください。---------->Ua-----v----- A-----v----- B--、--、--、--、--、--C----、--、--、--、--、○ <。--------- 応答チェーン
Not all responses are usefully cachable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cachable responses are defined in section 13.
すべての応答がどんな有効にキャッシュ可能であるというわけではありません、そして、いくつかの要求がキャッシュの振舞いに特別な要件を置く修飾語を含むかもしれません。 キャッシュの振舞いとキャッシュ可能応答のための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 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.
事実上、現在実験されるか、またはWWWの向こう側に配布されるキャッシュとプロキシのさまざまなアーキテクチャと構成は、あります。 これらのシステムは、大洋横断の帯域幅か放送されるシステムかマルチキャストキャッシュエントリー、CD-ROMを通してキャッシュされたデータの部分集合を分配する組織などを節約するためにプロキシキャッシュの国家の階層構造を含んでいます。 HTTPシステムは高帯域リンクの上と、そして、低出力ラジオリンクと間欠接続性があるPDAを通したアクセスに企業イントラネットに使用されます。 HTTP/1.1の目標は高信頼性を必要とするウェブアプリケーションを組立てる人の需要と少なくともそれに失敗することでの失敗の信頼できるしるしを満たすプロトコル構造物を導入している間に既に配布された構成の広い多様性をサポートすることです。
HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80, 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; the mapping of the 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接続の上で行われます。 デフォルトポートはTCP80ですが、他のポートを使用できます。 これは、インターネットの上、または、他のネットワークの上のいかなる他のプロトコルの上でも実装されるので、HTTPを排除しません。 HTTPは信頼できる輸送を推定するだけです。 そのような保証を提供するどんなプロトコルも使用できます。 この仕様の範囲の外に問題のプロトコルの輸送データ単位へのHTTP/1.1要求と応答構造に関するマッピングがあります。
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では、接続は1回以上の要求/応答交換に使用されるかもしれません、接続がさまざまな理由に閉店するかもしれませんが(セクション8.1を見てください)。
2 Notational Conventions and Generic Grammar
2 記号法のコンベンションとジェネリック文法
2.1 Augmented BNF
2.1 増大しているBNF
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [9]. Implementers will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
本書では指定されたメカニズムのすべてが散文とRFC822[9]によって使用されるそれと同様の増大しているバッカス記法(BNF)の両方で説明されます。 Implementersは、この仕様を理解するために記法によく知られる必要があるでしょう。 増大しているBNFは以下の構造物を含んでいます:
Fielding, et. al. Standards Track [Page 13] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[13ページ]RFC2068HTTP/1997年1月1.1日
name = definition
The name of a rule is simply the name itself (without any enclosing
"<" and ">") and is separated from its definition by the equal "="
character. Whitespace is only significant in that indentation of
continuation lines is used to indicate a rule definition that spans
more than one line. Certain basic rules are in uppercase, such as
SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle brackets are used
within definitions whenever their presence will facilitate
discerning the use of rule names.
aの名前が統治する名前=定義は、単に名前(いずれも"<"と">"を同封することのない)自体であり、等しい「=」キャラクタによって定義と切り離されます。 継続行の刻み目が1つ以上の系列にかかる規則定義を示すのに使用されるので、空白は重要であるだけです。 SPなどの大文字、LWS、HT、CRLF、DIGIT、アルファーなどには、ある基本的なルールがあります。 それらの存在が、規則名の使用について明察するのを容易にするときはいつも、角ブラケットは定義の中で使用されます。
"literal"
Quotation marks surround literal text. Unless stated otherwise, the
text is case-insensitive.
「文字通り」のQuotationマークは文字通りのテキストを囲んでいます。 別の方法で述べられない場合、テキストは大文字と小文字を区別しないです。
rule1 | rule2
Elements separated by a bar ("|") are alternatives, e.g., "yes |
no" will accept yes or no.
rule1| rule2Elementsがバーのそばで分離した、(「|」、)、代替手段、例えば、「はい」です。| 「いいえ」は諾否を受け入れるでしょう。
(rule1 rule2)
Elements enclosed in parentheses are treated as a single element.
Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
foo elem" and "elem bar elem".
(rule1 rule2) 括弧に同封された要素はただ一つの要素として扱われます。 したがって、「(elem(foo| バー)elem)」はトークン系列"elem foo elem"と「elemバーelem」を許容します。
*rule
The character "*" preceding an element indicates repetition. The
full form is "<n>*<m>element" indicating at least <n> and at most
<m> occurrences of element. Default values are 0 and infinity so
that "*(element)" allows any number, including zero; "1*element"
requires at least one; and "1*2element" allows one or two.
*要素に先行するキャラクタ「*」が反復を示すと裁決してください。 完全形は要素の少なくとも<n>と高々<m>を示す「<n>*<m>要素」発生です。 「デフォルト値が0であり、無限がそう、それ、」 *、(要素) 」 ゼロを含むどんな数も許容します。 「1*要素」は少なくとも1を必要とします。 そして、「1*2element」は1か2を許容します。
[rule]
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
[統治します] 角括弧は随意的な要素を同封します。 「「[fooバー]」は」 *1(fooバー)に同等です。」
N rule
Specific repetition: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
alphabetic characters.
NはSpecific反復を統治します: 「<n>(要素)」は「<n>*<n>(要素)」に同等です。 すなわち、まさに(要素)の<n>発生。 したがって、2DIGITは2桁数です、そして、3ALPHAは一連の3つの英字です。
#rule
A construct "#" is defined, similar to "*", for defining lists of
elements. The full form is "<n>#<m>element " indicating at least
<n> and at most <m> elements, each separated by one or more commas
(",") and optional linear whitespace (LWS). This makes the usual
form of lists very easy; a rule such as "( *LWS element *( *LWS ","
*LWS element )) " can be shown as "1#element". Wherever this
construct is used, null elements are allowed, but do not contribute
#規則A構造物「#」は、要素のリストを定義するための「*」と定義されていて、同様です。 完全形は少なくとも<n>と高々<m>を示す「<n>#<m>要素」要素です、1つ以上のコンマによって切り離されたそれぞれ、(「」、)、そして、任意の直線的な空白(LWS)。 これで、普通の形式のリストは非常に簡単になります。 「aが統治する、「(*LWS要素*、(*LWS、」、」、*LWS要素) 「「1#要素」として、示すことができます」。 この構造物が使用されている、ヌル要素が許容されていますが、貢献しないどこ
Fielding, et. al. Standards Track [Page 14] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[14ページ]RFC2068HTTP/1997年1月1.1日
to the count of elements present. That is, "(element), , (element)
" is permitted, but counts as only two elements. Therefore, where
at least one element is required, at least one non-null element
must be present. Default values are 0 and infinity so that
"#element" allows any number, including zero; "1#element" requires
at least one; and "1#2element" allows one or two.
要素の現在のカウントに。 すなわち、「(要素)、(要素) 」 受入れられますが、2つの要素だけにみなします。 したがって、少なくとも1つの要素が必要であるところでは、少なくとも1つの非ヌル要素が存在していなければなりません。 「デフォルト値が0であり、無限がそう、それ、」 #要素、」 ゼロを含むどんな数も許容します。 「1#要素」は少なくとも1を必要とします。 そして、「1#2element」は1か2を許容します。
; comment
A semi-colon, set off some distance to the right of rule text,
starts a comment that continues to the end of line. This is a
simple way of including useful notes in parallel with the
specifications.
; 規則テキストの右への何らかの距離に引きたったコメントAセミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。
implied *LWS
The grammar described by this specification is word-based. Except
where noted otherwise, linear whitespace (LWS) can be included
between any two adjacent words (token or quoted-string), and
between adjacent tokens and delimiters (tspecials), without
changing the interpretation of a field. At least one delimiter
(tspecials) must exist between any two tokens, since they would
otherwise be interpreted as a single token.
文法がこの仕様で説明した暗示している*LWSは単語ベースです。 別の方法で注意されるのを除いて、どんな2つの続いている語(トークンか引用文字列)の間とも、そして、隣接しているトークンとデリミタ(tspecials)の間に直線的な空白(LWS)を含むことができます、分野の解釈を変えないで。 少なくとも1つのデリミタ(tspecials)がどんな2つのトークンの間にも存在しなければなりません、そうでなければ、それらはただ一つのトークンとして解釈されるでしょう、したがって。
2.2 Basic Rules
2.2 基本的な規則
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986 [21].
以下の規則は、基本的な構文解析構造物について説明するのにこの仕様中で使用されます。 米国-ASCIIコード化文字集合はANSI X3.4-1986[21]によって定義されます。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
データ>CHAR=<において、どんな米国-ASCII文字(八重奏0--127)>UPALPHAも<と等しいです。「OCTETがどんな8ビットも配列する<と等しい、どんな米国-ASCII大文字「A」。」Z、「>LOALPHAがどんな米国-ASCIIも小文字で印刷する<と等しい、手紙“a"、」z「>アルファー=UPALPHA」| LOALPHA DIGITは<とどんな米国-ASCIIケタ「0インチ」等しいです。9インチの>CTLが<と等しい、どんな米国-ASCII制御文字(八重奏0--31)とデル(127)>CR=<米国-ASCII CR、復帰(13)>LF=<米国-ASCII LF、ラインフィード(10)>SP=<米国-ASCII SP、<米国-ASCII HT、水平タブ(9)><「>の=<米国-ASCIIの二重引用符」とスペース(32)>HTは等しいです。(34)>。
Fielding, et. al. Standards Track [Page 15] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[15ページ]RFC2068HTTP/1997年1月1.1日
HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see appendix 19.3 for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described in section 3.7.
HTTP/1.1は実体本体以外のすべてのプロトコル要素のための行末マーカーと系列CR LFを定義します(許容性があるアプリケーションに関して付録19.3を見てください)。 実体本体の中の行末マーカーはセクション3.7で説明されるように関連メディアタイプによって定義されます。
CRLF = CR LF
CRLFはCR LFと等しいです。
HTTP/1.1 headers can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP.
継続行がスペースか水平タブで始まるなら、HTTP/1.1個のヘッダーを複数の系列に折り重ねることができます。 折り重なるのを含むすべての直線的な余白がSPと同じ意味論を持っています。
LWS = [CRLF] 1*( SP | HT )
LWSは[CRLF]1*と等しいです。(SP| HT)
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT may contain characters from character sets other than ISO 8859-1 [22] only when encoded according to the rules of RFC 1522 [14].
TEXT規則は描写的である分野コンテンツとメッセージパーサによって解釈されることを意図しない値に使用されるだけです。 [22] RFC1522[14]の規則に従ってコード化される場合にだけ、*TEXTのワーズはISO8859-1以外の文字集合からのキャラクタを含むかもしれません。
TEXT = <any OCTET except CTLs,
but including LWS>
TEXT=<はCTLsの、しかし、含んでいるLWS>以外のあらゆるOCTETです。
Hexadecimal numeric characters are used in several protocol elements.
16進数字は数個のプロトコル要素で使用されます。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
十六進法=「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| 「f」| ケタ
Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters MUST be in a quoted string to be used within a parameter value.
多くのHTTP/1.1のヘッダーフィールド値がLWSか特殊文字によって切り離された単語から成ります。 パラメタ値の中で使用されるために、これらの特殊文字が引用文字列にあるに違いありません。
token = 1*<any CHAR except CTLs or tspecials>
トークン=1*<はCTLsかtspecials>以外のあらゆるCHARです。
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
tspecialsが等しい、「(「|」、)、」| "<"| ">"| "@" | "," | ";" | ":" | "\" | <">"| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP| HT
Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
いくつかのHTTPヘッダ分野にコメントテキストを括弧に取り巻くことによって、コメントを含むことができます。 コメントは彼らの分野値の定義の一部として「コメント」を含む分野に許容されているだけです。 他のすべての分野では、括弧が分野価値の一部であると考えられます。
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
そして、「(「*(ctext| コメント)」)」というコメント=ctextが<と等しい、どんなテキスト除外、も「(「」、)、">"
Fielding, et. al. Standards Track [Page 16] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[16ページ]RFC2068HTTP/1997年1月1.1日
A string of text is parsed as a single word if it is quoted using double-quote marks.
それが二重引用符を使用することで引用されるなら、テキストの五弦は一語として分析されます。
quoted-string = ( <"> *(qdtext) <"> )
引用文字列=(<、「>*(qdtext)<、「>)」
qdtext = <any TEXT except <">>
<「>>」を除いて、qdtext=<はあらゆるTEXTです。
The backslash character ("\") may be used as a single-character quoting
mechanism only within quoted-string and comment constructs.
バックスラッシュキャラクタ(「\」)は、引用文字列とコメント構造物だけの中にメカニズムを引用しながら、単独のキャラクタとして使用されるかもしれません。
quoted-pair = "\" CHAR
引用された組=「\」炭
3 Protocol Parameters
3 プロトコルパラメタ
3.1 HTTP Version
3.1 HTTPバージョン
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed.
HTTPは、プロトコルのバージョンを示すのに「<の主要な><の小さい方の>」ナンバリングスキームを使用します。 プロトコルversioning方針が、送付者がそのコミュニケーションで得られた特徴よりむしろさらなるHTTPコミュニケーションを理解するためにメッセージとその容量の書式を示すのを許容することを意図します。 変更を全くコミュニケーション行動に影響しないか、または広げることができる分野値に加えるだけであるメッセージコンポーネントの追加のバージョン番号にしません。 プロトコルにされた変更が一般的なメッセージ構文解析アルゴリズムを変えませんが、メッセージ意味論に加えて、送付者の追加能力を含意するかもしれない特徴を加えると、<の小さい方の>番号は増加されています。 プロトコルの中のメッセージの形式を変えるとき、<の主要な>番号は増加しています。
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message.
HTTPメッセージのバージョンはメッセージの最初の系列におけるHTTPバージョン分野によって示されます。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
「HTTPバージョン=「HTTP」」/、」 1*ケタ、」、」 1*ケタ
Note that the major and minor numbers MUST be treated as separate integers and that each may be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and MUST NOT be sent.
主要で小さい方の数を別々の整数として扱わなければならなくて、それぞれが一桁より高く増加されるかもしれないことに注意してください。 したがって、HTTP/2.4は順番に低いHTTP/2.13より低いHTTP/12.3よりバージョンです。 先行ゼロを受取人が無視しなければならなくて、送ってはいけません。
Applications sending Request or Response messages, as defined by this specification, MUST include an HTTP-Version of "HTTP/1.1". Use of this version number indicates that the sending application is at least conditionally compliant with this specification.
この仕様で定義されるようにRequestかResponseにメッセージを送るアプリケーションは「HTTP/1.1インチ」のHTTPバージョンを含まなければなりません。 このバージョン番号の使用は、送付アプリケーションがこの仕様で少なくとも条件付きに対応であることを示します。
The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.
アプリケーションのHTTPバージョンはアプリケーションが少なくとも条件付きに対応である最も高いHTTPバージョンです。
Fielding, et. al. Standards Track [Page 17] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[17ページ]RFC2068HTTP/1997年1月1.1日
Proxy and gateway applications must be careful when forwarding messages in protocol versions different from that of the application. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway MUST never send a message with a version indicator which is greater than its actual version; if a higher version request is received, the proxy/gateway MUST either downgrade the request version, respond with an error, or switch to tunnel behavior. Requests with a version lower than that of the proxy/gateway's version MAY be upgraded before being forwarded; the proxy/gateway's response to that request MUST be in the same major version as the request.
アプリケーションのものと異なったプロトコルバージョンのメッセージを転送するとき、プロキシとゲートウェイアプリケーションは慎重であるに違いありません。 プロトコルバージョンが送付者のプロトコル能力を示すので、プロキシ/ゲートウェイは実際のバージョンよりすばらしいバージョンインディケータでメッセージを決して送ってはいけません。 より高いバージョン要求が受信されているなら、プロキシ/ゲートウェイは、要求バージョンを格下げしなければならないか、誤りで応じなければならないか、またはトンネルの振舞いに切り替わらなければなりません。 バージョンが進める前にプロキシ/ゲートウェイのバージョンのものをアップグレードさせるかもしれないより低い要求。 その要求へのプロキシ/ゲートウェイの応答が要求と同じ主要なバージョンにあるに違いありません。
Note: Converting between versions of HTTP may involve modification
of header fields required or forbidden by the versions involved.
以下に注意してください。 HTTPのバージョンの間で変換するのはかかわったバージョンによって必要であった、または禁じられたヘッダーフィールドの変更にかかわるかもしれません。
3.2 Uniform Resource Identifiers
3.2 Uniform Resource Identifier
URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers , and finally the combination of Uniform Resource Locators (URL) and Names (URN). As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a resource.
URIは多くの名前によって知られています: Uniform Resource Locator(URL)とNames(URN)のWWWアドレス、Universal Document Identifiers、Universal Resource Identifiers、および最終的に組み合わせ。 HTTPに関する限り、Uniform Resource Identifierは名前、位置、またはいかなる他の特性でもリソースを特定する単にフォーマットされたストリングです。
3.2.1 General Syntax
3.2.1 一般構文
URIs in HTTP can be represented in absolute form or relative to some known base URI, depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon.
絶対フォームか何らかの知られているベースURIに比例してHTTPにおけるURIを表すことができます、彼らの使用の文脈によって。 2つのフォームがコロンが体系名のあとに続いていて絶対URIがいつも始まるという事実によって差別化されます。
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
URI=(absoluteURI| relativeURI)[「#」断片]
absoluteURI = scheme ":" *( uchar | reserved )
「absoluteURI=は計画する」:、」 *(予約されていた状態で|ucharします)
relativeURI = net_path | abs_path | rel_path
relativeURIはネットの_経路と等しいです。| 腹筋_経路| rel_経路
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
「ネットの_経路=」//」 ネットの_loc[腹筋_経路]腹筋_経路=」 /」 rel_経路rel_経路=[経路][「;」params][“?"質問]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
経路=fsegment*(「/」セグメント)fsegmentは1*pcharセグメント=*pcharと等しいです。
params = param *( ";" param )
param = *( pchar | "/" )
paramsがparam*と等しい、(「」、;param) paramが*と等しい 「(pchar| 」 /、」、)
Fielding, et. al. Standards Track [Page 18] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[18ページ]RFC2068HTTP/1997年1月1.1日
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
「=1*を計画してください、(アルファー| DIGIT|「+」|「-」|、」、」、)、ネット_locは*と等しいです。「(pchar|、」、;、」 | “?"、)
query = *( uchar | reserved )
fragment = *( uchar | reserved )
質問=*(予約されていた状態で|ucharします)断片=*(予約されていた状態で|ucharします)
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
pcharはucharと等しいです。| ":" | "@" | "&" | "=" | 「+」uchar=無遠慮です。| 無遠慮な=アルファーから逃げてください。| ケタ| 金庫| エキストラ| 国家
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
reserved, extra, safe, and unsafe>
「エスケープは「」 十六進法が魔法をかける%は=を予約したこと」と等しいです」 | "/" | "?" | ":" | "@" | "&" | "=" | 「+」 付加的な=“!" | "*" | "'" | "(" | ")" | 「」、安全な=「$」| "-" | "_" | 「. 」 危険な=CTL| SP| <">"| "#" | "%" | "<"| アルファーを除いたどんなOCTET(DIGIT)も予約した付加的で、安全な">"国家の=<と危険な>。
For definitive information on URL syntax and semantics, see RFC 1738 [4] and RFC 1808 [11]. The BNF above includes national characters not allowed in valid URLs as specified by RFC 1738, since HTTP servers are not restricted in the set of unreserved characters allowed to represent the rel_path part of addresses, and HTTP proxies may receive requests for URIs not defined by RFC 1738.
URL構文と意味論の決定的な情報に関しては、RFC1738[4]とRFC1808[11]を見てください。 上のBNFはRFC1738年までに指定されるとしての有効なURLに許容されなかった国民性を含んでいます、HTTPサーバがアドレスのrel_経路部分を表すことができた無遠慮な性格のセットで制限されないで、HTTPプロキシがRFC1738によって定義されなかったURIを求める要求を受け取るかもしれないので。
The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).
HTTPプロトコルはどんな先験的な限界もURIの長さに置きません。 サーバはそれらが役立つどんなリソース、およびSHOULDのURIも扱うことができなければなりません。そのようなURIを生成することができたGETベースのフォームを提供するなら、限りない長さのURIを扱うことができてください。 サーバSHOULDリターン414(要求URI Too Long)状態はURIであるならサーバが扱うことができるより長いです(セクション10.4.15を見てください)。
Note: Servers should be cautious about depending on URI lengths
above 255 bytes, because some older client or proxy implementations
may not properly support these lengths.
以下に注意してください。 サーバは255バイトより高いURIの長さに依存することに関して用心深いはずです、いくつかのさらに年取ったクライアントかプロキシ実装が適切にこれらの長さをサポートしないかもしれないので。
3.2.2 http URL
3.2.2 http URL
The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.
"http"体系は、HTTPプロトコルでネットワーク資源の場所を見つけるのに使用されます。 このセクションはhttp URLのために体系特有の構文と意味論を定義します。
Fielding, et. al. Standards Track [Page 19] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[19ページ]RFC2068HTTP/1997年1月1.1日
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
http_URL=は「以下をhttpします」。 「//」ホスト[「:」 ポート][腹筋_経路]
host = <A legal Internet host domain name
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
ホストは<のA法的なインターネット・ホストのドメイン名かIPアドレスと等しいです(ドット付き10進法フォームで)、RFC1123>のセクション2.1によって定義されるように
port = *DIGIT
ポートは*DIGITと等しいです。
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path. The use of IP addresses in URL's SHOULD be avoided whenever possible (see RFC 1900 [24]). If the abs_path is not present in the URL, it MUST be given as "/" when used as a Request-URI for a resource (section 5.1.2).
ポートが人影がないか考えないで、ポート80は想定されます。 意味論は特定されたリソースがそのホストのそのポートの上でTCP接続の聞こうとするサーバで位置しているということです、そして、リソースのためのRequest-URIは腹筋_経路です。 可能であるときはいつも、IPアドレスでは、URL SHOULDで避けられてください。使用、(RFC1900[24])を見てください。 いつがリソースに要求URIとして(セクション5.1.2)を使用したかという「腹筋_経路がURLに存在していないなら、それは」 /として当然のことであるに違いありません」。
3.2.3 URI Comparison
3.2.3 URI比較
When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions:
比較するとき、決める2つのURIがそれらであるなら合って、クライアントSHOULD使用は全体のURIの大文字と小文字を区別する八重奏による八重奏比較です、これらの例外で:
o A port that is empty or not given is equivalent to the default
port for that URI;
o そのURIに、人影がないか与えられなかったポートはデフォルトポートに同等です。
o Comparisons of host names MUST be case-insensitive;
o ホスト名の比較は大文字と小文字を区別しないに違いありません。
o Comparisons of scheme names MUST be case-insensitive;
o 体系名の比較は大文字と小文字を区別しないに違いありません。
o An empty abs_path is equivalent to an abs_path of "/".
o 「人影のない腹筋_経路は」 /の腹筋_経路に同等です。」
Characters other than those in the "reserved" and "unsafe" sets (see section 3.2) are equivalent to their ""%" HEX HEX" encodings.
「予約され」て「危険な」セット(セクション3.2を見る)におけるそれら以外のキャラクターはそれらの「「%」十六進法十六進法」encodingsに同等です。
For example, the following three URIs are equivalent:
例えば、以下の3つのURIが同等です:
http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html
http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html
Fielding, et. al. Standards Track [Page 20] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[20ページ]RFC2068HTTP/1997年1月1.1日
3.3 Date/Time Formats
3.3 日付/時間形式
3.3.1 Full Date
3.3.1 完全な期日
HTTP applications have historically allowed three different formats for the representation of date/time stamps:
HTTPアプリケーションは日付/タイムスタンプの表現のための3つの異なった形式を歴史的に許容しました:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
グリニッジ標準時1994年11月6日日曜日8時49分37秒。 RFC1123グリニッジ標準時1994年11月6日日曜日8時49分37秒までにアップデートされたRFC822。 RFC1036 1994年11月6日日曜日8時49分37秒までに時代遅れにされたRFC850。 ANSI Cのasctime()形式
The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 (an update to RFC 822). The second format is in common use, but is based on the obsolete RFC 850 [12] date format and lacks a four-digit year. HTTP/1.1 clients and servers that parse the date value MUST accept all three formats (for compatibility with HTTP/1.0), though they MUST only generate the RFC 1123 format for representing HTTP-date values in header fields.
最初の形式は、インターネット標準として好まれて、RFC1123(RFC822へのアップデート)によって定義されたその固定長部分集合を表します。 2番目の形式は、共用ですが、時代遅れのRFC850[12]日付の形式に基づいていて、4ケタの年間欠けています。 日付の値を分析するHTTP/1.1のクライアントとサーバがすべての3つの形式(HTTP/1.0との互換性のための)を受け入れなければなりません、ヘッダーフィールドにおけるHTTP日付の値を表すためにRFC1123が形式であると生成するだけでよいのですが。
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
以下に注意してください。 日付の値の受取人が非HTTPアプリケーションで送られたかもしれない日付の値を受け入れるのにおいて強健であるよう奨励されます、SMTPかNNTPへのプロキシ/ゲートウェイを通してメッセージを検索するか、または掲示するとき、時々そうであるように。
All HTTP date/time stamps MUST be represented in Greenwich Mean Time (GMT), without exception. This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and MUST be assumed when reading the asctime format.
(グリニッジ標準時に)グリニッジ標準時に例外なしですべてのHTTP日付/タイムスタンプを表さなければなりません。 これを時間帯のための3文字の略語として最初の2つの形式で「グリニッジ標準時」の包含で示されて、asctime書式を読むとき、想定しなければなりません。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
HTTP日付=rfc1123-日付| rfc850-日付| asctime-日付
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
「rfc1123-日付はwkdayと等しいです」、wkday SP date3 SP」SPが「」 グリニッジ標準時のrfc850-日付=平日」、「グリニッジ標準時」の」SP date2 SP時間SPのときにasctime日付を入れるSP date1 SP時間=時間SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
2DIGIT SP date1=月のSP 4DIGIT。 日月の2DIGIT「-」date2=月の年(例えば、1982年6月2日)の「-」2DIGIT。 日の月のdate3=月の年(例えば、1982年6月2日)のSP(2DIGIT| (SP 1DIGIT))。 月の日(例えば、6月2日)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
「時間は2DIGITと等しい」:、」 "2DIGIT":、」 2DIGIT。 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
wkday=「月曜日」| 「火曜日」| 「水曜日」| 「木曜日」| 「金曜日」| 「座っています」| 「Sun」
Fielding, et. al. Standards Track [Page 21] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[21ページ]RFC2068HTTP/1997年1月1.1日
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
「月曜日」平日=| 「火曜日」| 「水曜日」| 「木曜日」| 「金曜日」| 「土曜日」| 「日曜日」
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
月=「1月」| 「2月」| 「3月」| 「4月」| 「5月」| 「6月」| 「7月」| 「8月」| 「9月」| 「10月」| 「11月」| 「12月」
Note: HTTP requirements for the date/time stamp format apply only
to their usage within the protocol stream. Clients and servers are
not required to use these formats for user presentation, request
logging, etc.
以下に注意してください。 日付/タイムスタンプ形式のためのHTTP要件はプロトコルストリームの中でそれらの用法だけに適用されます。 クライアントとサーバは、ユーザプレゼンテーション、要求伐採などにこれらの形式を使用するのに必要ではありません。
3.3.2 Delta Seconds
3.3.2デルタ秒
Some HTTP header fields allow a time value to be specified as an integer number of seconds, represented in decimal, after the time that the message was received.
いくつかのHTTPヘッダ分野が、時間的価値がメッセージを受け取った時の後に小数で表された整数秒数として指定されるのを許容します。
delta-seconds = 1*DIGIT
デルタ秒は1*DIGITと等しいです。
3.4 Character Sets
3.4 文字コード
HTTP uses the same definition of the term "character set" as that described for MIME:
それがMIMEのために説明したようにHTTPは「文字集合」という用語の同じ定義を使用します:
The term "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of octets
into a sequence of characters. Note that unconditional conversion
in the other direction is not required, in that not all characters
may be available in a given character set and a character set may
provide more than one sequence of octets to represent a particular
character. This definition is intended to allow various kinds of
character encodings, from simple single-table mappings such as US-
ASCII to complex table switching methods such as those that use ISO
2022's techniques. However, the definition associated with a MIME
character set name MUST fully specify the mapping to be performed
from octets to characters. In particular, use of external profiling
information to determine the exact mapping is not permitted.
「文字集合」という用語は、八重奏の系列をキャラクタの系列に変換するのに1個以上のテーブルと共に使用されるメソッドを示すのに本書では使用されます。 もう片方の方向への無条件の変換は必要でないことに注意してください、すべてのキャラクタがどんな与えられた文字集合で手があくかもしれないというわけではなくて、文字集合が特定のキャラクタの代理をするために八重奏の1つ以上の系列を提供するかもしれないので。 この定義が様々な種類の文字符号化を許容することを意図します、米国ASCIIなどの簡単な単一のテーブルマッピングから複雑なISO2022のテクニックを使用するものなどのテーブル切り換えメソッドまで。 しかしながら、MIME文字集合名に関連している定義は、八重奏からキャラクタまで実行されるためにマッピングを完全に指定しなければなりません。 特に、正確なマッピングを決定する外部のプロフィール情報の使用は受入れられません。
Note: This use of the term "character set" is more commonly
referred to as a "character encoding." However, since HTTP and MIME
share the same registry, it is important that the terminology also
be shared.
以下に注意してください。 「文字集合」という用語のこの使用は、より一般的に「文字符号化」と呼ばれます。 しかしながら、HTTPとMIMEが同じ登録を共有するので、また、用語が共有されるのは、重要です。
Fielding, et. al. Standards Track [Page 22] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[22ページ]RFC2068HTTP/1997年1月1.1日
HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character Set registry [19].
HTTP文字集合は大文字と小文字を区別しないトークンによって特定されます。 完全なセットのトークンはIANA文字コード登録[19]によって定義されます。
charset = token
charsetはトークンと等しいです。
Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA Character Set registry MUST represent the character set defined by that registry. Applications SHOULD limit their use of character sets to those defined by the IANA registry.
HTTPは、任意のトークンがcharset値として使用されるのを許容しますが、IANA文字コード登録の中に事前に定義された値を持っているどんなトークンもその登録によって定義された文字集合を表さなければなりません。 アプリケーションSHOULDは彼らの文字集合の使用をIANA登録によって定義されたものに制限します。
3.5 Content Codings
3.5 満足しているコーディング
Content coding values indicate an encoding transformation that has been or can be applied to an entity. Content codings are primarily used to allow a document to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the entity is stored in coded form, transmitted directly, and only decoded by the recipient.
満足しているコード化値は、それがコード化変換であったのを示すか、または実体に適用できます。 満足しているコーディングは、ドキュメントが圧縮されるのを許容するのに主として使用されるか、または別の方法で基本的なメディアタイプのアイデンティティを失うことなしで情報の損失なしで有効に変えられます。 実体は、頻繁に、コード化形式で保存されて、直接伝えられて、受取人によって解読されるだけです。
content-coding = token
内容をコード化する=トークン
All content-coding values are case-insensitive. HTTP/1.1 uses content-coding values in the Accept-Encoding (section 14.3) and Content-Encoding (section 14.12) header fields. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding.
すべての内容をコード化する値が大文字と小文字を区別しないです。 HTTP/1.1はAcceptをコード化していて(セクション14.3)Contentをコード化している(セクション14.12)ヘッダーフィールドに内容をコード化する値を使用します。 値は内容をコード化しているのと説明しますが、より重要なことはどんな解読メカニズムがコード化を取り除かなければならないかを示すということです。
The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:
インターネットAssigned民数記Authority(IANA)は内容をコード化する値のトークンのための登録として機能します。 初めは、登録は以下のトークンを含みます:
gzip An encoding format produced by the file compression program "gzip"
(GNU zip) as described in RFC 1952 [25]. This format is a Lempel-
Ziv coding (LZ77) with a 32 bit CRC.
gzip Anコード化形式はRFC1952[25]で説明される"gzip"(GNUはすばやく動く)というファイル圧縮プログラムで発生しました。 この形式は32ビットのCRCとのLempel- Zivコード化(LZ77)です。
compress
The encoding format produced by the common UNIX file compression
program "compress". This format is an adaptive Lempel-Ziv-Welch
coding (LZW).
「湿布」という一般的なUNIXファイル圧縮プログラムで発生したコード化形式を圧縮してください。 この形式は適応型のLempel-Ziv-ウェルチコード化(LZW)です。
Fielding, et. al. Standards Track [Page 23] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[23ページ]RFC2068HTTP/1997年1月1.1日
Note: Use of program names for the identification of encoding
formats is not desirable and should be discouraged for future
encodings. Their use here is representative of historical practice,
not good design. For compatibility with previous implementations of
HTTP, applications should consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.
以下に注意してください。 プログラム名のコード化形式の識別の使用は、望ましくなく、将来のencodingsのためにお勧めできなくあるべきです。 ここでの彼らの使用は良いデザインではなく、歴史的な習慣を代表しています。 HTTPの前の実装との互換性のために、アプリケーションは、"x-gzip"と「x-湿布」がそれぞれ"gzip"と「湿布」に相当していると考えるべきです。
deflate The "zlib" format defined in RFC 1950[31] in combination with
the "deflate" compression mechanism described in RFC 1951[29].
圧縮機構がRFC 1951[29]で説明した「空気を抜いてください」と組み合わせてRFC 1950[31]で定義された"zlib"書式に空気を抜かせてください。
New content-coding value tokens should be registered; to allow interoperability between clients and servers, specifications of the content coding algorithms needed to implement a new value should be publicly available and adequate for independent implementation, and conform to the purpose of content coding defined in this section.
内容をコード化する新しい値のトークンは登録されるべきです。 新しい値を実装するのに必要であるアルゴリズムをコード化する内容の仕様は、クライアントとサーバの間の相互運用性を許容するために、独立している実装に公的に利用可能であって、適切であり、このセクションで定義された満足しているコード化の目的に従うべきです。
3.6 Transfer Codings
3.6 転送コーディング
Transfer coding values are used to indicate an encoding transformation that has been, can be, or may need to be applied to an entity-body in order to ensure "safe transport" through the network. This differs from a content coding in that the transfer coding is a property of the message, not of the original entity.
転送コード化値は、それがコード化変換であったのを示すのに使用されるか、あることができるか、またはネットワークを通した「安全輸送」を確実にするために実体本体に当てられる必要があるかもしれません。 これは転送コード化がオリジナルの実体ではなく、メッセージの特性であるという点において満足しているコード化と異なっています。
transfer-coding = "chunked" | transfer-extension
転送をコード化する=は「chunkedされました」。| 転送拡大
transfer-extension = token
転送拡大はトークンと等しいです。
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer coding values in the Transfer-Encoding header field (section 14.40).
すべての転送をコード化する値が大文字と小文字を区別しないです。 HTTP/1.1はTransferをコード化しているヘッダーフィールド(セクション14.40)に転送コード化値を使用します。
Transfer codings are analogous to the Content-Transfer-Encoding values of MIME , which were designed to enable safe transport of binary data over a 7-bit transport service. However, safe transport has a different focus for an 8bit-clean transfer protocol. In HTTP, the only unsafe characteristic of message-bodies is the difficulty in determining the exact body length (section 7.2.2), or the desire to encrypt data over a shared transport.
転送コーディングはMIMEのContent転送コード化値に類似しています。(MIMEは、7ビットの輸送サービスの上でバイナリ・データの安全輸送を可能にするように設計されました)。 しかしながら、安全輸送には、8ビット清潔な転送プロトコルのための異なった焦点があります。 HTTPでは、メッセージ本体の唯一の危険な特性は、正確なボディーの長さ(セクション7.2.2)を測定することにおける苦労、または共有された輸送の上にデータを暗号化する願望です。
The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator, followed by an optional footer containing entity-header fields. This allows dynamically-produced content to be transferred along with the information necessary for the recipient to verify that it has received the full message.
chunkedコード化は、一連の塊(それ自身のサイズインディケータがあるそれぞれ)が実体ヘッダーフィールドを含む任意のフッターで続いたのでそれを移すようにメッセージのボディーを変更します。 これは、受取人が、完全なメッセージを受け取ったことを確かめるようにダイナミックに生産された内容が必要情報と共に移されるのを許容します。
Fielding, et. al. Standards Track [Page 24] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[24ページ]RFC2068HTTP/1997年1月1.1日
Chunked-Body = *chunk
"0" CRLF
footer
CRLF
Chunkedボディー=*塊「0インチのCRLFフッターCRLF」
chunk = chunk-size [ chunk-ext ] CRLF
chunk-data CRLF
塊=塊サイズ[塊-ext]CRLF塊データCRLF
hex-no-zero = <HEX excluding "0">
十六進法ノーゼロ、は「0インチの>」を除いた<HEXと等しいです。
chunk-size = hex-no-zero *HEX
chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-value ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
塊サイズが*HEX塊-ext十六進法ノーゼロ=*と等しい、(「」、;塊ext名[塊ext価値と「等しい」)の塊ext名の=トークン塊-ext-valがトークンと等しい | 引用文字列塊データは塊サイズと等しいです。(八重奏)
footer = *entity-header
フッター=*実体ヘッダー
The chunked encoding is ended by a zero-sized chunk followed by the footer, which is terminated by an empty line. The purpose of the footer is to provide an efficient way to supply information about an entity that is generated dynamically; applications MUST NOT send header fields in the footer which are not explicitly defined as being appropriate for the footer, such as Content-MD5 or future extensions to HTTP for digital signatures or other facilities.
chunkedコード化は空の系列によって終えられるフッターによって後をつけられた無大きさで分けられた塊によって終わらされます。 フッターの目的はダイナミックに生成される実体の情報を提供する効率的な方法を提供することです。 アプリケーションはフッターの明らかにフッターに適切であると定義されないヘッダーフィールドを送ってはいけません、デジタル署名か他の施設へのHTTPへのContent-MD5や今後の拡大のように。
An example process for decoding a Chunked-Body is presented in appendix 19.4.6.
Chunked-ボディーを解読するための例のプロセスは付録19.4.6で提示されます。
All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer coding, and MUST ignore transfer coding extensions they do not understand. A server which receives an entity-body with a transfer-coding it does not understand SHOULD return 501 (Unimplemented), and close the connection. A server MUST NOT send transfer-codings to an HTTP/1.0 client.
すべてのHTTP/1.1のアプリケーションが、"chunkedする"の転送コード化を受けて、解読できなければならなくて、彼らが理解していない転送コード化拡大を無視しなければなりません。 それがする転送コード化で実体本体を受けるサーバは、SHOULDが501(Unimplemented)を返して、接続を終えるのを理解していません。 サーバはHTTP/1.0クライアントに転送コーディングを送ってはいけません。
3.7 Media Types
3.7のメディアタイプ
HTTP uses Internet Media Types in the Content-Type (section 14.18) and Accept (section 14.1) header fields in order to provide open and extensible data typing and type negotiation.
HTTPは、開いていて広げることができるデータ型定義を提供して、交渉をタイプするのにコンテントタイプ(セクション14.18)とAccept(セクション14.1)ヘッダーフィールドにインターネットメディアTypesを使用します。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
」 「メディアタイプはタイプと等しく」/「副-タイプ」*(「;」パラメタ)タイプはトークン「副-タイプ」=トークンと等しいです。
Parameters may follow the type/subtype in the form of attribute/value pairs.
パラメタは属性/値の組の形でタイプ/「副-タイプ」に続くかもしれません。
Fielding, et. al. Standards Track [Page 25] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[25ページ]RFC2068HTTP/1997年1月1.1日
parameter = attribute "=" value
attribute = token
value = token | quoted-string
パラメタ=属性「=」値属性=トークン価値はトークンと等しいです。| 引用文字列
The type, subtype, and parameter attribute names are case- insensitive. Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name. Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value. User agents that recognize the media-type MUST process (or arrange to be processed by any external applications used to process that type/subtype by the user agent) the parameters for that MIME type as described by that type/subtype definition to the and inform the user of any problems discovered.
タイプ、「副-タイプ」、およびパラメタ属性名はケース鈍感です。 パラメタ名の意味論によって、パラメタ値は大文字と小文字を区別しているかもしれません。 タイプと「副-タイプ」の間と、そして、属性とその値の間で直線的な余白(LWS)を使用してはいけません。 そして、メディアタイプを認めるユーザエージェントがタイプ/が定義を副タイプする説明されるそのMIMEの種類のためのパラメタを処理しなければならない、(ユーザエージェントでそのタイプ/「副-タイプ」を処理するのに使用されるどんな外部のアプリケーションでも処理されるように手配してください)発見されたあらゆる問題についてユーザに知らせてください。
Note: some older HTTP applications do not recognize media type
parameters. When sending data to older HTTP applications,
implementations should only use media type parameters when they are
required by that type/subtype definition.
以下に注意してください。 いくつかの、より古いHTTPアプリケーションはメディア型引数を認識しません。 より古いHTTPアプリケーションにデータを送るとき、それらがそのタイプ/「副-タイプ」定義で必要であるときにだけ、実装はメディア型引数を使用するべきです。
Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is outlined in RFC 2048 [17]. Use of non-registered media types is discouraged.
メディアタイプ値はISOCの機関の一つで(IANA)に示されます。 メディアタイプ登録手続はRFC2048[17]に概説されています。 非登録されたメディアタイプの使用はお勧めできないです。
3.7.1 Canonicalization and Text Defaults
3.7.1 Canonicalizationとテキストはデフォルトとします。
Internet media types are registered with a canonical form. In general, an entity-body transferred via HTTP messages MUST be represented in the appropriate canonical form prior to its transmission; the exception is "text" types, as defined in the next paragraph.
インターネットメディアタイプは標準形に示されます。 一般に、トランスミッションの前に適切な標準形にHTTPメッセージで移された実体本体を表さなければなりません。 例外は次のパラグラフで定義されるように「テキスト」タイプです。
When in canonical form, media subtypes of the "text" type use CRLF as the text line break. HTTP relaxes this requirement and allows the transport of text media with plain CR or LF alone representing a line break when it is done consistently for an entire entity-body. HTTP applications MUST accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP. In addition, if the text is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the entity-body; a bare CR or LF MUST NOT be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
標準形にあるとき、テキストラインブレイクとしてのタイプが使用する「テキスト」CRLFのメディア血液型亜型です。 明瞭なCRかLFが単独の状態で、HTTPは、全体の実体本体のために一貫してそれをするとラインブレイクを表しながら、この要件を弛緩して、テキストメディアの輸送を許容します。 HTTPアプリケーションはラインブレイクを代表するとHTTPで受け取られたテキストメディアでCRLF、むき出しのCR、およびむき出しのLFを認めなければなりません。 さらに、テキストがCRとLFにそれぞれ八重奏13と10を使用しない文字集合で表されるなら、いくつかの多バイト文字セットのためのケースのように、その文字集合によって定義されるどんな八重奏系列の使用もラインブレイクのためにHTTPでCRとLFの同等物を表すことができます。 ラインブレイクに関するこの柔軟性は実体本体のテキストメディアだけに適用されます。 aはCRかLF MUST NOTを剥き出します。HTTP制御構造(ヘッダーフィールドや複合境界などの)のどれかの中でCRLFに代入してください。
If an entity-body is encoded with a Content-Encoding, the underlying data MUST be in a form defined above prior to being encoded.
実体本体がContent-コード化でコード化されるなら、基本的なデータがコード化される前に上で定義された書式にあるに違いありません。
Fielding, et. al. Standards Track [Page 26] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[26ページ]RFC2068HTTP/1997年1月1.1日
The "charset" parameter is used with some media types to define the character set (section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets MUST be labeled with an appropriate charset value.
"charset"パラメタは、データの文字集合(セクション3.4)を定義するのに何人かのメディアタイプで使用されます。 「テキスト」タイプのメディア血液型亜型がデフォルトcharset価値を持つためにどんな明白なcharsetパラメタもいつ送付者によって提供されないかが定義される、「ISO、8859、1インチ、いつ、HTTPで受信するか、」 または、データがぴったりしたセットする、「ISO8859、1インチ、適切なcharset値で部分集合をラベルしなければならない、」
Some HTTP/1.0 software has interpreted a Content-Type header without charset parameter incorrectly to mean "recipient should guess." Senders wishing to defeat this behavior MAY include a charset parameter even when the charset is ISO-8859-1 and SHOULD do so when it is known that it will not confuse the recipient.
何らかのHTTP/1.0ソフトウェアが、「受取人は推測するべきです」と意味するためにcharsetパラメタなしでコンテントタイプヘッダーを不当に解釈しました。 charsetがISO-8859-1であり、受取人を混乱させないのが知られているとSHOULDがそうしさえするとき、この振舞いを破りたがっているSendersはcharsetパラメタを入れるかもしれません。
Unfortunately, some older HTTP/1.0 clients did not deal properly with an explicit charset parameter. HTTP/1.1 recipients MUST respect the charset label provided by the sender; and those user agents that have a provision to "guess" a charset MUST use the charset from the content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document.
残念ながら、何人かの、より古いHTTP/1.0人のクライアントは適切に明白なcharsetパラメタに対処しませんでした。 HTTP/1.1人の受取人が送付者によって提供されたcharsetラベルを尊敬しなければなりません。 そして、初めはドキュメントを表示するとき、彼らが受取人の好みよりむしろそのcharsetをサポートするなら、charsetを「推測する」支給を持っているそれらのユーザエージェントはcontent type分野からcharsetを使用しなければなりません。
3.7.2 Multipart Types
3.7.2 複合タイプ
MIME provides for a number of "multipart" types -- encapsulations of one or more entities within a single message-body. All multipart types share a common syntax, as defined in MIME [7], and MUST include a boundary parameter as part of the media type value. The message body is itself a protocol element and MUST therefore use only CRLF to represent line breaks between body-parts. Unlike in MIME, the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue).
MIMEは多くの「複合」のタイプに備えます--単一のメッセージ本体の中の1つ以上の実体のカプセル化。 すべての複合タイプが、MIME[7]で定義されるように一般的な構文を共有して、タイプが評価するメディアの一部として境界パラメタを入れなければなりません。 メッセージ本体は、それ自体でプロトコル要素であり、したがって、身体部分の間のラインブレイクを表すのにCRLFだけを使用しなければなりません。 MIMEなどと異なって、どんな複合メッセージのエピローグも空であるに違いありません。 HTTPアプリケーションがエピローグを伝えてはいけない、(オリジナル複合、含有、エピローグ)
In HTTP, multipart body-parts MAY contain header fields which are significant to the meaning of that part. A Content-Location header field (section 14.15) SHOULD be included in the body-part of each enclosed entity that can be identified by a URL.
HTTPでは、複合身体部分はその部分の意味に重要なヘッダーフィールドを含むかもしれません。 含まれていて、Content-位置のヘッダーはURLで特定できるそれぞれの同封の実体の身体部分で(セクション14.15)SHOULDをさばきます。
In general, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. If an application receives an unrecognized multipart subtype, the application MUST treat it as being equivalent to "multipart/mixed".
一般に、HTTPユーザエージェントSHOULDはMIMEユーザエージェントが複合タイプを受け取り次第続くように同じであるか同様の振舞いに続きます。 アプリケーションが認識されていない複合「副-タイプ」を受けるなら、アプリケーションは「複合か混ぜられること」に同等であるとしてそれを扱わなければなりません。
Note: The "multipart/form-data" type has been specifically defined
for carrying form data suitable for processing via the POST request
method, as described in RFC 1867 [15].
以下に注意してください。 「複合かデータを形成している」タイプはポスト要求メソッドを通して処理に適したフォームデータを運ぶために明確に定義されました、RFC1867[15]で説明されるように。
Fielding, et. al. Standards Track [Page 27] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[27ページ]RFC2068HTTP/1997年1月1.1日
3.8 Product Tokens
3.8 製品トークン
Product tokens are used to allow communicating applications to identify themselves by software name and version. Most fields using product tokens also allow sub-products which form a significant part of the application to be listed, separated by whitespace. By convention, the products are listed in order of their significance for identifying the application.
製品トークンは、ソフト名とバージョンで自分たちを特定するためにアプリケーションを伝えるのを許容するのに使用されます。 また、製品トークンを使用するほとんどの分野が、アプリケーションのかなりの部分を形成するサブ製品が空白によって記載されて、切り離されるのを許容します。 コンベンションによって、製品はアプリケーションを特定するためのそれらの意味の順に記載されています。
product = token ["/" product-version]
product-version = token
製品=トークン[「/」製品バージョン]製品バージョン=トークン
Examples:
例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
ユーザエージェント: CERN-LineMode/2.15libwww/2.17b3 Server: アパッチ/0.8.4
Product tokens should be short and to the point -- use of them for advertising or other non-essential information is explicitly forbidden. Although any token character may appear in a product- version, this token SHOULD only be used for a version identifier (i.e., successive versions of the same product SHOULD only differ in the product-version portion of the product value).
製品トークンは、短くて、肝心であるべきです--それらの広告か他の不要不急な情報の使用は明らかに禁じられます。 どんなトークンキャラクタですがも、製品バージョンに現れるかもしれません、このトークンSHOULD。バージョン識別子に単に使用されてください(すなわち、同じ製品SHOULDの連続したバージョンは生産物価値の製品バージョン部分で異なるだけです)。
3.9 Quality Values
3.9 上質の値
HTTP content negotiation (section 12) uses short "floating point"
numbers to indicate the relative importance ("weight") of various
negotiable parameters. A weight is normalized to a real number in the
range 0 through 1, where 0 is the minimum and 1 the maximum value.
HTTP/1.1 applications MUST NOT generate more than three digits after
the decimal point. User configuration of these values SHOULD also be
limited in this fashion.
HTTP内容交渉(セクション12)は、様々な交渉可能なパラメタの相対的な重要性(「重さ」)を示すのに短い「浮動小数点」番号を使用します。 重りは0〜1に範囲の実数に正常にされます、0が最小限であり、1が最大値であるところで。 HTTP/1.1のアプリケーションが小数点以下3ケタ以上を生成してはいけません。 また、こんなやり方で制限されていて、これらのユーザ構成はSHOULDを評価します。
qvalue = ( "0" [ "." 0*3DIGIT ] )
| ( "1" [ "." 0*3("0") ] )
qvalueが等しい、(「0インチ[「.」 0*3DIGIT)」| ( "1" [ "." 0*3("0") ] )
"Quality values" is a misnomer, since these values merely represent relative degradation in desired quality.
これらの値が単に必要な品質における相対的な退行を表すので、「上質の値」は誤称です。
3.10 Language Tags
3.10 言語タグ
A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. HTTP uses language tags within the Accept-Language and Content- Language fields.
言語タグは話されたか、書かれたか、または情報に関するコミュニケーションのために別の方法で人間によって他の人間まで運ばれた自然言語を特定します。 コンピュータ言語は明らかに除かれます。 HTTPはAccept-言語とContent言語分野の中で言語タグを使用します。
Fielding, et. al. Standards Track [Page 28] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[28ページ]RFC2068HTTP/1997年1月1.1日
The syntax and registry of HTTP language tags is the same as that defined by RFC 1766 [1]. In summary, a language tag is composed of 1 or more parts: A primary language tag and a possibly empty series of subtags:
言語がタグ付けをするHTTPの構文と登録はRFC1766[1]によって定義されたそれと同じです。 概要では、言語タグは1以上の部品で構成されます: プライマリ言語タグと「副-タグ」のことによると空のシリーズ:
language-tag = primary-tag *( "-" subtag )
言語タグ=プライマリタグ*(「-」subtag)
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
プライマリタグ=1*8ALPHA subtagは1*8ALPHAと等しいです。
Whitespace is not allowed within the tag and all tags are case- insensitive. The name space of language tags is administered by the IANA. Example tags include:
空白はタグの中に許容されていません、そして、すべてのタグがケース神経が鈍いです。 言語タグの名前スペースはIANAによって管理されます。 例のタグは:
en, en-US, en-cockney, i-cherokee, x-pig-latin
アン、アン米国の、そして、アンロンドン子のi-cherokee、xブタラテン
where any two-letter primary-tag is an ISO 639 language abbreviation and any two-letter initial subtag is an ISO 3166 country code. (The last three tags above are not registered tags; all but the last are examples of tags which could be registered in future.)
どんな2文字のプライマリタグもISO639言語略語とあらゆる2文字であるところで、初期のsubtagは3166年のISO国名略号です。 (上の最後の3個のタグは登録されたタグではありません; 最終以外のすべてがこれから登録できたタグに関する例です。)
3.11 Entity Tags
3.11 実体タグ
Entity tags are used for comparing two or more entities from the same requested resource. HTTP/1.1 uses entity tags in the ETag (section 14.20), If-Match (section 14.25), If-None-Match (section 14.26), and If-Range (section 14.27) header fields. The definition of how they are used and compared as cache validators is in section 13.3.3. An entity tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
実体タグは、同じ要求されたリソースから2つ以上の実体を比較するのに使用されます。 HTTP/1.1はETag(セクション14.20)(If-マッチ(セクション14.25)、なにも合わせないIf(セクション14.26)、およびIf-範囲(セクション14.27)ヘッダーフィールド)で実体タグを使用します。 セクション13.3.3にはそれらがキャッシュvalidatorsとしてどう使用されて、比較されるかに関する定義があります。 実体タグはことによると弱点インディケータによって前に置かれた不明瞭な引用文字列から成ります。
entity-tag = [ weak ] opaque-tag
=[弱い]の不透明な実体タグタグ
weak = "W/"
opaque-tag = quoted-string
弱い=“W/"不透明なタグ=引用文字列
A "strong entity tag" may be shared by two entities of a resource only if they are equivalent by octet equality.
それらが八重奏平等で同等である場合にだけ、「強い実体タグ」はリソースの2つの実体によって共有されるかもしれません。
A "weak entity tag," indicated by the "W/" prefix, may be shared by two entities of a resource only if the entities are equivalent and could be substituted for each other with no significant change in semantics. A weak entity tag can only be used for weak comparison.
実体を同等であり、著しい変化なしで意味論で互いに代入できる場合にだけ、リソースの2つの実体で“W/"接頭語によって示された「弱い実体タグ」を共有するかもしれません。 弱い比較に弱い実体タグを使用できるだけです。
An entity tag MUST be unique across all versions of all entities associated with a particular resource. A given entity tag value may be used for entities obtained by requests on different URIs without implying anything about the equivalence of those entities.
実体タグは特定のリソースに関連しているすべての実体のすべてのバージョンの向こう側にユニークであるに違いありません。 与えられた実体タグ価値は異なったURIに関する要求でそれらの実体の等価性に関して何も含意しないで得られた実体に使用されるかもしれません。
Fielding, et. al. Standards Track [Page 29] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[29ページ]RFC2068HTTP/1997年1月1.1日
3.12 Range Units
3.12 範囲ユニット
HTTP/1.1 allows a client to request that only part (a range of) the response entity be included within the response. HTTP/1.1 uses range units in the Range (section 14.36) and Content-Range (section 14.17) header fields. An entity may be broken down into subranges according to various structural units.
HTTP/1.1で、クライアントは、含まれていて、それが応答の中で(様々)の応答実体を分けるだけであるよう要求できます。 HTTP/1.1はRange(セクション14.36)とContent-範囲(セクション14.17)ヘッダーフィールドにレンジ・ユニットを使用します。 様々な構造ユニットに従って、実体はサブレンジへ砕けているかもしれません。
range-unit = bytes-unit | other-range-unit
レンジ・ユニットはバイト-ユニットと等しいです。| 他のレンジ・ユニット
bytes-unit = "bytes"
other-range-unit = token
バイト-ユニット=「バイト」他のレンジ・ユニットはトークンと等しいです。
The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations may ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.
HTTP/1.1によって定義された唯一のレンジ・ユニットが「バイト」です。 HTTP/1.1の実装が他のユニットを使用することで指定された範囲を無視するかもしれません。 HTTP/1.1は、範囲に関する知識によらないアプリケーションの実装を許容するように設計されています。
4 HTTP Message
4HTTPメッセージ
4.1 Message Types
4.1 メッセージタイプ
HTTP messages consist of requests from client to server and responses from server to client.
HTTPメッセージはクライアントからサーバまでの要求とサーバからクライアントまでの応答から成ります。
HTTP-message = Request | Response ; HTTP/1.1 messages
HTTPメッセージ=要求| 応答。 HTTP/1.1のメッセージ
Request (section 5) and Response (section 6) messages use the generic message format of RFC 822 [9] for transferring entities (the payload of the message). Both types of message consist of a start-line, one or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header fields, and an optional message-body.
(セクション5)とResponse(セクション6)メッセージが実体(メッセージのペイロード)を移すのにRFC822[9]のジェネリックメッセージ・フォーマットを使用するよう要求してください。 メッセージの両方のタイプはスタート系列、1つ以上のヘッダーフィールド(また、「ヘッダー」として、知られている)、ヘッダーフィールドの終わりを示す空の系列(すなわち、何もCRLFに先行していない系列)、および任意のメッセージ本体から成ります。
generic-message = start-line
*message-header
CRLF
[ message-body ]
ジェネリックメッセージ=スタート系列*メッセージヘッダーCRLF[メッセージ本体]
start-line = Request-Line | Status-Line
スタート系列=要求線| 状況表示行
In the interest of robustness, servers SHOULD ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
丈夫さのために、サーバSHOULDはRequest-線が予想されるところに受け取られたどんな空の台詞も無視します。 言い換えれば、サーバがメッセージの始めにプロトコルストリームを読んで、最初にCRLFを受けるなら、それはCRLFを無視するべきです。
Fielding, et. al. Standards Track [Page 30] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[30ページ]RFC2068HTTP/1997年1月1.1日
Note: certain buggy HTTP/1.0 client implementations generate an
extra CRLF's after a POST request. To restate what is explicitly
forbidden by the BNF, an HTTP/1.1 client must not preface or follow
a request with an extra CRLF.
以下に注意してください。 HTTP/1.0のあるバギーのクライアント実装がポストの要求の後に付加的なCRLFのものを生成します。 BNFによって明らかに禁じられることを言い直すために、HTTP/1.1クライアントは、付加的なCRLFとの要求の前書きしてはいけませんし、また後をつけてはいけません。
4.2 Message Headers
4.2 メッセージヘッダー
HTTP header fields, which include general-header (section 4.5),
request-header (section 5.3), response-header (section 6.2), and
entity-header (section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [9]. Each header field consists
of a name followed by a colon (":") and the field value. Field names
are case-insensitive. The field value may be preceded by any amount
of LWS, though a single SP is preferred. Header fields can be
extended over multiple lines by preceding each extra line with at
least one SP or HT. Applications SHOULD follow "common form" when
generating HTTP constructs, since there might exist some
implementations that fail to accept anything beyond the common forms.
HTTPヘッダ分野(一般的なヘッダー(セクション4.5)、要求ヘッダー(セクション5.3)、応答ヘッダ(セクション6.2)、および実体ヘッダー(セクション7.1)分野を含んでいる)はRFC822[9]のセクション3.1におけるそんなに与えられるのと同じジェネリック形式に続きます。 各ヘッダーフィールドがコロンがあとに続いた名前から成る、(「:」、)、そして、分野値。 フィールド名は大文字と小文字を区別しないです。 独身のSPは好まれますが、LWSのどんな量も分野値に先行するかもしれません。 ヘッダーフィールドはそれぞれの付加的な系列に先行することによって達せられた倍数が少なくとも1SPかHTと共に立ち並んでいるということであるかもしれません。 HTTPが構造物であると生成するとき、アプリケーションSHOULDは「一般的なフォーム」に続きます、何も一般的なフォームを超えたところまで受け入れないいくつかの実装が存在するかもしれないので。
message-header = field-name ":" [ field-value ] CRLF
「メッセージヘッダー=フィールド名」:、」 [分野値] CRLF
field-name = token
field-value = *( field-content | LWS )
フィールド名=トークン分野価値は*と等しいです。(分野内容| LWS)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
分野内容が<と等しい、分野値を作って、トークンの*TEXTか組み合わせのどちらかから成るOCTETs、tspecials、および引用文字列>。
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by request-header or response- header fields, and ending with the entity-header fields.
異なったフィールド名があるヘッダーフィールドが受け取られているオーダーは重要ではありません。 しかしながら、最初に一般的なヘッダーフィールドを送るのは、「良い習慣」です、要求ヘッダーか応答ヘッダーフィールドがあとに続いていて、実体ヘッダーフィールドで終わって。
Multiple message-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded.
そして、同じフィールド名がある複数のメッセージヘッダーフィールドがメッセージに存在しているかもしれない、そのヘッダーフィールドのための全体の分野値がコンマで切り離されたリスト[すなわち、#値()]と定義される場合にだけ。 複数のヘッダーフィールドを1つに結合するのが可能であるに違いない、「フィールド名:」 それぞれのその後の分野値を1日に追加することによってメッセージの意味論を変えないで、「分野値」組はコンマでそれぞれ分離しました。 したがって、同じフィールド名があるヘッダーフィールドが受け取られているオーダーは結合した分野価値の解釈に重要です、そして、メッセージを転送するとき、その結果、プロキシはこれらの分野値の注文を変えてはいけません。
Fielding, et. al. Standards Track [Page 31] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[31ページ]RFC2068HTTP/1997年1月1.1日
4.3 Message Body
4.3 メッセージ本体
The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The message-body differs from the entity-body only when a transfer coding has been applied, as indicated by the Transfer-Encoding header field (section 14.40).
HTTPメッセージのメッセージ本体(もしあれば)は、要求か応答に関連している実体本体を運ぶのに使用されます。 転送コード化が適用されたときだけ、メッセージ本体は実体本体と異なっています、Transferをコード化しているヘッダーフィールド(セクション14.40)によって示されるように。
message-body = entity-body
| <entity-body encoded as per Transfer-Encoding>
メッセージ本体=実体本体| Transfer-コード化に従ってコード化された<実体本体>。
Transfer-Encoding MUST be used to indicate any transfer codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding is a property of the message, not of the entity, and thus can be added or removed by any application along the request/response chain.
どんな転送コーディングも、メッセージの安全で適切な転送を確実にするのにアプリケーションで申し込んだのを示すのに転送コード化を使用しなければなりません。 その結果、要求/応答チェーンに沿ったどんなアプリケーションでも転送コード化を実体ではなく、メッセージの特性であり、加えるか、または取り除くことができます。
The rules for when a message-body is allowed in a message differ for requests and responses.
メッセージ本体がメッセージに許容されている時の間の規則は要求と応答のために異なります。
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers. A message-body MAY be included in a request only when the request method (section 5.1.1) allows an entity-body.
要求のメッセージヘッダーでのContent-長さかTransferをコード化しているヘッダーフィールドの包含で要求における、メッセージ本体の存在は合図されます。 要求メソッド(セクション5.1.1)が実体本体を許容する場合にだけ、メッセージ本体は要求に含まれるかもしれません。
For response messages, whether or not a message-body is included with a message is dependent on both the request method and the response status code (section 6.1.1). All responses to the HEAD request method MUST NOT include a message-body, even though the presence of entity- header fields might lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses MUST NOT include a message-body. All other responses do include a message-body, although it may be of zero length.
メッセージ本体が含まれているか否かに関係なく、メッセージと共に、応答メッセージに、要求メソッドと応答ステータスコードの両方(セクション6.1.1)の扶養家族は賛成しています。 HEADへのすべての応答が、メソッドがメッセージ本体を含んではいけないよう要求します、実体ヘッダーフィールドの存在は、人が、そうすると信じているように導くかもしれませんが。 すべての1xx(情報の)、204(内容がない)、および304(変更されない)の応答がメッセージ本体を含んではいけません。 それはゼロ・レングスのものであるかもしれませんが、他のすべての応答がメッセージ本体を含んでいます。
4.4 Message Length
4.4 メッセージ長
When a message-body is included with a message, the length of that body is determined by one of the following (in order of precedence):
メッセージ本体がメッセージで含まれているとき、そのボディーの長さは以下(先任順に)の1つで測定されます:
1. Any response message which MUST NOT include a message-body
(such as the 1xx, 204, and 304 responses and any response to a HEAD
request) is always terminated by the first empty line after the
header fields, regardless of the entity-header fields present in the
message.
1. メッセージ本体(HEAD要求への1xxや、204や、304の応答やどんな応答などのも)を含んではいけないどんな応答メッセージもいつもヘッダーフィールドの後の最初の空の系列によって終えられます、メッセージの現在の実体ヘッダーフィールドにかかわらず。
2. If a Transfer-Encoding header field (section 14.40) is present and
indicates that the "chunked" transfer coding has been applied, then
2. Transferをコード化しているヘッダーフィールド(セクション14.40)が、存在していて、次に、"chunkedする"の転送コード化が適用されたのを示すなら
Fielding, et. al. Standards Track [Page 32] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[32ページ]RFC2068HTTP/1997年1月1.1日
the length is defined by the chunked encoding (section 3.6).
chunkedコード化(セクション3.6)で長さは定義されます。
3. If a Content-Length header field (section 14.14) is present, its
value in bytes represents the length of the message-body.
3. Content-長さのヘッダーフィールド(セクション14.14)が存在しているなら、バイトで表現される値はメッセージ本体の長さを表します。
4. If the message uses the media type "multipart/byteranges", which is
self-delimiting, then that defines the length. This media type MUST
NOT be used unless the sender knows that the recipient can parse it;
the presence in a request of a Range header with multiple byte-range
specifiers implies that the client can parse multipart/byteranges
responses.
4. メッセージがメディアタイプ「複合/byteranges」(自己に、区切っている)を使用するなら、それは長さを定義します。 送付者が、受取人がそれを分析できるのを知らない場合、このメディアタイプを使用してはいけません。 複数のバイト範囲特許説明書の作成書とのRangeヘッダーの要求における存在は、クライアントが複合/byteranges応答を分析できるのを含意します。
5. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since that
would leave no possibility for the server to send back a response.)
5. 接続を終えるサーバで。 (要求本体の先を示すのに接続を終えるのを使用できません、それはサーバが応答を返送する可能性を全く残さないでしょう、したがって。)
For compatibility with HTTP/1.0 applications, HTTP/1.1 requests containing a message-body MUST include a valid Content-Length header field unless the server is known to be HTTP/1.1 compliant. If a request contains a message-body and a Content-Length is not given, the server SHOULD respond with 400 (bad request) if it cannot determine the length of the message, or with 411 (length required) if it wishes to insist on receiving a valid Content-Length.
HTTP/1.0のアプリケーションとの互換性のために、HTTP/1.1が対応であったならサーバが知られない場合、メッセージ本体を含むHTTP/1.1の要求が有効なContent-長さのヘッダーフィールドを含まなければなりません。 要求がメッセージ本体を含んでいるか、そして、Content-長さは与えられていません、有効なContent-長さを受けると主張したがっていて、メッセージ、または411がある長さを測定できないなら(長さが必要です)SHOULDが400(悪い要求)で反応させるサーバ。
All HTTP/1.1 applications that receive entities MUST accept the "chunked" transfer coding (section 3.6), thus allowing this mechanism to be used for messages when the message length cannot be determined in advance.
実体を受けるすべてのHTTP/1.1のアプリケーションが"chunkedする"の転送コード化(セクション3.6)を受け入れなければなりません、あらかじめメッセージ長を測定できないとき、その結果、このメカニズムがメッセージに使用されるのを許容します。
Messages MUST NOT include both a Content-Length header field and the "chunked" transfer coding. If both are received, the Content-Length MUST be ignored.
メッセージはContent-長さのヘッダーフィールドと"chunkedする"の転送コード化の両方を含んではいけません。 両方が受け取られているなら、Content-長さを無視しなければなりません。
When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.
メッセージ本体が許容されているメッセージでContent-長さを与えるとき、分野値はまさにメッセージ本体のOCTETsの数に合わなければなりません。 無効の長さが受け取られて、検出されるとき、HTTP/1.1人のユーザエージェントがユーザに通知しなければなりません。
Fielding, et. al. Standards Track [Page 33] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[33ページ]RFC2068HTTP/1997年1月1.1日
4.5 General Header Fields
4.5 一般ヘッダーフィールド
There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the message being transmitted.
要求と応答メッセージの両方のために一般的な適用性を持っていますが、移される実体に適用されないいくつかのヘッダーフィールドがあります。 これらのヘッダーフィールドは送られるメッセージだけに適用されます。
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.19
| Pragma ; Section 14.32
| Transfer-Encoding ; Section 14.40
| Upgrade ; Section 14.41
| Via ; Section 14.44
一般的なヘッダーはキャッシュコントロールと等しいです。 セクション14.9| 接続。 セクション14.10| デートしてください。 セクション14.19| Pragma。 セクション14.32| 転送をコード化しています。 セクション14.40| アップグレードしてください。 セクション14.41| を通して。 セクション14.44
General-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields. Unrecognized header fields are treated as entity-header fields.
単にプロトコルバージョンにおける変化と組み合わせて一般ヘッダーフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが一般的なヘッダーフィールドであると認めるなら、一般的なヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドは実体ヘッダーフィールドとして扱われます。
5 Request
5要求
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
クライアントからサーバまでの要求メッセージはそのメッセージの最初の系列の中にリソースに適用されるべきメソッド、リソースに関する識別子、および使用中のプロトコルバージョンを含んでいます。
Request = Request-Line ; Section 5.1
*( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
=要求線を要求してください。 セクション5.1*(一般的なヘッダー; セクション4.5| 要求ヘッダー; セクション5.3| 実体ヘッダー)。 セクション7.1 CRLF[メッセージ本体]。 セクション7.2
5.1 Request-Line
5.1 要求線
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence.
Request-URIとプロトコルバージョンがあとに続いていて、CRLFと共に終わって、Request-線はメソッドトークンで始まります。 要素はSPキャラクタによって切り離されます。 最終的なCRLF系列以外に、どんなCRもLFも許容されていません。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
メソッドSP要求URI SP HTTPバージョン要求線=CRLF
Fielding, et. al. Standards Track [Page 34] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[34ページ]RFC2068HTTP/1997年1月1.1日
5.1.1 Method
5.1.1 メソッド
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
MethodトークンはRequest-URIによって特定されたリソースに実行されるべきメソッドを示します。 メソッドは大文字と小文字を区別しています。
Method = "OPTIONS" ; Section 9.2
| "GET" ; Section 9.3
| "HEAD" ; Section 9.4
| "POST" ; Section 9.5
| "PUT" ; Section 9.6
| "DELETE" ; Section 9.7
| "TRACE" ; Section 9.8
| extension-method
メソッドは「オプション」と等しいです。 セクション9.2| 「得ます」。 セクション9.3| 「向かってください」。 セクション9.4| 「ポスト」。 セクション9.5| 「置きます」。 セクション9.6| 「削除します」。 セクション9.7| 「跡」。 セクション9.8| 拡大メソッド
extension-method = token
拡大メソッドはトークンと等しいです。
The list of methods allowed by a resource can be specified in an Allow header field (section 14.7). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the set of allowed methods can change dynamically. Servers SHOULD return the status code 405 (Method Not Allowed) if the method is known by the server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the server. The list of methods known by a server can be listed in a Public response-header field (section 14.35).
Allowヘッダーフィールド(セクション14.7)でリソースによって許容されたメソッドのリストを指定できます。 メソッドが現在リソースに許容されているか否かに関係なく、応答の復帰コードはいつもクライアントに通知します、許容メソッドのセットがダイナミックに変化できるので。 メソッドがメソッドが認識されていないなら要求されたリソース、および501(Implementedでない)のために許容されていないのを除いて、サーバによって知られているか、またはサーバによって実装されないなら、サーバSHOULDはステータスコード405(メソッドNot Allowed)を返します。Public応答ヘッダ分野(セクション14.35)にサーバによって知られていたメソッドのリストはリストアップできます。
The methods GET and HEAD MUST be supported by all general-purpose servers. All other methods are optional; however, if the above methods are implemented, they MUST be implemented with the same semantics as those specified in section 9.
メソッドのGETとHEAD MUST、すべての汎用サーバで、サポートされてください。 他のすべてのメソッドが任意です。 しかしながら、上のメソッドが実装されるなら、セクション9で指定されたものと同じ意味論でそれらを実装しなければなりません。
5.1.2 Request-URI
5.1.2 要求URI
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
Request-URIは、Uniform Resource Identifier(セクション3.2)であり、要求を適用するリソースを特定します。
Request-URI = "*" | absoluteURI | abs_path
要求URI=「*」| absoluteURI| 腹筋_経路
The three options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be
Request-URIのための3つのオプションが要求の本質に依存しています。 アスタリスク「*」は、要求が特定のリソースに適用するのではなく、サーバ自体に適用されることを意味して、使用されるメソッドが必ずリソースに適用されるというわけではないときだけ、許容されています。 1つの例がそうでしょう。
OPTIONS * HTTP/1.1
オプション*HTTP/1.1
The absoluteURI form is required when the request is being made to a proxy. The proxy is requested to forward the request or service it
要求がプロキシに出されているとき、absoluteURIフォームが必要です。 要求を転送するか、またはプロキシがそれを調整するよう要求されています。
Fielding, et. al. Standards Track [Page 35] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[35ページ]RFC2068HTTP/1997年1月1.1日
from a valid cache, and return the response. Note that the proxy MAY forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy MUST be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:
有効なキャッシュ、およびリターンからの応答。 プロキシが別のプロキシ、または、直接absoluteURIによって指定されたサーバに要求を転送するかもしれないことに注意してください。 要求輪を避けるために、プロキシはサーバー名のすべてを認識できなければなりません、どんな別名、地理的変異、および数値IPアドレスも含んでいて。 例のRequest-線は以下の通りでしょう。
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1を得てください。
To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.
HTTPの将来のバージョンにおけるすべての要求におけるabsoluteURIsへの変遷を考慮するために、すべてのHTTP/1.1のサーバが要求でabsoluteURIフォームを受け入れなければなりません、HTTP/1.1人のクライアントが要求でプロキシに彼らを生成するだけでしょうが。
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case the absolute path of the URI MUST be transmitted (see section 3.2.1, abs_path) as the Request-URI, and the network location of the URI (net_loc) MUST be transmitted in a Host header field. For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the lines:
最も一般的なフォームのRequest-URIは発生源サーバかゲートウェイに関するリソースを特定するのにおいてそんなに使用されています。 この場合、Request-URIとしてURIの絶対パスを伝えなければなりません、そして、(セクション3.2.1を見てください、腹筋_経路)HostヘッダーフィールドでURI(ネット_loc)のネットワークの位置を伝えなければなりません。 例えば、直接発生源サーバからの上記のリソースを検索したがっているクライアントは80ホスト"www.w3.org"を移植して、系列を送るためにTCP接続を創造するでしょう:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
/pub/WWW/TheProject.html HTTP/1.1ホストを手に入れてください: www.w3.org
followed by the remainder of the Request. Note that the absolute path cannot be empty; if none is present in the original URI, it MUST be given as "/" (the server root).
Requestの残りはあとに続いています。 絶対パスが空であるはずがないことに注意してください。 「なにもオリジナルのURIで存在していないなら、」 /としてそれを与えなければならない」(サーバルート)。
If a proxy receives a request without any path in the Request-URI and the method specified is capable of supporting the asterisk form of request, then the last proxy on the request chain MUST forward the request with "*" as the final Request-URI. For example, the request
プロキシがRequest-URIにおける少しも経路なしで要求を受け取って、指定されたメソッドが要求のアスタリスクフォームをサポートすることができるなら、要求チェーンの最後のプロキシは最終的な要求URIとして「*」がある要求を転送しなければなりません。 例えば、要求
OPTIONS http://www.ics.uci.edu:8001 HTTP/1.1
オプション http://www.ics.uci.edu:8001 HTTP/1.1
would be forwarded by the proxy as
プロキシによって進められるでしょう。
OPTIONS * HTTP/1.1
Host: www.ics.uci.edu:8001
オプション*HTTP/1.1ホスト: www.ics.uci.edu: 8001
after connecting to port 8001 of host "www.ics.uci.edu".
8001ホスト"www.ics.uci.edu"を移植するために接続した後に。
The Request-URI is transmitted in the format specified in section 3.2.1. The origin server MUST decode the Request-URI in order to properly interpret the request. Servers SHOULD respond to invalid Request-URIs with an appropriate status code.
Request-URIはセクション3.2.1で指定された形式で伝えられます。 発生源サーバは、適切に要求を解釈するためにRequest-URIを解読しなければなりません。 サーバSHOULDは適切なステータスコードで無効のRequest-URIに応じます。
Fielding, et. al. Standards Track [Page 36] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[36ページ]RFC2068HTTP/1997年1月1.1日
In requests that they forward, proxies MUST NOT rewrite the "abs_path" part of a Request-URI in any way except as noted above to replace a null abs_path with "*", no matter what the proxy does in its internal implementation.
それらが転送する要求では、ヌル腹筋_経路を「*」に取り替えるために上に述べられるのを除いて、プロキシは何らかの方法でRequest-URIの「腹筋_経路」部分を書き直してはいけません、プロキシが内部の実装で何をしても。
Note: The "no rewrite" rule prevents the proxy from changing the
meaning of the request when the origin server is improperly using a
non-reserved URL character for a reserved purpose. Implementers
should be aware that some pre-HTTP/1.1 proxies have been known to
rewrite the Request-URI.
以下に注意してください。 「書き直しがありません」規則は、発生源サーバが予約された目的に不適切に非控え目なURLキャラクタを使用しているとき、プロキシが要求の意味を変えるのを防ぎます。 Implementersは何人かのプレHTTP/1.1のプロキシがRequest-URIを書き直すのが知られているのを意識しているべきです。
5.2 The Resource Identified by a Request
5.2 要求で特定されたリソース
HTTP/1.1 origin servers SHOULD be aware that the exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.
HTTP/1.1発生源サーバSHOULD、インターネット要求で特定された正確なリソースがRequest-URIとHostヘッダーフィールドの両方を調べることによって決定するのを意識してください。
An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value. (But see section 19.5.1 for other requirements on Host support in HTTP/1.1.)
リソースが要求されたホストで異ならない発生源サーバはHostヘッダーフィールド価値を無視するかもしれません。 (しかし、HTTP/1.1におけるHostサポートに関する他の要件に関してセクション19.5.1を見てください。)
An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity hostnames) MUST use the following rules for determining the requested resource on an HTTP/1.1 request:
要求された(時々事実上のホストか虚栄ホスト名と呼ばれます)ホストに基づくリソースを差別化する発生源サーバはHTTP/1.1要求に関する要求されたリソースを決定するのに以下の規則を使用しなければなりません:
1. If Request-URI is an absoluteURI, the host is part of the
Request-URI. Any Host header field value in the request MUST be
ignored.
1. Request-URIがabsoluteURIであるなら、ホストはRequest-URIの一部です。 要求におけるどんなHostヘッダーフィールド価値も無視しなければなりません。
2. If the Request-URI is not an absoluteURI, and the request
includes a Host header field, the host is determined by the Host
header field value.
2. Request-URIがabsoluteURIでなく、要求がHostヘッダーフィールドを含んでいるなら、ホストはHostヘッダーフィールド価値で決定します。
3. If the host as determined by rule 1 or 2 is not a valid host on
the server, the response MUST be a 400 (Bad Request) error
message.
3. 規則1か2で決定するホストがサーバの有効なホストでないなら、応答は400(悪いRequest)エラーメッセージであるに違いありません。
Recipients of an HTTP/1.0 request that lacks a Host header field MAY attempt to use heuristics (e.g., examination of the URI path for something unique to a particular host) in order to determine what exact resource is being requested.
Hostヘッダーフィールドを欠いているHTTP/1.0要求の受取人は、どんな正確なリソースが要求されているかを決定するのに、発見的教授法(例えば、特定のホストに何かユニークなもののためのURI経路の試験)を使用するのを試みるかもしれません。
5.3 Request Header Fields
5.3 要求ヘッダーフィールド
The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics
クライアントは要求ヘッダーフィールドで要求、およびクライアント自身に関する追加情報を通過できます、サーバに。これらの分野は要求修飾語として機能します、意味論で
Fielding, et. al. Standards Track [Page 37] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[37ページ]RFC2068HTTP/1997年1月1.1日
equivalent to the parameters on a programming language method invocation.
プログラミング言語メソッド実施に関するパラメタに、同等です。
request-header = Accept ; Section 14.1
| Accept-Charset ; Section 14.2
| Accept-Encoding ; Section 14.3
| Accept-Language ; Section 14.4
| Authorization ; Section 14.8
| From ; Section 14.22
| Host ; Section 14.23
| If-Modified-Since ; Section 14.24
| If-Match ; Section 14.25
| If-None-Match ; Section 14.26
| If-Range ; Section 14.27
| If-Unmodified-Since ; Section 14.28
| Max-Forwards ; Section 14.31
| Proxy-Authorization ; Section 14.34
| Range ; Section 14.36
| Referer ; Section 14.37
| User-Agent ; Section 14.42
要求ヘッダー=は受け入れます。 セクション14.1| Charsetを受け入れます。 セクション14.2| コード化を受け入れます。 セクション14.3| 言語を受け入れます。 セクション14.4| 承認。 セクション14.8| 。 セクション14.22| ホスト。 セクション14.23| 以来変更されるなら。 セクション14.24| -合ってください、。 セクション14.25| なにも合っていないなら。 セクション14.26| -及んでください、。 セクション14.27| 以来変更されていないなら。 セクション14.28| マックス-フォワード。 セクション14.31| プロキシ承認。 セクション14.34| 及んでください。 セクション14.36| Referer。 セクション14.37| ユーザエージェント。 セクション14.42
Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of request- header fields if all parties in the communication recognize them to be request-header fields. Unrecognized header fields are treated as entity-header fields.
単にプロトコルバージョンにおける変化と組み合わせて要求ヘッダーフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが要求ヘッダーフィールドであると認めるなら、要求ヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドは実体ヘッダーフィールドとして扱われます。
6 Response
6 応答
After receiving and interpreting a request message, a server responds with an HTTP response message.
要求メッセージを受け取って、解釈した後に、サーバはHTTP応答メッセージで反応します。
Response = Status-Line ; Section 6.1
*( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
応答は状況表示行と等しいです。 セクション6.1*(一般的なヘッダー; セクション4.5| 応答ヘッダ; セクション6.2| 実体ヘッダー)。 セクション7.1 CRLF[メッセージ本体]。 セクション7.2
6.1 Status-Line
6.1 状況表示行
The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Responseメッセージの最初の系列はStatus-線です、数値ステータスコードとその関連原文の句があとに続いたプロトコルバージョンから成って、各要素がSPキャラクタによって切り離されている状態で。 最終的なCRLF系列以外に、どんなCRもLFも許容されていません。
Fielding, et. al. Standards Track [Page 38] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[38ページ]RFC2068HTTP/1997年1月1.1日
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状況表示行=HTTPバージョンSPステータスコードSP理由句のCRLF
6.1.1 Status Code and Reason Phrase
6.1.1 コードと理由が言葉で表す状態
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in section 10. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.
Status-コード要素は要望を理解して、応じる試みの3ケタの整数結果コードです。 これらのコードはセクション10で完全に定義されます。 Reason-句がStatus-コードの短い原文の記述を与えることを意図します。 Status-コードは使用のためにオートマトンで意図します、そして、Reason-句は人間のユーザのために意図します。 クライアントは、Reason句を調べるか、または表示する必要はありません。
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
Status-コードの最初のケタは応答のクラスを定義します。 下2ケタには、どんな分類の役割もありません。 最初のケタのための5つの値があります:
o 1xx: Informational - Request received, continuing process
o 1xx: 情報、--受け取られていていて、継続するプロセスを要求してください
o 2xx: Success - The action was successfully received, understood,
and accepted
o 2xx: 成功--動作を首尾よく受けて、理解して、受け入れました。
o 3xx: Redirection - Further action must be taken in order to
complete the request
o 3xx: リダイレクション--要求を終了するためにさらなる行動を取らなければなりません。
o 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
o 4xx: クライアントError--要求が、誤りのある構文を含んでいるか、または実現できません。
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
o 5xx: サーバError--サーバは明らかに有効な要求を実現させませんでした。
The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol.
以下でHTTP/1.1のために定義された数値ステータスコードの個人価値、および対応する句のReasonものの例のセットを寄贈します。 ここにリストアップされた句がお勧めであるだけである理由--プロトコルに影響しないで、それらを地方の同等物に取り替えるかもしれません。
Status-Code = "100" ; Continue
| "101" ; Switching Protocols
| "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "203" ; Non-Authoritative Information
| "204" ; No Content
| "205" ; Reset Content
| "206" ; Partial Content
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
ステータスコード=「100」。 続いてください。| "101" ; 切り換えプロトコル| "200" ; OK| "201" ; 作成されます。| "202" ; 受け入れます。| "203" ; 非信頼できる情報| "204" ; 内容がありません。| "205" ; リセット内容| "206" ; 部分的な内容| "300" ; 選択式| "301" ; 永久に、移行します。| "302" ; 一時、移行します。
Fielding, et. al. Standards Track [Page 39] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[39ページ]RFC2068HTTP/1997年1月1.1日
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "409" ; Conflict
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; HTTP Version not supported
| extension-code
| "303" ; 別に見てください。| "304" ; 変更されません。| "305" ; プロキシを使用してください。| "400" ; 悪い要求| "401" ; 権限のない| "402" ; 支払いが必要です。| "403" ; 禁じられます。| "404" ; 見つけられません。| "405" ; 許容されなかったメソッド| "406" ; 許容できない| "407" ; プロキシ認証が必要です。| "408" ; タイムアウトを要求してください。| "409" ; 闘争| "410" ; 行きます。| "411" ; 長さが必要です。| "412" ; 前提条件は失敗しました。| "413" ; 大き過ぎる状態で実体を要求してください。| "414" ; 要求URIも多| "415" ; サポートされないメディアタイプ| "500" ; 内部サーバーエラー| "501" ; 実装されません。| "502" ; 悪いゲートウェイ| "503" ; 入手できないサービス| "504" ; ゲートウェイタイムアウト| "505" ; バージョンがサポートしなかったHTTP| 拡張コード
extension-code = 3DIGIT
拡張コード=3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
CR、LF>を除いた理由句の=*<TEXT
HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.
HTTPステータスコードは広げることができます。 そのような理解は明らかに望ましいのですが、HTTPアプリケーションは、すべての登録されたステータスコードの意味を理解するのに必要ではありません。 しかしながら、アプリケーションは、最初のケタによって示されるようにどんなステータスコードのクラスも理解して、認識されていない応答が例外があるそのクラスのステータスコードであるに違いありませんが、x00に同等であるとしてキャッシュされていた状態でどんな認識されていない応答も扱わなければなりません。 例えば、431の認識されていないステータスコードがクライアントによって受け取られるなら、それは、まるで400ステータスコードを受け取ったかのように要求には不具合があったと安全に仮定して、応答を扱うことができます。 そのような場合、ユーザエージェントSHOULDは応答と共に返された実体をユーザに提示します、その実体が珍しい状態がわかる人間の読み込み可能な情報を含んでいそうであるので。
Fielding, et. al. Standards Track [Page 40] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[40ページ]RFC2068HTTP/1997年1月1.1日
6.2 Response Header Fields
6.2 応答ヘッダーフィールド
The response-header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
応答ヘッダ分野で、サーバはStatus線に置くことができない応答に関する追加情報を通過できます。 これらのヘッダーフィールドはサーバの周りと、そして、Request-URIによって特定されたリソースへのさらなるアクセスの周りに関して知らせます。
response-header = Age ; Section 14.6
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Public ; Section 14.35
| Retry-After ; Section 14.38
| Server ; Section 14.39
| Vary ; Section 14.43
| Warning ; Section 14.45
| WWW-Authenticate ; Section 14.46
応答ヘッダ=時代。 セクション14.6| 位置。 セクション14.30| プロキシで認証します。 セクション14.33| 公衆。 セクション14.35| -後に再試行してください。 セクション14.38| サーバ。 セクション14.39| 異なってください。 セクション14.43| 警告。 セクション14.45| WWW認証します。 セクション14.46
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response- header fields if all parties in the communication recognize them to be response-header fields. Unrecognized header fields are treated as entity-header fields.
単にプロトコルバージョンにおける変化と組み合わせて応答ヘッダフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが応答ヘッダ分野であると認めるなら、応答ヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドは実体ヘッダーフィールドとして扱われます。
7 Entity
7実体
Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.
別の方法で要求メソッドか応答ステータスコードによって制限されないなら、要求とResponseメッセージは実体を移すかもしれません。 いくつかの応答が実体ヘッダーを含むだけでしょうが、実体は実体ヘッダーフィールドと実体本体から成ります。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
このセクションで、送付者と受取人の両方がクライアントかサーバのどちらかについて言及します、だれが発信するか、そして、だれが実体を受けるかによって。
7.1 Entity Header Fields
7.1 実体ヘッダーフィールド
Entity-header fields define optional metainformation about the entity-body or, if no body is present, about the resource identified by the request.
実体ヘッダーフィールドが実体本体に関して任意のmetainformationを定義するか、またはボディーはいいえなら存在しています、要求で特定されたリソースに関して。
Fielding, et. al. Standards Track [Page 41] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[41ページ]RFC2068HTTP/1997年1月1.1日
entity-header = Allow ; Section 14.7
| Content-Base ; Section 14.11
| Content-Encoding ; Section 14.12
| Content-Language ; Section 14.13
| Content-Length ; Section 14.14
| Content-Location ; Section 14.15
| Content-MD5 ; Section 14.16
| Content-Range ; Section 14.17
| Content-Type ; Section 14.18
| ETag ; Section 14.20
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
=が許容する実体ヘッダー。 セクション14.7| 満足している基地。 セクション14.11| 内容をコード化しています。 セクション14.12| 満足している言語。 セクション14.13| コンテンツの長さ。 セクション14.14| 満足している位置。 セクション14.15| 満足しているMD5。 セクション14.16| 満足している範囲。 セクション14.17| コンテントタイプ。 セクション14.18| ETag。 セクション14.20| 期限が切れます。 セクション14.21| 最終更新日。 セクション14.29| 拡張ヘッダー
extension-header = message-header
拡張ヘッダーはメッセージヘッダーと等しいです。
The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and forwarded by proxies.
拡張ヘッダーメカニズムは、追加実体ヘッダーフィールドがプロトコルを変えないで定義されるのを許容しますが、受取人が認識可能であるとこれらの分野を思うことができません。 認識されていないヘッダーは受取人によって無視されて、プロキシによって進められたSHOULDをさばきます。
7.2 Entity Body
7.2 実体本体
The entity-body (if any) sent with an HTTP request or response is in a format and encoding defined by the entity-header fields.
実体ヘッダーフィールドによって定義された書式とコード化にはHTTP要求か応答と共に送られた実体本体(もしあれば)があります。
entity-body = *OCTET
実体本体=*OCTET
An entity-body is only present in a message when a message-body is present, as described in section 4.3. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that may have been applied to ensure safe and proper transfer of the message.
メッセージ本体が存在しているとき、実体本体はセクション4.3で説明されるように単にメッセージに存在しています。 メッセージ本体からメッセージの安全で適切な転送を確実にするために適用されたどんなTransfer-コード化も解読することによって、実体本体を得ます。
7.2.1 Type
7.2.1 タイプ
When an entity-body is included with a message, the data type of that body is determined via the header fields Content-Type and Content- Encoding. These define a two-layer, ordered encoding model:
実体本体がメッセージで含まれているとき、そのボディーのデータ型はヘッダーフィールドコンテントタイプとContentコード化を通して決定しています。 これらはモデルをコード化しながら注文された2層を定義します:
entity-body := Content-Encoding( Content-Type( data ) )
実体本体:=内容コード化(コンテントタイプ(データ))
Content-Type specifies the media type of the underlying data. Content-Encoding may be used to indicate any additional content codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. There is no default encoding.
コンテントタイプは基本的なデータのメディアタイプを指定します。 内容をコード化しているのは、どんな追加満足しているコーディングも通常データ圧縮の目的のためのそれをデータに適用したのを示すのに使用されているのが、要求されたリソースの特性であるということであるかもしれません。 デフォルトコード化がありません。
Fielding, et. al. Standards Track [Page 42] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[42ページ]RFC2068HTTP/1997年1月1.1日
Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type field, the recipient MAY attempt to guess the media type via inspection of its content and/or the name extension(s) of the URL used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
実体本体を含んでいて、SHOULDがそのボディーのメディアタイプを定義するコンテントタイプヘッダーフィールドを含んでいるというどんなHTTP/1.1メッセージ。 コンテントタイプ分野(メディアが内容の点検でタイプされて、URLの名前拡大が以前はよくリソースを特定していたと推測する受取人5月の試み)によってメディアタイプは単に与えられません。 メディアタイプが未知のままでいるなら、受取人SHOULDはタイプ「八重奏アプリケーション/ストリーム」としてそれを扱います。
7.2.2 Length
7.2.2 長さ
The length of an entity-body is the length of the message-body after any transfer codings have been removed. Section 4.4 defines how the length of a message-body is determined.
どんな転送コーディングも取り除いた後に実体本体の長さはメッセージ本体の長さです。 セクション4.4はメッセージ本体の長さがどう決定しているかを定義します。
8 Connections
8 コネクションズ
8.1 Persistent Connections
8.1のパーシステントコネクション
8.1.1 Purpose
8.1.1 目的
Prior to persistent connections, a separate TCP connection was established to fetch each URL, increasing the load on HTTP servers and causing congestion on the Internet. The use of inline images and other associated data often requires a client to make multiple requests of the same server in a short amount of time. Analyses of these performance problems are available [30][27]; analysis and results from a prototype implementation are in [26].
パーシステントコネクションの前に、別々のTCP接続は各URLをとって来るために確立されました、HTTPサーバで負荷を増強して、インターネットで混雑を引き起こして。 インライン画像と他の関連データの使用は、しばしばクライアントが短い時間で同じサーバの複数の要求をするのを必要とします。 これらの性能問題の分析は利用可能な[30][27]です。 プロトタイプ実装からの分析と結果が[26]にあります。
Persistent HTTP connections have a number of advantages:
永続的なHTTP接続には、多くの利点があります:
o By opening and closing fewer TCP connections, CPU time is saved,
and memory used for TCP protocol control blocks is also saved.
o HTTP requests and responses can be pipelined on a connection.
Pipelining allows a client to make multiple requests without
waiting for each response, allowing a single TCP connection to be
used much more efficiently, with much lower elapsed time.
o Network congestion is reduced by reducing the number of packets
caused by TCP opens, and by allowing TCP sufficient time to
determine the congestion state of the network.
o HTTP can evolve more gracefully; since errors can be reported
without the penalty of closing the TCP connection. Clients using
future versions of HTTP might optimistically try a new feature, but
if communicating with an older server, retry with old semantics
after an error is reported.
o より少ないTCP接続を開いて、終えることによって、CPU時間は節約されます、そして、また、TCPプロトコル制御ブロックに使用されるメモリを保存します。接続のときにo HTTP要求と応答をpipelinedすることができます。 各応答を待たないで、クライアントはパイプライン処理で複数の要求をすることができます、単独のTCP接続がはるかに効率的に使用されるのを許容して開いて. o Network混雑が減少することによって抑えられるはるかに低い経過時間で、TCPによって引き起こされたパケットの数は、ネットワークの混雑事情を決定できるくらいの時間をTCPに許容することによって、そうします。o HTTPは、より優雅に発展できます。 以来、TCP接続を終える刑罰なしで誤りを報告できます。 HTTPの将来のバージョンを使用しているクライアントは楽観的に新機能を試みるかもしれませんが、より古いサーバとコミュニケートするなら、古い意味論で、誤りが報告された後に再試行してください。
HTTP implementations SHOULD implement persistent connections.
HTTP実装SHOULDはパーシステントコネクションを実装します。
Fielding, et. al. Standards Track [Page 43] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[43ページ]RFC2068HTTP/1997年1月1.1日
8.1.2 Overall Operation
8.1.2 総合的な操作
A significant difference between HTTP/1.1 and earlier versions of HTTP is that persistent connections are the default behavior of any HTTP connection. That is, unless otherwise indicated, the client may assume that the server will maintain a persistent connection.
HTTP/1.1とHTTPの以前のバージョンの著しい違いはパーシステントコネクションがどんなHTTP接続のデフォルトの振舞いであるということです。 すなわち、別の方法で示されない場合、クライアントは、サーバがパーシステントコネクションを維持すると仮定するかもしれません。
Persistent connections provide a mechanism by which a client and a server can signal the close of a TCP connection. This signaling takes place using the Connection header field. Once a close has been signaled, the client MUST not send any more requests on that connection.
パーシステントコネクションはクライアントとサーバがTCP接続の閉鎖を示すことができるメカニズムを提供します。 このシグナリングは、Connectionヘッダーフィールドを使用することで行われます。 閉鎖がいったん合図されると、クライアントはそれ以上の要求をその接続に送ってはいけません。
8.1.2.1 Negotiation
8.1.2.1 交渉
An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to maintain a persistent connection unless a Connection header including the connection-token "close" was sent in the request. If the server chooses to close the connection immediately after sending the response, it SHOULD send a Connection header including the connection-token close.
HTTP/1.1サーバは、「近いところに」接続トークンを含むConnectionヘッダーが要求で送られなかったならHTTP/1.1クライアントがパーシステントコネクションを維持するつもりであると仮定するかもしれません。 サーバが、選ぶなら、応答を送る直後接続を終えてください、それ。近くに接続トークンを含んでいて、SHOULDはConnectionヘッダーを送ります。
An HTTP/1.1 client MAY expect a connection to remain open, but would decide to keep it open based on whether the response from a server contains a Connection header with the connection-token close. In case the client does not want to maintain a connection for more than that request, it SHOULD send a Connection header including the connection-token close.
HTTP/1.1クライアントは、接続が開いたままで残っていると予想するかもしれませんが、サーバからの応答が接続トークン閉鎖でConnectionヘッダーを含んでいるかどうかに基づいて開くようにそれを保つと決めるでしょう。 場合におけるクライアントはその要求以上のための接続を維持したがっていません、それ。近くに接続トークンを含んでいて、SHOULDはConnectionヘッダーを送ります。
If either the client or the server sends the close token in the Connection header, that request becomes the last one for the connection.
クライアントかサーバのどちらかがConnectionヘッダーで近いトークンを送るなら、その要求は接続のための最後のものになります。
Clients and servers SHOULD NOT assume that a persistent connection is maintained for HTTP versions less than 1.1 unless it is explicitly signaled. See section 19.7.1 for more information on backwards compatibility with HTTP/1.0 clients.
クライアントとサーバSHOULD NOTは、それが明らかに合図されない場合パーシステントコネクションがHTTPバージョンのために1.1未満に維持されると仮定します。 HTTP/1.0人のクライアントとの遅れている互換性の詳しい情報に関してセクション19.7.1を見てください。
In order to remain persistent, all messages on the connection must have a self-defined message length (i.e., one not defined by closure of the connection), as described in section 4.4.
接続に関するすべてのメッセージには、永続的なままで残るために、自己によって定義されたメッセージ長(すなわち、接続の閉鎖によって定義されなかったもの)がなければなりません、セクション4.4で説明されるように。
8.1.2.2 Pipelining
8.1.2.2 パイプライン処理
A client that supports persistent connections MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
要求(すなわち、各応答を待たないで、複数の要求を送る)をパーシステントコネクション5月の「パイプライン」にサポートするクライアント。 サーバは要求を受け取ったという同次におけるそれらの要求への応答を送らなければなりません。
Fielding, et. al. Standards Track [Page 44] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[44ページ]RFC2068HTTP/1997年1月1.1日
Clients which assume persistent connections and pipeline immediately after connection establishment SHOULD be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it MUST NOT pipeline before it knows the connection is persistent. Clients MUST also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
最初のpipelined試みが失敗するならコネクション確立SHOULD直後パーシステントコネクションとパイプラインが彼らの接続を再試行するように準備されると仮定するクライアント。 クライアントがそのような再試行をするのでそうしてはいけないなら、接続を知る前にパイプラインは永続的です。 また、対応する応答のすべてを送る前にサーバが接続を終えるなら、クライアントは彼らの要求を再送する用意ができていなければなりません。
8.1.3 Proxy Servers
8.1.3 Proxyサーバ
It is especially important that proxies correctly implement the properties of the Connection header field as specified in 14.2.1.
プロキシが指定されるように正しくConnectionヘッダーフィールドの特性を実装するのが、特に重要である、14.2、.1
The proxy server MUST signal persistent connections separately with its clients and the origin servers (or other proxy servers) that it connects to. Each persistent connection applies to only one transport link.
プロキシサーバは別々にそれが接するクライアントと発生源サーバ(または、他のプロキシサーバ)でパーシステントコネクションを示さなければなりません。 各パーシステントコネクションは1個の輸送リンクだけに適用されます。
A proxy server MUST NOT establish a persistent connection with an HTTP/1.0 client.
プロキシサーバはHTTP/1.0クライアントと共にパーシステントコネクションを確立してはいけません。
8.1.4 Practical Considerations
8.1.4 実用的な問題
Servers will usually have some time-out value beyond which they will no longer maintain an inactive connection. Proxy servers might make this a higher value since it is likely that the client will be making more connections through the same server. The use of persistent connections places no requirements on the length of this time-out for either the client or the server.
サーバには、通常、彼らがもう不活発な接続を維持しない何らかのタイムアウト価値があるでしょう。 Proxyサーバは、クライアントが同じサーバを通して、より多くの接続を作りそうであるので、これをより高い値にするかもしれません。パーシステントコネクションの使用はクライアントかサーバのどちらかのためにこのタイムアウトの長さに要件を全く置きません。
When a client or server wishes to time-out it SHOULD issue a graceful close on the transport connection. Clients and servers SHOULD both constantly watch for the other side of the transport close, and respond to it as appropriate. If a client or server does not detect the other side's close promptly it could cause unnecessary resource drain on the network.
クライアントかサーバが、それがSHOULDであることをタイムアウトに願っているときには、輸送接続のときに優雅な閉鎖を発行してください。 クライアントとSHOULDのサーバ両方が、近くで絶えず輸送の反対側を待ち兼ねて、適宜それに応じます。 クライアントかサーバが近くに即座に反対側のものを検出しないなら、それはネットワークで不要なリソースドレインを引き起こす場合がありました。
A client, server, or proxy MAY close the transport connection at any time. For example, a client MAY have started to send a new request at the same time that the server has decided to close the "idle" connection. From the server's point of view, the connection is being closed while it was idle, but from the client's point of view, a request is in progress.
クライアント、サーバ、またはプロキシがいつでも、輸送接続を終えるかもしれません。 例えば、クライアントはサーバが、「活動していません、な」接続を終えると決めたという同時にの新しい要求を送り始めたかもしれません。 サーバの観点から、それが活動していなかった間接続は閉店していますが、クライアントの観点から、要求は進行しています。
This means that clients, servers, and proxies MUST be able to recover from asynchronous close events. Client software SHOULD reopen the transport connection and retransmit the aborted request without user interaction so long as the request method is idempotent (see section
これは、クライアント、サーバ、およびプロキシが非同期な近いイベントから回復できなければならないことを意味します。 クライアントソフトウェアSHOULDが要求メソッドがベキ等元である限り、輸送接続を再開させて、ユーザ相互作用なしで中止になっている要求を再送する、(セクションを見てください。
Fielding, et. al. Standards Track [Page 45] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[45ページ]RFC2068HTTP/1997年1月1.1日
9.1.2); other methods MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request.
9.1.2); 自動的に他のメソッドを再試行してはいけません、ユーザエージェントは要求を再試行することの選択を人間のオペレータに提供するかもしれませんが。
However, this automatic retry SHOULD NOT be repeated if the second request fails.
しかしながら、2番目の要求が失敗するなら繰り返されて、このオートマチックはSHOULD NOTを再試行します。
Servers SHOULD always respond to at least one request per connection, if at all possible. Servers SHOULD NOT close a connection in the middle of transmitting a response, unless a network or client failure is suspected.
できれば、サーバSHOULDはいつも1接続あたり少なくとも1つの要求まで応じます。 サーバSHOULD NOTは応答を伝える中央で接続を終えます、ネットワークかクライアント失敗が疑われない場合。
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD maintain AT MOST 2 connections with any server or proxy. A proxy SHOULD use up to 2*N connections to another server or proxy, where N is the number of simultaneously active users. These guidelines are intended to improve HTTP response times and avoid congestion of the Internet or other networks.
パーシステントコネクションSHOULDを使用するクライアントが彼らが与えられたサーバに維持する同時接続の数を制限します。シングルユーザークライアントSHOULDは、AT MOSTがどんなサーバやプロキシとの2つの関係であることも支持します。 SHOULDがNが同時に活発なユーザの数であるところで別のサーバかプロキシに2つの*N接続まで使用するプロキシ。 これらのガイドラインは、HTTP応答回数を改良して、インターネットか他のネットワークの混雑を避けることを意図します。
8.2 Message Transmission Requirements
8.2 メッセージトランスミッション要件
General requirements:
一般要件:
o HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's flow control mechanisms to resolve temporary overloads, rather than terminating connections with the expectation that clients will retry. The latter technique can exacerbate network congestion.
o HTTP/1.1サーバSHOULDは、クライアントが再試行する期待との関係を終えるよりむしろ一時的なオーバーロードを決議するのにパーシステントコネクションを維持して、TCPのフロー制御メカニズムを使用します。 後者のテクニックはネットワークの混雑を悪化させることができます。
o An HTTP/1.1 (or later) client sending a message-body SHOULD monitor the network connection for an error status while it is transmitting the request. If the client sees an error status, it SHOULD immediately cease transmitting the body. If the body is being sent using a "chunked" encoding (section 3.6), a zero length chunk and empty footer MAY be used to prematurely mark the end of the message. If the body was preceded by a Content-Length header, the client MUST close the connection.
o それが要求を伝えている間にメッセージ本体SHOULDモニターにエラー状況のためのネットワーク接続を送るHTTP/1.1(後で)クライアント。 クライアントはエラー状況を見て、それはSHOULDです。すぐに、ボディーを伝えるのはやみます。 ボディーに"chunkedする"のコード化(セクション3.6)を使用させるなら、早まってメッセージの終わりを示すのにゼロ・レングス塊と空のフッターを使用するかもしれません。 ボディーがContent-長さのヘッダーによって先行されたなら、クライアントは接続を終えなければなりません。
o An HTTP/1.1 (or later) client MUST be prepared to accept a 100 (Continue) status followed by a regular response.
o HTTP/1.1(後で)クライアントは100(続けている)状態を受け入れて、続いて定期的な応答を受け入れる用意ができていなければなりません。
o An HTTP/1.1 (or later) server that receives a request from a HTTP/1.0 (or earlier) client MUST NOT transmit the 100 (continue) response; it SHOULD either wait for the request to be completed normally (thus avoiding an interrupted request) or close the connection prematurely.
o HTTP/1.0(より早くに)クライアントから要求を受け取るHTTP/1.1(後で)サーバは100(続けている)応答を伝えてはいけません。 それ、SHOULDは通常(その結果、中断している要求を避ける)、完成されるという要求を待っているか、または早まって、接続を終えます。
Fielding, et. al. Standards Track [Page 46] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[46ページ]RFC2068HTTP/1997年1月1.1日
Upon receiving a method subject to these requirements from an HTTP/1.1 (or later) client, an HTTP/1.1 (or later) server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with an error status. If it responds with an error status, it MAY close the transport (TCP) connection or it MAY continue to read and discard the rest of the request. It MUST NOT perform the requested method if it returns an error status.
HTTP/1.1(後で)クライアントからのこれらの要件を条件としてメソッドを受けると、HTTP/1.1(後で)サーバは、エラー状況で100(続けている)状態で応じて、入力ストリームから読み続けなければならないか、または反応しなければなりません。 エラー状況で応じるなら、輸送(TCP)接続を終えるかもしれないか、それは、要求の残りを読んで、捨て続けるかもしれません。 エラー状況を返すなら、それは要求されたメソッドを実行してはいけません。
Clients SHOULD remember the version number of at least the most recently used server; if an HTTP/1.1 client has seen an HTTP/1.1 or later response from the server, and it sees the connection close before receiving any status from the server, the client SHOULD retry the request without user interaction so long as the request method is idempotent (see section 9.1.2); other methods MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request.. If the client does retry the request, the client
クライアントSHOULDは、少なくとも大部分のバージョン番号が最近サーバを使用したのを覚えています。 HTTP/1.1クライアントがサーバからHTTP/1.1以降応答を見て、サーバからどんな状態も取る前に近くで接続を見るなら、クライアントSHOULDは要求メソッドがベキ等元(セクション9.1.2を見る)である限り、ユーザ相互作用なしで要求を再試行します。 自動的に他のメソッドを再試行してはいけません、ユーザエージェントは要求を再試行することの選択を人間のオペレータに提供するかもしれませんが。 クライアントが要求、クライアントを再試行するなら
o MUST first send the request header fields, and then
o 1番目はヘッダーフィールド、およびその時を要求に送らなければなりませんか?
o MUST wait for the server to respond with either a 100 (Continue)
response, in which case the client should continue, or with an
error status.
o クライアントがどのケースを続けるべきであるか、そして、またはエラー状況でサーバがどちらかで100(続けている)応答を反応させるのを待たなければなりません。
If an HTTP/1.1 client has not seen an HTTP/1.1 or later response from the server, it should assume that the server implements HTTP/1.0 or older and will not use the 100 (Continue) response. If in this case the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. If the client does retry the request to this HTTP/1.0 server, it should use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
HTTP/1.1クライアントがサーバからHTTP/1.1以降応答を見ていないなら、それは、サーバがHTTP/1.0以上を実装して、100(続けている)応答を使用しないと仮定するべきです。 サーバからどんな状態も取る前にクライアントがこの場合近くで接続を見るなら、クライアントSHOULDは要求を再試行します。 クライアントがこのHTTP/1.0サーバに要求を再試行するなら、信頼できる応答を得るのを保証されるのに以下の「2進の指数のbackoff」アルゴリズムを使用するべきです:
1. Initiate a new connection to the server
1. 新しい接続をサーバに開始してください。
2. Transmit the request-headers
2. 要求ヘッダーを伝えてください。
3. Initialize a variable R to the estimated round-trip time to the
server (e.g., based on the time it took to establish the
connection), or to a constant value of 5 seconds if the round-trip
time is not available.
3. およそ往復の時間まで変数Rをサーバに初期化してください。さもないと(例えば、始めた時間に基づいて、接続を確立してください)、5の恒常価値に、秒は往復の時間であるなら有効ではありません。
4. Compute T = R * (2**N), where N is the number of previous retries
of this request.
4. T=R*(2**N)を計算してください。そこでは、Nがこの要求の前の再試行の数です。
5. Wait either for an error response from the server, or for T seconds
(whichever comes first)
5. サーバからの誤り応答、またはT秒の間、待ってください。(一番になります)
Fielding, et. al. Standards Track [Page 47] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[47ページ]RFC2068HTTP/1997年1月1.1日
6. If no error response is received, after T seconds transmit the body
of the request.
6. T秒が要求のボディーを伝えた後にどんな誤り応答も受け取られていないなら。
7. If client sees that the connection is closed prematurely, repeat
from step 1 until the request is accepted, an error response is
received, or the user becomes impatient and terminates the retry
process.
7. クライアントが、接続が早まって閉店するのがわかるなら、ステップ1から、要求を受け入れて、誤り応答が受け取られているか、ユーザがせっかちになって、再試行プロセスを終えるまで、繰り返してください。
No matter what the server version, if an error status is received, the client
状態がサーババージョンが何であっても、誤りであるなら受け取られている、クライアント
o MUST NOT continue and
o そして続けてはいけない。
o MUST close the connection if it has not completed sending the
message.
o メッセージを送るのを完了していないなら、接続を終えなければなりません。
An HTTP/1.1 (or later) client that sees the connection close after receiving a 100 (Continue) but before receiving any other status SHOULD retry the request, and need not wait for 100 (Continue) response (but MAY do so if this simplifies the implementation).
100(続けている)を受け取った後にもかかわらず、いかなる他の状態SHOULD再試行も受ける前に接続が要求を終えるのを見て、100(続けている)応答(しかし、これが実装を簡素化するなら、そうするかもしれない)を待つ必要はないHTTP/1.1(後で)クライアント。
9 Method Definitions
9 メソッド定義
The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.
HTTP/1.1のための共通方法のセットは以下で定義されます。 このセットは膨張できますが、追加メソッドが別々に拡張しているクライアントとサーバのために同じ意味論を共有すると思うことができません。
The Host request-header field (section 14.23) MUST accompany all HTTP/1.1 requests.
Host要求ヘッダーフィールド(セクション14.23)はすべてのHTTP/1.1の要求に伴わなければなりません。
9.1 Safe and Idempotent Methods
9.1金庫とベキ等元メソッド
9.1.1 Safe Methods
9.1.1 確実な方法
Implementers should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others.
Implementersは、それらが取るどんな行動も意識している自分たちか他のものに予期していなかった意味を持っているかもしれないユーザを許容するためにソフトウェアにインターネットの上のそれらの相互作用でユーザの代理をして、注意しているべきであるのを意識しているべきです。
In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action other than retrieval. These methods should be considered "safe." This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
特に、GETとHEADメソッドが検索を除いて、訴訟を起こしながら意味を決して持つべきでないコンベンションは設立されました。 これらのメソッドは「安全である」と考えられるべきです。 これで、ユーザエージェントは他のメソッドを表すことができます、ポストや、PUTやDELETEなどのように、特別な方法で、ユーザをことによると危険な動きが要求されているという事実を知るようにするように。
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in
当然、サーバが、実行の結果、副作用がGET要求であると生成しないのを保証するのは可能ではありません。 コネ
Fielding, et. al. Standards Track [Page 48] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[48ページ]RFC2068HTTP/1997年1月1.1日
fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
事実、いくつかのダイナミックなリソースが、それが特徴であると考えます。 ここでの大切な区別はしたがって、副作用を要求しなかったのでそれらについて責任があるようにユーザを保つことができないということです。
9.1.2 Idempotent Methods
9.1.2 ベキ等元メソッド
Methods may also have the property of "idempotence" in that (aside from error or expiration issues) the side-effects of N > 0 identical requests is the same as for a single request. The methods GET, HEAD, PUT and DELETE share this property.
また、N>0の同じ要求の(誤りか満了問題は別として)副作用がただ一つの要求のように同じであるので、メソッドには"idempotence"の特性があるかもしれません。 メソッドのGET、HEAD、PUT、およびDELETEはこの特性を共有します。
9.2 OPTIONS
9.2 オプション
The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
OPTIONSメソッドはRequest-URIによって特定された要求/応答チェーンで利用可能なコミュニケーションオプションの情報に関する要求を表します。 クライアントはこのメソッドでオプション、そして/または、リソースに関連している要件、またはサーバの能力を決定できます、リソース動作を含意するか、またはリソース検索を開始しないで。
Unless the server's response is an error, the response MUST NOT include entity information other than what can be considered as communication options (e.g., Allow is appropriate, but Content-Type is not). Responses to this method are not cachable.
サーバの応答が誤りでないなら、応答はコミュニケーションオプションであるとみなすことができること以外の実体情報を含んではいけません(例えば、Allowが適切ですが、コンテントタイプは適切であるというわけではありません)。 このメソッドへの応答はキャッシュ可能ではありません。
If the Request-URI is an asterisk ("*"), the OPTIONS request is
intended to apply to the server as a whole. A 200 response SHOULD
include any header fields which indicate optional features
implemented by the server (e.g., Public), including any extensions
not defined by this specification, in addition to any applicable
general or response-header fields. As described in section 5.1.2, an
"OPTIONS *" request can be applied through a proxy by specifying the
destination server in the Request-URI without any path information.
Request-URIがアスタリスク(「*」)であるなら、オプション要求が全体でサーバに適用することを意図します。 応答SHOULDが含む200 この仕様でどんな適切な一般に加えて定義されなかった少しの拡大か応答ヘッダ分野も含むサーバ(例えば、Public)によって実装されたオプション機能を示すどんなヘッダーフィールド セクション5.1.2で説明されるように、プロキシを通して少しも経路情報なしで要求URIにおける目的地サーバを指定することによって、「オプション*」要求を適用できます。
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource. A 200 response SHOULD include any header fields which indicate optional features implemented by the server and applicable to that resource (e.g., Allow), including any extensions not defined by this specification, in addition to any applicable general or response-header fields. If the OPTIONS request passes through a proxy, the proxy MUST edit the response to exclude those options which apply to a proxy's capabilities and which are known to be unavailable through that proxy.
Request-URIがアスタリスクでないなら、OPTIONS要求はそのリソースで交信するとき利用可能なオプションだけに適用されます。 応答SHOULDが含む200 この仕様でどんな適切な一般に加えて定義されなかった少しの拡大か応答ヘッダ分野も含むそのリソース(例えば、Allow)にサーバで適切によって実装されたオプション機能を示すどんなヘッダーフィールド OPTIONS要求がプロキシを通り抜けるなら、プロキシは、プロキシの能力に申し込んで、そのプロキシを通して入手できないのが知られているそれらのオプションを除くために応答を編集しなければなりません。
Fielding, et. al. Standards Track [Page 49] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[49ページ]RFC2068HTTP/1997年1月1.1日
9.3 GET
9.3は得られます。
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
GETメソッドは、Request-URIによって特定されるどんな情報(実体の形の)も検索することを意味します。 Request-URIがデータを作り出すプロセスについて言及するなら、それはプロセスの原始テキストではなく、応答における実体として返されるものとする、生産されたデータです、そのテキストがたまたまプロセスの出力でないなら。
The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, or If-Range header field. A conditional GET method requests that the entity be transferred only under the circumstances described by the conditional header field(s). The conditional GET method is intended to reduce unnecessary network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring data already held by the client.
「条件付きのGET」へのGETメソッド変化の意味論は要求メッセージであるなら以来変更されたIfを含んでいます、以来変更されていないIf、If-マッチ、なにも合わせないIf、またはIf-範囲ヘッダーフィールド。 条件付きのGETメソッドは、実体が単に条件付きのヘッダーフィールドによって説明された状況で移されるよう要求します。 キャッシュされた実体が複数の要求を必要としないでリフレッシュされるのを許容することによって条件付きのGETメソッドが不要なネットワーク用法を減少させることを意図したか、またはデータを移すのは既にクライアントを固守しました。
The semantics of the GET method change to a "partial GET" if the request message includes a Range header field. A partial GET requests that only part of the entity be transferred, as described in section 14.36. The partial GET method is intended to reduce unnecessary network usage by allowing partially-retrieved entities to be completed without transferring data already held by the client.
「部分的なGET」へのGETメソッド変化の意味論は要求メッセージであるならRangeヘッダーフィールドを含んでいます。 部分的なGETは、セクション14.36で説明されるように実体の一部だけが移されるよう要求します。 部分的に検索された実体がクライアントによって既に保持されたデータを移さないで完成するのを許容することによって部分的なGETメソッドが不要なネットワーク用法を減少させることを意図します。
The response to a GET request is cachable if and only if it meets the requirements for HTTP caching described in section 13.
GET要求への応答がキャッシュ可能である、単に、それはセクション13で説明されたHTTPキャッシュのために条件を満たします。
9.4 HEAD
9.4 ヘッド
The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response. The metainformation contained in the HTTP headers in response to a HEAD request SHOULD be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the entity implied by the request without transferring the entity-body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
サーバが応答でメッセージ本体を返してはいけないのを除いて、HEADメソッドはGETと同じです。 HEADに対応してHTTPヘッダに含まれたmetainformationは、SHOULDがGET要求に対応して送られた情報と同じであるよう要求します。 要求で実体本体自体を移さないで含意された実体に関してmetainformationを入手するのにこのメソッドを使用できます。 このメソッドは、正当性、アクセシビリティ、および最近の変更がないかどうかハイパーテキストリンクをテストするのにしばしば使用されます。
The response to a HEAD request may be cachable in the sense that the information contained in the response may be used to update a previously cached entity from that resource. If the new field values indicate that the cached entity differs from the current entity (as would be indicated by a change in Content-Length, Content-MD5, ETag or Last-Modified), then the cache MUST treat the cache entry as stale.
HEAD要求への応答は応答に含まれた情報がそのリソースから以前にキャッシュされた実体をアップデートするのに使用されるかもしれないという意味でキャッシュ可能であるかもしれません。 新しい分野値が、キャッシュされた実体が現在の実体と異なっているのを示すなら(Content-長さ、Content-MD5、ETagまたは最終更新日における変化によって示されるように)、キャッシュは聞き古したキャッシュ同じくらいエントリーを扱わなければなりません。
Fielding, et. al. Standards Track [Page 50] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[50ページ]RFC2068HTTP/1997年1月1.1日
9.5 POST
9.5 ポスト
The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
ポストメソッドは、目的地サーバがリソースの新しい部下がRequest-線のRequest-URIで特定したように要求に同封された実体を受け入れるよう要求するのに使用されます。 ポストは以下の機能をカバーする一定のメソッドを許容するように設計されています:
o Annotation of existing resources;
o 既存のリソースの注釈。
o Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
o 記事の掲示板、ニュースグループ、メーリングリスト、または同様のグループにメッセージを掲示します。
o Providing a block of data, such as the result of submitting a
form, to a data-handling process;
o フォームを提出するという結果などのように、1ブロックのデータを提供して、データハンドリングに処理してください。
o Extending a database through an append operation.
o データベースを広げている、操作を追加してください。
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
ポストメソッドで実行された実際の関数は、サーバで決定して、通常、Request-URIに依存しています。 掲示された実体がそれを含むディレクトリに下位で同じようにファイルがそうであるそのURIを従属することである、ニュース記事がそれが掲示されるニュースグループに下位です、または記録はデータベースに下位です。
The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.
ポストメソッドで実行された動作はURIで特定できるリソースをもたらさないかもしれません。 この場合、どちらかの200(OK)か204(Contentがない)が適切な応答状態です、応答が結果について説明する実体を含んでいるかどうかによって。
If a resource has been created on the origin server, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header (see section 14.30).
発生源サーバでリソースを作成してあるなら、応答SHOULDは201歳(作成される)であり、要求の状態について説明して、新しいリソース、およびLocationヘッダーについて言及する実体を含んでいます(セクション14.30を見てください)。
Responses to this method are not cachable, unless the response includes appropriate Cache-Control or Expires header fields. However, the 303 (See Other) response can be used to direct the user agent to retrieve a cachable resource.
応答が適切なCache-コントロールかExpiresヘッダーフィールドを含んでいない場合、このメソッドへの応答はキャッシュ可能ではありません。 しかしながら、キャッシュ可能リソースを検索するようユーザエージェントに指示するのに303(Otherを見る)応答を使用できます。
POST requests must obey the message transmission requirements set out in section 8.2.
ポストの要求はセクション8.2を始められたメッセージトランスミッション要件に従わなければなりません。
Fielding, et. al. Standards Track [Page 51] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[51ページ]RFC2068HTTP/1997年1月1.1日
9.6 PUT
9.6 置かれました。
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity SHOULD be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI. If a new resource is created, the origin server MUST inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No Content) response codes SHOULD be sent to indicate successful completion of the request. If the resource could not be created or modified with the Request-URI, an appropriate error response SHOULD be given that reflects the nature of the problem. The recipient of the entity MUST NOT ignore any Content-* (e.g. Content-Range) headers that it does not understand or implement and MUST return a 501 (Not Implemented) response in such cases.
PUTメソッドは、同封の実体が供給されたRequest-URIの下で保存されるよう要求します。 Request-URIは既に既存のリソースを示します、同封の実体SHOULD。ものが発生源サーバにある変更されたバージョンであるとみなされてください。Request-URIが既存のリソースを示さないで、要求しているユーザエージェントが新しいリソースとそのURIが定義できるなら、発生源サーバはそのURIでリソースを作成できます。 新しいリソースが作成されるなら、発生源サーバは201(作成される)応答でユーザエージェントに知らせなければなりません。 既存のリソースが変更されているなら、200(OK)か204(Contentがない)応答のどちらかがSHOULDをコード化します。要求の無事終了を示すために、送ります。 それが自然を反映する当然のことが問題であるならRequest-URI、適切な誤り応答SHOULDと共にリソースを作成できないか、変更できないなら。 実体の受取人は、それが理解もしていませんし、実装もしないどんなContent-*(例えば、Content-範囲)ヘッダーも無視してはいけなくて、そのような場合501(Implementedでない)応答を返さなければなりません。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method are not cachable.
要求がキャッシュを通り抜けて、Request-URIが1つ以上の現在キャッシュされた実体を特定するなら、それらのエントリーは同じくらい聞き古したである扱われるべきです。 このメソッドへの応答はキャッシュ可能ではありません。
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server MUST NOT attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI, it MUST send a 301 (Moved Permanently) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
ポストとPUT要求の基本的な違いはRequest-URIの異なった意味に反映されます。 ポストの要求におけるURIは同封の実体を扱うリソースを特定します。 そのリソースは、データを受け入れるプロセス、ある他のプロトコルへのゲートウェイ、または注釈を受け入れる別々の実体であるかもしれません。 対照的に、PUT要求におけるURIは同封の実体を要求と同一視します--ユーザエージェントは、どんなURIが意図するかを知っています、そして、サーバはある他のリソースに要求を適用するのを試みてはいけません。 サーバが、要求が異なったURIに適用されることを望んでいるなら、301(Permanentlyを動かす)応答を送らなければなりません。 そして、ユーザエージェントは要求を向け直すかどうかに関するそれ自身の決定をするかもしれません。
A single resource MAY be identified by many different URIs. For example, an article may have a URI for identifying "the current version" which is separate from the URI identifying each particular version. In this case, a PUT request on a general URI may result in several other URIs being defined by the origin server.
ただ一つのリソースは多くの異なったURIによって特定されるかもしれません。 例えば、記事には、それぞれの特定のバージョンを特定するURIから別々の「最新版」を特定するためのURIがあるかもしれません。 この場合、一般的なURIに関するPUT要求は発生源サーバによって定義される他のいくつかのURIをもたらすかもしれません。
HTTP/1.1 does not define how a PUT method affects the state of an origin server.
HTTP/1.1はPUTメソッドがどう発生源サーバの事情に影響するかを定義しません。
PUT requests must obey the message transmission requirements set out in section 8.2.
PUT要求はセクション8.2を始められたメッセージトランスミッション要件に従わなければなりません。
Fielding, et. al. Standards Track [Page 52] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[52ページ]RFC2068HTTP/1997年1月1.1日
9.7 DELETE
9.7は削除します。
The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD not indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location.
DELETEメソッドは、発生源サーバがRequest-URIによって特定されたリソースを削除するよう要求します。 発生源サーバにおける人間の介入(または、他の手段)でこのメソッドはくつがえされるかもしれません。操作が行われたのをクライアントを保証できません、発生源サーバから返されたステータスコードが、操作が首尾よく完了したのを示しても。 しかしながら、リソースを削除しないつもりであるか、応答を与えるときそれを近づきがたい位置に動かさないつもりであるなら、サーバSHOULDは成功を示しません。
A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the response is OK but does not include an entity.
うまくいっている応答SHOULD、応答が動作がまだ制定されていないなら状態、202(受け入れる)について説明する実体を含んでいるか、そして、204(Contentがない)の200(OK)が応答であるならOKですが、実体を含んでいないということになってください。
If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries should be treated as stale. Responses to this method are not cachable.
要求がキャッシュを通り抜けて、Request-URIが1つ以上の現在キャッシュされた実体を特定するなら、それらのエントリーは同じくらい聞き古したである扱われるべきです。 このメソッドへの応答はキャッシュ可能ではありません。
9.8 TRACE
9.8 跡
The TRACE method is used to invoke a remote, application-layer loop- back of the request message. The final recipient of the request SHOULD reflect the message received back to the client as the entity-body of a 200 (OK) response. The final recipient is either the origin server or the first proxy or gateway to receive a Max-Forwards value of zero (0) in the request (see section 14.31). A TRACE request MUST NOT include an entity.
TRACEメソッドは、要求メッセージのリモート応用層輪を呼び出すのに使用されます。 SHOULDがメッセージを反映するという要求の最終的な受取人は200(OK)応答の実体本体としてクライアントに受信して戻りました。 最終的な受取人は、要求における、(0)がない前方へマックス値を受ける最初の発生源サーバかプロキシかゲートウェイ(セクション14.31を見る)のどちらかです。 TRACE要求は実体を含んではいけません。
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (section 14.44) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
TRACEはクライアントに要求チェーンのもう一方の端に受け取られているものを見て、テストか診断情報にそのデータを使用させます。 Viaヘッダーフィールド(セクション14.44)の値は特別におもしろいです、要求チェーンの跡として機能するので。 クライアントは前方へマックスヘッダーフィールドの使用で要求チェーンの長さを制限できます。(チェーンは無限ループにおけるメッセージを転送するプロキシのチェーンを検査することの役に立ちます)。
If successful, the response SHOULD contain the entire request message in the entity-body, with a Content-Type of "message/http". Responses to this method MUST NOT be cached.
うまくいくなら、応答SHOULDは実体本体に「メッセージ/http」のコンテントタイプで全体の要求メッセージを含んでいます。 このメソッドへの応答をキャッシュしてはいけません。
10 Status Code Definitions
10 ステータスコード定義
Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.
各Status-コードは以下で説明されます、それがどのメソッドに従うことができるかに関する記述と応答で必要であるmetainformationを含んでいて。
Fielding, et. al. Standards Track [Page 53] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[53ページ]RFC2068HTTP/1997年1月1.1日
10.1 Informational 1xx
10.1 情報の1xx
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. Since HTTP/1.0 did not define any 1xx status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client except under experimental conditions.
このクラスのステータスコードは、Status-線と任意のヘッダーだけから成って、暫定的な応答を示して、空の系列によって終えられます。 HTTP/1.0が少しの1xxステータスコードも定義しなかったので、実験条件以外に、サーバはHTTP/1.0クライアントに1xx応答を送ってはいけません。
10.1.1 100 Continue
10.1.1 100 続いてください。
The client may continue with its request. This interim response is used to inform the client that the initial part of the request has been received and has not yet been rejected by the server. The client SHOULD continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The server MUST send a final response after the request has been completed.
クライアントは要求を続行するかもしれません。 この当座の応答は、要求の初期の部分が受け取られて、サーバによってまだ拒絶されていないことをクライアントに知らせるのに使用されます。クライアントSHOULDは要求の残りを送ることによって続くか、または要求が既に終了されたなら、この応答を無視します。 要求が終了した後にサーバは最終的な応答を送らなければなりません。
10.1.2 101 Switching Protocols
10.1.2 101 切り換えプロトコル
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.41), for a change in the application protocol being used on this connection. The server will switch protocols to those defined by the response's Upgrade header field immediately after the empty line which terminates the 101 response.
サーバは、分かって、クライアントの要求に応じても構わないと思っています、Upgradeメッセージヘッダーフィールド(セクション14.41)で、この接続のときに使用されるアプリケーション・プロトコルにおける変化のために。 サーバは101応答を終える空の系列直後応答のUpgradeヘッダーフィールドによって定義されたものにプロトコルを切り換えるでしょう。
The protocol should only be switched when it is advantageous to do so. For example, switching to a newer version of HTTP is advantageous over older versions, and switching to a real-time, synchronous protocol may be advantageous when delivering resources that use such features.
そうするのが有利であるときにだけ、プロトコルは切り換えられるべきです。 例えば、HTTPの、より新しいバージョンに切り替わるのは旧式のバージョンの上で有利です、そして、そのような特徴を使用するリソースを提供するとき、リアルタイムで、同期のプロトコルに切り替わるのは有利であるかもしれません。
10.2 Successful 2xx
10.2 うまくいっている2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
このクラスのステータスコードは、クライアントの要求が首尾よく受け取られて、理解されて、受け入れられたのを示します。
10.2.1 200 OK
10.2.1 200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, for example:
要求は成功しました。 応答と共に返された情報は例えば要求で使用されるメソッドに依存しています:
GET an entity corresponding to the requested resource is sent in the
response;
要求されたリソースに対応する実体が応答で送られるGET。
HEAD the entity-header fields corresponding to the requested resource
are sent in the response without any message-body;
要求されたリソースに対応する実体ヘッダーフィールドが少しもメッセージ本体なしで応答で送られるHEAD。
Fielding, et. al. Standards Track [Page 54] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[54ページ]RFC2068HTTP/1997年1月1.1日
POST an entity describing or containing the result of the action;
ポスト、動作の結果を説明するか、または含む実体。
TRACE an entity containing the request message as received by the end
server.
TRACE、エンドサーバで受け取るように要求メッセージを含む実体。
10.2.2 201 Created
10.2.2 201 作成されています。
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URL for the resource given by a Location header field. The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server should respond with 202 (Accepted) response instead.
要求は、実現して作成される新しいリソースとなっています。 応答の実体で返されたURIで新たに作成されたリソースに参照をつけることができます、Locationヘッダーフィールドによって与えられたリソースのための最も特定のURLで。 201ステータスコードを返す前に、発生源サーバはリソースを作成しなければなりません。 すぐに動作を行うことができないなら、サーバは代わりに202(受け入れる)応答で反応するべきです。
10.2.3 202 Accepted
10.2.3 202 受け入れます。
The request has been accepted for processing, but the processing has not been completed. The request MAY or MAY NOT eventually be acted upon, as it MAY be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
処理のために要求を受け入れましたが、処理を終了していません。 処理が実際に行われるとき、それが禁じられるとき、要求は結局、実行されるかもしれません。 これなどの非同期動作からステータスコードを再送するための施設が全くありません。
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response SHOULD include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
202応答は故意にどっちつかずです。 目的は過程が完了するまでサーバとのユーザエージェントの接続が固執する必要でないサーバがある他のプロセス(恐らく1日に一度実行されるだけであるバッチ指向のプロセス)のために申し込みに応じるのを許容することです。 この応答SHOULDと共に返された実体は要求の現在の状態のしるしと状態モニターへの指針かユーザが実現するという要求を予想できる時に関する何らかの見積りのどちらかを含んでいます。
10.2.4 203 Non-Authoritative Information
10.2.4 203 非信頼できる情報
The returned metainformation in the entity-header is not the definitive set as available from the origin server, but is gathered from a local or a third-party copy. The set presented MAY be a subset or superset of the original version. For example, including local annotation information about the resource MAY result in a superset of the metainformation known by the origin server. Use of this response code is not required and is only appropriate when the response would otherwise be 200 (OK).
実体ヘッダーの返されたmetainformationは発生源サーバからの利用可能であるとしての決定的なセットではありませんが、ローカルか第三者コピーから集められます。 寄贈されたセットは、オリジナルバージョンの部分集合かスーパーセットであるかもしれません。 例えば、リソースの情報は発生源サーバによって知られていたmetainformationのスーパーセットをもたらします。そうでなければ、応答が200(OK)であるだろうというときにだけ、この応答コードの使用は、地方の注釈を含むかもしれなくて、必要でなく、適切です。
10.2.5 204 No Content
10.2.5 204 内容がありません。
The server has fulfilled the request but there is no new information to send back. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This
サーバは要求を実現させましたが、返送する新情報が全くありません。 クライアントはユーザエージェントであり、それはドキュメントが送られるという要求を引き起こしたそれから見るSHOULD NOT変化です。 これ
Fielding, et. al. Standards Track [Page 55] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[55ページ]RFC2068HTTP/1997年1月1.1日
response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view. The response MAY include new metainformation in the form of entity-headers, which SHOULD apply to the document currently in the user agent's active view.
主として、応答が動作がユーザエージェントの作業中の文書視点への変化を引き起こさないで行われるために入力を許すことを意図します。 応答は実体ヘッダーの形に新しいmetainformationを含むかもしれません。(SHOULDは現在ユーザエージェントのアクティブな意見でヘッダーをドキュメントに適用します)。
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
204応答は、メッセージ本体を含んではいけなくて、その結果、いつもヘッダーフィールドの後の最初の空の系列によって終えられます。
10.2.6 205 Reset Content
10.2.6 205 リセット内容
The server has fulfilled the request and the user agent SHOULD reset the document view which caused the request to be sent. This response is primarily intended to allow input for actions to take place via user input, followed by a clearing of the form in which the input is given so that the user can easily initiate another input action. The response MUST NOT include an entity.
サーバは要求を実現させました、そして、ユーザエージェントSHOULDは送られるという要求を引き起こしたドキュメント視点をリセットしました。 この応答が動作がユーザ入力で行われるために入力を許すことを主として意図します、ユーザが容易に別の入力動作を開始できるように入力が与えられている形式の開拓地があとに続いていて。 応答は実体を含んではいけません。
10.2.7 206 Partial Content
10.2.7 206 部分的な内容
The server has fulfilled the partial GET request for the resource. The request must have included a Range header field (section 14.36) indicating the desired range. The response MUST include either a Content-Range header field (section 14.17) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If multipart/byteranges is not used, the Content-Length header field in the response MUST match the actual number of OCTETs transmitted in the message-body.
サーバはリソースに関する部分的なGET要求を実現させました。 要求は、必要な範囲を示しながら、Rangeヘッダーフィールド(セクション14.36)を含んでいたに違いありません。 応答はこの応答で含まれていた範囲を示すContent-範囲ヘッダーフィールド(セクション14.17)か各部分へのContent-範囲分野を含む複合/byterangesコンテントタイプのどちらかを含まなければなりません。 複合/byterangesが使用されていないなら、応答におけるContent-長さのヘッダーフィールドはメッセージ本体で伝えられたOCTETsの実数に合わなければなりません。
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.
RangeとContent-範囲ヘッダーを支えないキャッシュは206の(部分的)の応答をキャッシュしてはいけません。
10.3 Redirection 3xx
10.3 リダイレクション3xx
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required MAY be carried out by the user agent without interaction with the user if and only if the method used in the second request is GET or HEAD. A user agent SHOULD NOT automatically redirect a request more than 5 times, since such redirections usually indicate an infinite loop.
このクラスのステータスコードは、さらなる動作が、要求を実現させるためにユーザエージェントによって取られる必要であるのを示します。 必要な行動がユーザとの相互作用なしでユーザエージェントによって行われるかもしれない、2番目の要求で中古のメソッドである場合にだけ、GETかHEADがそうです。 ユーザエージェントSHOULD NOTは自動的に5回以上の要求を向け直します、そのようなリダイレクションが通常無限ループを示すので。
Fielding, et. al. Standards Track [Page 56] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[56ページ]RFC2068HTTP/1997年1月1.1日
10.3.1 300 Multiple Choices
10.3.1 300 選択式
The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent- driven negotiation information (section 12) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that location.
要求されたリソースは1セットの代理と、それぞれそれ自身の特定の位置でいくらか1つに対応している、ユーザ(または、ユーザエージェント)が都合のよい表現を選択して、その位置に要求を向け直すことができるように、エージェント駆動交渉情報(セクション12)を提供しています。
Unless it was a HEAD request, the response SHOULD include an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content- Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice may be performed automatically. However, this specification does not define any standard for such automatic selection.
それがHEAD要求でなかったなら、応答SHOULDはリソースの特性のリストを含む実体とユーザかユーザエージェントが最も適切な状態でものを選ぶことができる位置を含んでいます。 実体形式はContentタイプヘッダーフィールドで与えた状態でメディアタイプによって指定されます。 ユーザエージェントの形式と能力によって、最も適切な選択の選択は自動的に実行されるかもしれません。 しかしながら、この仕様はそのような自動選択のどんな規格も定義しません。
If the server has a preferred choice of representation, it SHOULD include the specific URL for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cachable unless indicated otherwise.
サーバがそうしたなら、aは表現の選択を好んで、それはLocationのその表現のための特定のURLがさばくSHOULDインクルードです。 ユーザエージェントは自動リダイレクションにLocation分野価値を使用するかもしれません。 別の方法で示されない場合、この応答はキャッシュ可能です。
10.3.2 301 Moved Permanently
10.3.2 301 永久に、動きます。
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD be done using one of the returned URIs. Clients with link editing capabilities SHOULD automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cachable unless indicated otherwise.
された使用が返されたURIの1つであったなら新しい永久的なURIとこのリソースSHOULDのどんな後学も要求されたリソースに割り当ててあります。 連係編集能力SHOULDをもっているクライアントは自動的にサーバによって可能であるところに返された新しい参照の1つ以上にRequest-URIの参照を再リンクします。 別の方法で示されない場合、この応答はキャッシュ可能です。
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
新しいURIであるなら、中のLocation分野のそばの当然のことが応答であったなら、aは位置、そのURL SHOULDですか? メソッドがHEAD、応答SHOULDの実体であったという要求がハイパーリンクがある短いハイパーテキスト注意を新しいURIに含んでいないなら。
If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
GETかHEAD以外の要求に対応して301ステータスコードを受け取って、ユーザがそれを確認できないなら、ユーザエージェントは自動的に要求を向け直してはいけません、これが要求が出された状態を変えるかもしれないので。
Note: When automatically redirecting a POST request after receiving
a 301 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
以下に注意してください。 301ステータスコードを受け取った後に自動的にポストの要求を向け直すとき、何人かの既存のHTTP/1.0人のユーザエージェントが誤ってそれをGET要求に変えるでしょう。
Fielding, et. al. Standards Track [Page 57] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[57ページ]RFC2068HTTP/1997年1月1.1日
10.3.3 302 Moved Temporarily
10.3.3 302 一時動かされました。
The requested resource resides temporarily under a different URI. Since the redirection may be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cachable if indicated by a Cache-Control or Expires header field.
要求されたリソースは異なったURIの下で仮住まいします。 リダイレクションが時々変更されるかもしれないので、クライアントSHOULDは、今後の要求にRequest-URIを使用し続けています。 Cache-コントロールかExpiresヘッダーフィールドによって示される場合にだけ、この応答はキャッシュ可能です。
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
新しいURIであるなら、中のLocation分野のそばの当然のことが応答であったなら、aは位置、そのURL SHOULDですか? メソッドがHEAD、応答SHOULDの実体であったという要求がハイパーリンクがある短いハイパーテキスト注意を新しいURIに含んでいないなら。
If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
GETかHEAD以外の要求に対応して302ステータスコードを受け取って、ユーザがそれを確認できないなら、ユーザエージェントは自動的に要求を向け直してはいけません、これが要求が出された状態を変えるかもしれないので。
Note: When automatically redirecting a POST request after receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
以下に注意してください。 302ステータスコードを受け取った後に自動的にポストの要求を向け直すとき、何人かの既存のHTTP/1.0人のユーザエージェントが誤ってそれをGET要求に変えるでしょう。
10.3.4 303 See Other
10.3.4 303 別に見てください。
The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response is not cachable, but the response to the second (redirected) request MAY be cachable.
検索された使用がそのリソースに関するGETメソッドであったなら異なったURIとSHOULDの下で要求への応答を見つけることができます。 このメソッドは、主としてポスト活性のスクリプトの出力が選択されたリソースにユーザエージェントを向け直すのを許容するために存在しています。 新しいURIは元々要求されたリソースの代わりの参照ではありません。 303応答はキャッシュ可能ではありませんが、2番目の(向け直される)の要求への応答はキャッシュ可能であるかもしれません。
If the new URI is a location, its URL SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s).
新しいURIであるなら、中のLocation分野のそばの当然のことが応答であったなら、aは位置、そのURL SHOULDですか? メソッドがHEAD、応答SHOULDの実体であったという要求がハイパーリンクがある短いハイパーテキスト注意を新しいURIに含んでいないなら。
10.3.5 304 Not Modified
10.3.5 304 変更されていません。
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The response MUST NOT contain a message-body.
クライアントが条件付きのGET要求を実行して、アクセスが許されていますが、ドキュメントが変更されていないなら、サーバSHOULDはこのステータスコードで応じます。 応答はメッセージ本体を含んではいけません。
Fielding, et. al. Standards Track [Page 58] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[58ページ]RFC2068HTTP/1997年1月1.1日
The response MUST include the following header fields:
応答は以下のヘッダーフィールドを含まなければなりません:
o Date
o 日付
o ETag and/or Content-Location, if the header would have been sent in
a 200 response to the same request
o ETag、そして/または、Content-位置、同じ要求への200応答でヘッダーを送ったでしょう。
o Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same variant
o 期限が切れる、Cache-コントロール、そして/または、Vary、分野値が異なるかもしれないなら、それから、同じ異形のためのどんな前の応答も送られました。
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
条件付きのGETが強いキャッシュvalidatorを使用したなら(セクション13.3.3を見てください)、応答SHOULD NOTは他の実体ヘッダーを含んでいます。 さもなければ(すなわち、条件付きのGETは弱いvalidatorを使用した)、応答は他の実体ヘッダーを含んではいけません。 これはキャッシュされた実体本体とアップデートされたヘッダーの間の矛盾を防ぎます。
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
304応答が現在キャッシュされていない実体を示すなら、キャッシュは、応答を無視して、条件付きなしで要求を繰り返さなければなりません。
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
キャッシュがキャッシュエントリーをアップデートするのに容認された304応答を使用するなら、キャッシュは、応答で与えられたどんな新しい分野値も反映するためにエントリーをアップデートしなければなりません。
The 304 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
304応答は、メッセージ本体を含んではいけなくて、その結果、いつもヘッダーフィールドの後の最初の空の系列によって終えられます。
10.3.6 305 Use Proxy
10.3.6 305 プロキシを使用してください。
The requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URL of the proxy. The recipient is expected to repeat the request via the proxy.
Location分野によって与えられるプロキシを通して要求されたリソースにアクセスしなければなりません。 Location分野はプロキシのURLを与えます。 受取人がプロキシを通して要求を繰り返すと予想されます。
10.4 Client Error 4xx
10.4 クライアント誤り4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.
ステータスコードの4xxのクラスはクライアントが間違えたように思える場合のために意図します。 HEAD要求に応じる時を除いて、サーバSHOULDはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含む実体を含んでいます。 これらのステータスコードはどんな要求メソッドにも適切です。 ユーザエージェントSHOULDはどんな含まれている実体もユーザに表示します。
Note: If the client is sending data, a server implementation using
TCP should be careful to ensure that the client acknowledges
receipt of the packet(s) containing the response, before the server
closes the input connection. If the client continues sending data
to the server after the close, the server's TCP stack will send a
reset packet to the client, which may erase the client's
以下に注意してください。 クライアントがデータを送るなら、TCPを使用するサーバ実装は応答を含んで、クライアントがパケットの領収書を受け取ったことを知らせるのを保証するのに慎重であるはずです、サーバが入力接続を終える前に。 クライアントが、閉鎖の後にデータをサーバに送り続けていると、サーバのTCPスタックはリセットパケットをクライアントに送るでしょう。(そのクライアントは、クライアントのものを消すかもしれません)。
Fielding, et. al. Standards Track [Page 59] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[59ページ]RFC2068HTTP/1997年1月1.1日
unacknowledged input buffers before they can be read and
interpreted by the HTTP application.
HTTPアプリケーションでそれらを読んで、解釈できる前に不承認の入力はバッファリングします。
10.4.1 400 Bad Request
10.4.1 400 悪い要求
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
奇形の構文のためサーバに要求を解釈できませんでした。 クライアントSHOULD NOTは変更なしで要求を繰り返します。
10.4.2 401 Unauthorized
10.4.2 401 権限がありません。
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.46) containing a challenge applicable to the requested resource. The client MAY repeat the request with a suitable Authorization header field (section 14.8). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity MAY include relevant diagnostic information. HTTP access authentication is explained in section 11.
要求はユーザー認証を必要とします。 応答は包含しなければなりません。要求されたリソースに適切な挑戦を含んでいて、aはヘッダーフィールド(セクション14.46)をWWW認証します。 クライアントは適当なAuthorizationヘッダーフィールド(セクション14.8)で要求を繰り返すかもしれません。 要求が既にAuthorization資格証明書を含んだなら、401応答は、承認がそれらの資格証明書のために拒否されたのを示します。 その実体が含めるかもしれないので、401応答が先の応答と同じ挑戦を含んでいて、ユーザエージェントが少なくとも一度既に認証を試みたことがあるなら、応答で与えられた実体がユーザSHOULDに提示されて、関連診断情報を含めてください。 HTTPアクセス認証はセクション11で説明されます。
10.4.3 402 Payment Required
10.4.3 402 支払いが必要です。
This code is reserved for future use.
このコードは今後の使用のために予約されます。
10.4.4 403 Forbidden
10.4.4 403 禁制です。
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
サーバは、要求を理解していますが、それを実現させるのを拒否しています。 繰り返されて、承認は助けでなくて要求SHOULD NOTを望んでいます。 要求メソッドがHEADでなく、サーバが要求が実現していなくて、それがSHOULDである理由を公表したいなら、実体における拒否の理由について説明してください。 サーバが、要求がちょうどなぜ拒否されたか、そして、または他のどんな応答もいつ適切でないかを明らかにしたがっていないとき、このステータスコードは一般的に使用されます。
10.4.5 404 Not Found
10.4.5 404 見つけられませんでした。
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent.
サーバは、何もRequest-URIに合っているのがわかっていません。 状態が一時的であるか、または永久的であるかを指示を全く与えません。
Fielding, et. al. Standards Track [Page 60] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[60ページ]RFC2068HTTP/1997年1月1.1日
If the server does not wish to make this information available to the client, the status code 403 (Forbidden) can be used instead. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
この情報がサーバでクライアントにとって利用可能になりたいと思わないなら、代わりに、ステータスコード403(禁じられます)を使用できます。 410(行く)ステータスコードSHOULDはサーバが、何らかの内部的に構成可能なメカニズムを通して古いリソースが永久に入手できないのを知っているなら使用されて、フォーワーディング・アドレスを全く持っていません。
10.4.6 405 Method Not Allowed
10.4.6 405 許容されなかったメソッド
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
Request-線で指定されたメソッドはRequest-URIによって特定されたリソースのために許容されていません。 応答は要求されたリソースのための有効なメソッドのリストを含むAllowヘッダーを含まなければなりません。
10.4.7 406 Not Acceptable
10.4.7 406 許容できません。
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request.
要求で特定されたリソースが、応答が満足している特性を許容できるようにしない実体であると生成することができるだけである、要求で送られたヘッダーを受け入れてください。
Unless it was a HEAD request, the response SHOULD include an entity containing a list of available entity characteristics and location(s) from which the user or user agent can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice may be performed automatically. However, this specification does not define any standard for such automatic selection.
それがHEAD要求でなかったなら、応答SHOULDは利用可能な実体の特性のリストを含む実体とユーザかユーザエージェントが最も適切な状態でものを選ぶことができる位置を含んでいます。 実体形式はコンテントタイプヘッダーフィールドで与えた状態でメディアタイプによって指定されます。 ユーザエージェントの形式と能力によって、最も適切な選択の選択は自動的に実行されるかもしれません。 しかしながら、この仕様はそのような自動選択のどんな規格も定義しません。
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the request.
In some cases, this may even be preferable to sending a 406
response. User agents are encouraged to inspect the headers of an
incoming response to determine if it is acceptable. If the response
could be unacceptable, a user agent SHOULD temporarily stop receipt
of more data and query the user for a decision on further actions.
以下に注意してください。 HTTP/1.1のサーバが許容できない応答を返すことができる、要求で送られたヘッダーを受け入れてください。 いくつかの場合、これは406応答を送るより望ましくさえあるかもしれません。 ユーザエージェントがそれが許容できるかどうか決定するために入って来る応答のヘッダーを点検するよう奨励されます。 応答が容認できないかもしれないなら、ユーザエージェントSHOULDは一時より多くのデータの領収書を止めて、さらなる動作の決定のためにユーザについて質問します。
10.4.8 407 Proxy Authentication Required
10.4.8 407 プロキシ認証が必要です。
This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. The proxy MUST return a Proxy-Authenticate header field (section 14.33) containing a challenge applicable to the proxy for the requested resource. The client MAY repeat the request with a suitable Proxy-Authorization header field (section 14.34). HTTP access authentication is explained in section 11.
このコードは、401と同様ですが(権限のない)、クライアントが最初にプロキシと共にそれ自体を認証しなければならないのを示します。 プロキシはaを返さなければなりません。要求されたリソースに、プロキシに適切な挑戦を含んで、ヘッダーフィールド(セクション14.33)をProxy認証してください。 クライアントは適当なProxy-承認ヘッダーフィールド(セクション14.34)で要求を繰り返すかもしれません。 HTTPアクセス認証はセクション11で説明されます。
Fielding, et. al. Standards Track [Page 61] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[61ページ]RFC2068HTTP/1997年1月1.1日
10.4.9 408 Request Timeout
10.4.9 408 タイムアウトを要求してください。
The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
クライアントはサーバが待つように準備された時中に要求を作り出しませんでした。 クライアントは後の何時でも変更なしで要求を繰り返すかもしれません。
10.4.10 409 Conflict
10.4.10 409 闘争
The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request. The response body SHOULD include enough information for the user to recognize the source of the conflict. Ideally, the response entity would include enough information for the user or user agent to fix the problem; however, that may not be possible and is not required.
要求はリソースの現状との闘争のため終了できませんでした。 このコードはユーザが対立を解決して、要求を再提出できるかもしれないと予想される状況で許容されているだけです。 応答本体SHOULDはユーザが闘争の源を認めることができるくらいの情報を含んでいます。 理想的に、応答実体は問題をユーザかユーザエージェントが修正されることができるくらいの情報を含んでいるでしょう。 しかしながら、それは、可能でないかもしれなく、また必要ではありません。
Conflicts are most likely to occur in response to a PUT request. If versioning is being used and the entity being PUT includes changes to a resource which conflict with those made by an earlier (third-party) request, the server MAY use the 409 response to indicate that it can't complete the request. In this case, the response entity SHOULD contain a list of the differences between the two versions in a format defined by the response Content-Type.
闘争はPUT要求に対応して最も起こりそうです。 versioningが使用されていて、PUTである実体がそれらとの闘争が以前の(第三者)要求で作ったリソースへの変化を含んでいるなら、サーバは、要求を終了できないのを示すのに409応答を使用するかもしれません。 この場合、応答実体SHOULDは2つのバージョンの間に応答コンテントタイプによって定義された書式に違いのリストを含みます。
10.4.11 410 Gone
10.4.11 410 過ぎ去ります。
The requested resource is no longer available at the server and no forwarding address is known. This condition SHOULD be considered permanent. Clients with link editing capabilities SHOULD delete references to the Request-URI after user approval. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cachable unless indicated otherwise.
要求されたリソースはもうサーバで利用可能ではありません、そして、フォーワーディング・アドレスは全く知られていません。 永久的な状態で考えられて、これはSHOULDを条件とさせます。 連係編集能力SHOULDをもっているクライアントはユーザ承認の後にRequest-URIの参照を削除します。 サーバに、知らないか、または状態が永久的であるか否かに関係なく、ステータスコード404(Foundでない)SHOULDが代わりに使用されることを決定する施設が全くないなら。 別の方法で示されない場合、この応答はキャッシュ可能です。
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
主として、リソースが故意に入手できなく、サーバ所有者が、そのリソースへのリモートリンクが取り外されることを望んでいるように受取人に通知することによって410応答がウェブメインテナンスに関するタスクを補助することを意図します。 そのようなイベントは、サーバのサイトで働きながら、期間限定、プロモーション・サービスに共通、そして、リソースのためにもう個人に属します。 すべての永久に入手できないリソースが「過ぎ去る」とマークするか、またはどんな長さの時間にもマークを保つのは必要ではありません--すなわち、サーバ所有者の思慮深さにいなくなりました。
Fielding, et. al. Standards Track [Page 62] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[62ページ]RFC2068HTTP/1997年1月1.1日
10.4.12 411 Length Required
10.4.12 411 長さが必要です。
The server refuses to accept the request without a defined Content- Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message.
サーバは、定義されたContentの長さなしで要請を受け入れるのを拒否します。 要求メッセージのメッセージ本体の長さを含む有効なContent-長さのヘッダーフィールドを加えるなら、クライアントは要求を繰り返すかもしれません。
10.4.13 412 Precondition Failed
10.4.13 412 前提条件は失敗しました。
The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.
要求ヘッダーフィールドの1つ以上で与えられた前提条件は、それがいつサーバでテストされたかを誤っているのに評価しました。この応答コードで、クライアントを現在のリソースmetainformation(ヘッダーフィールド・データ)に前提条件を置いて、その結果、要求されたメソッドが意図するもの以外のリソースに適用されるのを防ぎます。
10.4.14 413 Request Entity Too Large
10.4.14 413 大き過ぎる状態で実体を要求してください。
The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server may close the connection to prevent the client from continuing the request.
サーバは、要求実体がサーバが望んでいるか、または処理できるより大きいので要求を処理するのを拒否しています。 サーバは、クライアントが要求を続けているのを防ぐために接続を終えるかもしれません。
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client may try again.
状態が一時的であるなら、サーバSHOULDは、ヘッダーフィールドの後にそれが一時的であることを示して、クライアントが再試行するかもしれない何時の後に含むようにRetryを含んでいるか。
10.4.15 414 Request-URI Too Long
10.4.15 414 要求URIも長さ
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long query information, when the client has descended into a URL "black hole" of redirection (e.g., a redirected URL prefix that points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present in some servers using fixed-length buffers for reading or manipulating the Request-URI.
サーバは、サーバが、解釈しても構わないと思っているよりRequest-URIが長いので要求を修理するのを拒否しています。 クライアントが長い質問情報で不適切にポストの要求をGET要求に変換したときだけ、このまれな状態は起こりそうです、クライアントが「ブラックホール」というリダイレクション(例えば、それ自体の接尾語を示す向け直されたURL接頭語)のURLの中に降りたか、またはサーバはRequest-URIを読むか、または操るのに固定長バッファを使用することでいくつかのサーバにおける現在のセキュリティーホールを利用するのを試みるクライアントによって攻撃されているとき。
10.4.16 415 Unsupported Media Type
10.4.16 415 サポートされないメディアタイプ
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
サーバは、要求されたメソッドのための要求されたリソースによってサポートされなかった形式には要求の実体があるので要求を修理するのを拒否しています。
Fielding, et. al. Standards Track [Page 63] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[63ページ]RFC2068HTTP/1997年1月1.1日
10.5 Server Error 5xx
10.5 サーバ誤り5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method.
応答状態はケタで、「5インチはサーバがそれが間違えたのを意識しているか、または要求を実行できない場合を示す」始めをコード化します。 HEAD要求に応じる時を除いて、サーバSHOULDはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含む実体を含んでいます。 ユーザエージェントSHOULDはどんな含まれている実体もユーザに表示します。 これらの応答コードはどんな要求メソッドにも適切です。
10.5.1 500 Internal Server Error
10.5.1 500 内部サーバーエラー
The server encountered an unexpected condition which prevented it from fulfilling the request.
サーバはそれが要求を実現させるのを防いだ予期していなかった状態に遭遇しました。
10.5.2 501 Not Implemented
10.5.2 501 実装されません。
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
サーバは要求を実現させるのに必要である機能性をサポートしません。 これは、サーバが要求メソッドを認識しないときの適切な応答であり、どんなリソースのためにもそれをサポートすることができません。
10.5.3 502 Bad Gateway
10.5.3 502 悪いゲートウェイ
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
サーバはゲートウェイかプロキシとして務めている間、要求を実現させるのを試みる際にそれがアクセスした上流のサーバから無効回答を受けました。
10.5.4 503 Service Unavailable
10.5.4 503 入手できないサービス
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay may be indicated in a Retry-After header. If no Retry-After is given, the client SHOULD handle the response as it would for a 500 response.
サーバは現在、サーバの一時的な積みすぎかメインテナンスのため要求を扱うことができません。含意はこれが少し遅れてから軽減される一時的な病態であるということです。 知られているなら、遅れの長さは後のRetryヘッダーで示されるかもしれません。 後のRetryを全く与えないなら、クライアントSHOULDは500応答のために扱うように応答を扱います。
Note: The existence of the 503 status code does not imply that a
server must use it when becoming overloaded. Some servers may wish
to simply refuse the connection.
以下に注意してください。 503ステータスコードの存在は、積みすぎられるようになるとき、サーバがそれを使用しなければならないのを含意しません。 いくつかのサーバが単に接続を拒否したがっているかもしれません。
10.5.5 504 Gateway Timeout
10.5.5 504 ゲートウェイタイムアウト
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server it accessed in attempting to complete the request.
サーバはゲートウェイかプロキシとして務めている間、要求を終了するのを試みる際にそれがアクセスした上流のサーバからタイムリーな応答を受けませんでした。
Fielding, et. al. Standards Track [Page 64] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[64ページ]RFC2068HTTP/1997年1月1.1日
10.5.6 505 HTTP Version Not Supported
10.5.6 505 バージョンがサポートしなかったHTTP
The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in section 3.1, other than with this error message. The response SHOULD contain an entity describing why that version is not supported and what other protocols are supported by that server.
サーバは、サポート、要求メッセージで使用されたHTTPプロトコルバージョンに、サポートもしませんし、拒否もしません。 サーバは、クライアントと同じ主要なバージョンを使用する要求を終了するのが不本意であることを示しています、セクション3.1で説明されるように、このエラーメッセージを除いて。 応答SHOULDはそのバージョンがなぜサポートされないか、そして、どんな他のプロトコルがそのサーバによってサポートされるかを説明する実体を、含んでいます。
11 Access Authentication
11 アクセス認証
HTTP provides a simple challenge-response authentication mechanism which MAY be used by a server to challenge a client request and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
HTTPは認証情報を提供するのにクライアント要求に挑戦するサーバとクライアントによって使用されるかもしれない簡単なチャレンジレスポンス認証メカニズムを提供します。 それは、その体系で認証を達成するのに必要なパラメタを運ぶ属性値組のコンマで切り離されたリストがあとに続いた認証体系を特定するのに広げることができて、大文字と小文字を区別しないトークンを使用します。
auth-scheme = token
auth-体系=トークン
auth-param = token "=" quoted-string
auth-paramはトークン「=」引用文字列と等しいです。
The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
401の(権限のない)の応答メッセージは発生源サーバによって使用されて、ユーザエージェントの承認に挑戦します。 この応答はaを含まなければなりません。要求されたリソースに適切な少なくとも1つの挑戦を含んで、ヘッダーフィールドをWWW認証してください。
challenge = auth-scheme 1*SP realm *( "," auth-param )
挑戦はauth-体系1*SP分野*と等しいです。(「」、auth-param)
realm = "realm" "=" realm-value
realm-value = quoted-string
分野=「分野」「=」分野価値の分野価値は引用文字列と等しいです。
The realm attribute (case-insensitive) is required for all authentication schemes which issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL (see section 5.1.2) of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme.
分野属性(大文字と小文字を区別しない)が挑戦を発行するすべての認証体系に必要です。 アクセスされるサーバの正準な根のURL(セクション5.1.2を見る)と組み合わせて、分野値(大文字と小文字を区別する)は保護スペースを定義します。 これらの分野は、サーバに関する保護されたリソースが1セットの保護空間に仕切られるのを許容します、それぞれそれ自身の認証体系、そして/または、承認データベースで。 分野値は追加意味論を認証体系に特定にするかもしれない一般に、発生源サーバによって割り当てられたストリングです。
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 or 411 response- -MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials
サーバでそれ自体を認証したがっているユーザエージェント--401か411応答5月を受けた後に、必ずない、しかし、通常、要求でAuthorizationヘッダーフィールドを含んでいることによって、そうしてください。 Authorization分野価値は資格証明書から成ります。
Fielding, et. al. Standards Track [Page 65] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[65ページ]RFC2068HTTP/1997年1月1.1日
containing the authentication information of the user agent for the realm of the resource being requested.
要求されているリソースの分野のユーザエージェントの認証情報を含んでいます。
credentials = basic-credentials
| auth-scheme #auth-param
資格証明書は基本的な資格証明書と等しいです。| auth-体系#auth-param
The domain over which credentials can be automatically applied by a user agent is determined by the protection space. If a prior request has been authorized, the same credentials MAY be reused for all other requests within that protection space for a period of time determined by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.
ユーザエージェントが自動的に資格証明書を適用できるドメインは保護スペースのそばで決定しています。 先の要求が認可されたなら、同じ資格証明書は他のすべての要求のためにしばらく認証体系で決定しているその保護スペース、パラメタ、そして/または、ユーザー選択の中で再利用されるかもしれません。 別の方法で認証体系によって定義されない場合、ただ一つの保護スペースはサーバの範囲の外で広がることができません。
If the server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing the (possibly new) challenge applicable to the requested resource and an entity explaining the refusal.
サーバが受け入れたくないなら、資格証明書は要求と共に発信して、それはSHOULDリターンa401(権限のない)応答です。 応答はaを含まなければなりません。要求されたリソースと拒否がわかる実体に適切な(ことによると新しい)の挑戦を含んで、ヘッダーフィールドをWWW認証してください。
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms MAY be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.
HTTPプロトコルはアクセス認証のためにアプリケーションをこの簡単なチャレンジレスポンスメカニズムに制限しません。 追加メカニズムは使用されるかもしれません、輸送レベルにおけるメッセージカプセル化を通して、追加ヘッダーフィールドが認証情報を指定している暗号化などのように。 しかしながら、これらの追加メカニズムはこの仕様で定義されません。
Proxies MUST be completely transparent regarding user agent authentication. That is, they MUST forward the WWW-Authenticate and Authorization headers untouched, and follow the rules found in section 14.8.
プロキシはユーザエージェント認証に関して完全に透明でなければなりません。 すなわち、前方にそうしなければならない、WWW認証、Authorizationヘッダー、触れなさ、セクション14.8で見つけられた規則に従ってください。
HTTP/1.1 allows a client to pass authentication information to and from a proxy via the Proxy-Authenticate and Proxy-Authorization headers.
を通してクライアントがHTTP/1.1でプロキシとプロキシから認証情報を通ることができる、Proxy認証、そして、Proxy-承認ヘッダー。
11.1 Basic Authentication Scheme
11.1 基本認証体系
The "basic" authentication scheme is based on the model that the user agent must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will service the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
「基本的な」認証体系はユーザIDと各分野のためのパスワードでそれ自体でユーザエージェントが認証しなければならないモデルに基づいています。 分野値は平等のためにそのサーバの他の分野にたとえることができるだけである不透明なストリングであると考えられるべきです。Request-URIの保護スペースのためのユーザIDとパスワードを有効にすることができる場合にだけ、サーバは要求を修理するでしょう。 どんな任意の認証パラメタもありません。
Fielding, et. al. Standards Track [Page 66] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[66ページ]RFC2068HTTP/1997年1月1.1日
Upon receipt of an unauthorized request for a URI within the protection space, the server MAY respond with a challenge like the following:
保護スペースの中のURIを求める権限のない要求を受け取り次第、サーバは以下のように挑戦で反応するかもしれません:
WWW-Authenticate: Basic realm="WallyWorld"
以下をWWW認証してください。 基本的な分野="WallyWorld"
where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI.
"WallyWorld"がサーバによって割り当てられた、Request-URIの保護スペースを特定したストリングであるところ。
To receive authorization, the client sends the userid and password,
separated by a single colon (":") character, within a base64 encoded
string in the credentials.
承認を受けるために、クライアントが1コロンによって切り離されたユーザIDとパスワードを送る、(「:」、)、キャラクタ、中では、base64が資格証明書でストリングをコード化しました。
basic-credentials = "Basic" SP basic-cookie
基本的な資格証明書は「基本的な」SP基本的なクッキーと等しいです。
basic-cookie = <base64 [7] encoding of user-pass,
except not limited to 76 char/line>
76炭/系列>に制限されないのを除いたユーザパスの基本的なクッキー=<base64[7]コード化
user-pass = userid ":" password
「ユーザパス=ユーザID」:、」 パスワード
userid = *<TEXT excluding ":">
「ユーザID=*<TEXT除外」: ">"
password = *TEXT
パスワード=*TEXT
Userids might be case sensitive.
ユーザIDは大文字と小文字を区別しているかもしれません。
If the user agent wishes to send the userid "Aladdin" and password "open sesame", it would use the following header field:
ユーザエージェントが「アラジン」をユーザIDに送りたくて、「開いている胡麻」をパスワードに送りたいなら、以下のヘッダーフィールドを使用するでしょう:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
承認: 基本的なQWxhZGRpbjpvcGVuIHNlc2FtZQ=
See section 15 for security considerations associated with Basic authentication.
Basic認証に関連しているセキュリティ問題に関してセクション15を見てください。
11.2 Digest Authentication Scheme
11.2 ダイジェスト認証体系
A digest authentication for HTTP is specified in RFC 2069 [32].
HTTPのためのダイジェスト認証はRFC2069[32]で指定されます。
12 Content Negotiation
12 満足している交渉
Most HTTP responses include an entity which contains information for interpretation by a human user. Naturally, it is desirable to supply the user with the "best available" entity corresponding to the request. Unfortunately for servers and caches, not all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the best representation for a given response
ほとんどのHTTP応答が人間のユーザによる解釈のために情報を含む実体を含んでいます。 当然、要求に対応する「最もよく利用可能な」実体をユーザに提供するのは望ましいです。 残念ながら、すべてのユーザには、サーバとキャッシュのために、中で「もの最も良い」であることのための同じ好みがあるというわけではありません、そして、すべてのユーザエージェントがどんな等しくすべての実体タイプを表すことができるというわけではありません。 その理由で、HTTPには、「満足している交渉」のための数個のメカニズムのための条項があります--、与えられた応答の最も良い表現を選択するプロセス
Fielding, et. al. Standards Track [Page 67] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[67ページ]RFC2068HTTP/1997年1月1.1日
when there are multiple representations available.
利用可能な複数の表現があるとき。
Note: This is not called "format negotiation" because the alternate
representations may be of the same media type, but use different
capabilities of that type, be in different languages, etc.
以下に注意してください。 同じメディアタイプには代替の表現があるかもしれないので、これは「形式交渉」と呼ばれませんが、そのタイプの異なった能力を使用してください、そして、異なった言語などにいてください。
Any response containing an entity-body MAY be subject to negotiation, including error responses.
実体本体を含むどんな応答も誤り応答を含む交渉を受けることがあるかもしれません。
There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server in order to provide server-driven negotiation for subsequent requests.
2種類のHTTPで可能な満足している交渉があります: サーバによる駆動の、そして、エージェント駆動の交渉。 これらの2種類の交渉は、直交していて、その結果、別々にか組み合わせに使用されるかもしれません。 キャッシュがその後の要求にサーバ駆動の交渉を提供するために発生源サーバによって提供されたエージェント駆動の交渉情報を使用すると、わかりやすい交渉と呼ばれた組み合わせの1つのメソッドが起こります。
12.1 Server-driven Negotiation
12.1 サーバ駆動の交渉
If the selection of the best representation for a response is made by an algorithm located at the server, it is called server-driven negotiation. Selection is based on the available representations of the response (the dimensions over which it can vary; e.g. language, content-coding, etc.) and the contents of particular header fields in the request message or on other information pertaining to the request (such as the network address of the client).
サーバで位置するアルゴリズムで応答の最も良い表現の選択をするなら、それをサーバ駆動の交渉と呼びます。 選択は、要求(クライアントのネットワーク・アドレスなどの)に関しながら、要求メッセージか他の情報の上で応答(それが異なることができる寸法; 例えば、言語の、そして、内容をコード化するなど)の利用可能な表現と特定のヘッダーフィールドのコンテンツに基づいています。
Server-driven negotiation is advantageous when the algorithm for selecting from among the available representations is difficult to describe to the user agent, or when the server desires to send its "best guess" to the client along with the first response (hoping to avoid the round-trip delay of a subsequent request if the "best guess" is good enough for the user). In order to improve the server's guess, the user agent MAY include request header fields (Accept, Accept-Language, Accept-Encoding, etc.) which describe its preferences for such a response.
利用可能な表現からの選択のためのアルゴリズムはユーザエージェントに説明するのが難しいか、またはサーバが、「最も良い推測」を最初の応答に伴うクライアントに送ることを望んでいるとき(ユーザには、「最も良い推測」が十分良いならその後の要求の往復の遅れを避けることを望んでいて)、サーバ駆動の交渉は有利です。 サーバの推測を改良するために、ユーザエージェントはそのような応答のための好みについて説明する要求ヘッダーフィールド(受け入れてください、Accept-言語、Acceptコード化していますなど)を入れるかもしれません。
Server-driven negotiation has disadvantages:
サーバ駆動の交渉には、損失があります:
1. It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?).
1. サーバが、何か与えられたユーザにとって、何が「最も良いかもしれないか」を正確に決定するのは、不可能です、それがユーザエージェントの両方の能力に関する完全な知識と応答の意図している使用を必要とするでしょう(例えば、ユーザは、スクリーンの上でそれを見たいですか、紙上でそれを印刷したがっていますか?)、したがって。
2. Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential violation of
2. ユーザエージェントにあらゆる要求における能力について説明させるのは、ともに非常に効率が悪くて(わずかな百分率の応答だけに複数の表現があるなら)、潜在的違反であるかもしれません。
Fielding, et. al. Standards Track [Page 68] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[68ページ]RFC2068HTTP/1997年1月1.1日
the user's privacy.
ユーザのプライバシー。
3. It complicates the implementation of an origin server and the algorithms for generating responses to a request.
3. それは発生源サーバの実装と要求への応答を生成するためのアルゴリズムを複雑にします。
4. It may limit a public cache's ability to use the same response for multiple user's requests.
4. それは複数のユーザの要求に同じ応答を使用する公共のキャッシュの能力を制限するかもしれません。
HTTP/1.1 includes the following request-header fields for enabling server-driven negotiation through description of user agent capabilities and user preferences: Accept (section 14.1), Accept- Charset (section 14.2), Accept-Encoding (section 14.3), Accept- Language (section 14.4), and User-Agent (section 14.42). However, an origin server is not limited to these dimensions and MAY vary the response based on any aspect of the request, including information outside the request-header fields or within extension header fields not defined by this specification.
HTTP/1.1はユーザエージェント能力とユーザー選択の記述でサーバ駆動の交渉を可能にするための以下の要求ヘッダーフィールドを含んでいます: (セクション14.1)を受け入れてください、そして、Charset(セクション14.2)を受け入れてください、そして、コード化を受け入れて(セクション14.3)、言語(セクション14.4)、およびユーザエージェント(セクション14.42)を受け入れてください。 しかしながら、発生源サーバは、これらの寸法に制限されないで、要求のどんな局面にも基づく応答を変えるかもしれません、要求ヘッダーフィールドの外、または、この仕様で定義されなかった拡大ヘッダーフィールドの中に情報を含んでいて。
HTTP/1.1 origin servers MUST include an appropriate Vary header field (section 14.43) in any cachable response based on server-driven negotiation. The Vary header field describes the dimensions over which the response might vary (i.e. the dimensions over which the origin server picks its "best guess" response from multiple representations).
HTTP/1.1の発生源サーバがサーバ駆動の交渉に基づくどんなキャッシュ可能応答にも適切なVaryヘッダーフィールド(セクション14.43)を含まなければなりません。 Varyヘッダーフィールドは応答が異なるかもしれない寸法(すなわち、発生源サーバが複数の表現から「最も良い推測」応答を選ぶ寸法)について説明します。
HTTP/1.1 public caches MUST recognize the Vary header field when it is included in a response and obey the requirements described in section 13.6 that describes the interactions between caching and content negotiation.
HTTP/1.1の公共のキャッシュが、それが応答に含まれているとき、Varyヘッダーフィールドを認識して、キャッシュしていて満足している交渉の間の相互作用について説明するセクション13.6で説明された要件に従わなければなりません。
12.2 Agent-driven Negotiation
12.2 エージェント駆動の交渉
With agent-driven negotiation, selection of the best representation for a response is performed by the user agent after receiving an initial response from the origin server. Selection is based on a list of the available representations of the response included within the header fields (this specification reserves the field-name Alternates, as described in appendix 19.6.2.1) or entity-body of the initial response, with each representation identified by its own URI. Selection from among the representations may be performed automatically (if the user agent is capable of doing so) or manually by the user selecting from a generated (possibly hypertext) menu.
エージェント駆動の交渉で、発生源サーバから初期の応答を受けた後に、応答の最も良い表現の選択はユーザエージェントによって実行されます。選択はヘッダーフィールドの中に応答を含む利用可能な表現のリストに基づいています。(この仕様がフィールド名Alternatesを予約する、付録で説明される、19.6、.2、.1、)、または、各表現がそれ自身のURIによって特定されている初期の応答の実体本体。 表現からの選択は発生している(ことによるとハイパーテキスト)メニューから選び抜くユーザによって自動的(ユーザエージェントがそうすることができるなら)か手動で実行されるかもしれません。
Agent-driven negotiation is advantageous when the response would vary over commonly-used dimensions (such as type, language, or encoding), when the origin server is unable to determine a user agent's capabilities from examining the request, and generally when public caches are used to distribute server load and reduce network usage.
応答が一般的に使用された寸法(タイプ、言語、またはコード化などの)の上異なるだろうというとき、エージェント駆動の交渉は有利です、要求を調べるのでユーザエージェントの能力を決定できて、公共のキャッシュがサーバ負荷を分配して、ネットワーク用法を減少させるのに使用されるとき発生源サーバが一般に決定できないとき。
Fielding, et. al. Standards Track [Page 69] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[69ページ]RFC2068HTTP/1997年1月1.1日
Agent-driven negotiation suffers from the disadvantage of needing a second request to obtain the best alternate representation. This second request is only efficient when caching is used. In addition, this specification does not define any mechanism for supporting automatic selection, though it also does not prevent any such mechanism from being developed as an extension and used within HTTP/1.1.
エージェント駆動の交渉は得るという中で代替の表現最も良い2番目の要求を必要とする不都合を被ります。 キャッシュが使用されているときだけ、この2番目の要求は効率的です。 さらに、この仕様は自動選択をサポートするためにどんなメカニズムも定義しません、また、どんなそのようなメカニズムも拡大として開発されて、HTTP/1.1の中で使用されるのを防ぎませんが。
HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable) status codes for enabling agent-driven negotiation when the server is unwilling or unable to provide a varying response using server-driven negotiation.
HTTP/1.1は、サーバが不本意であるか、またはサーバ駆動の交渉を使用することで異なった応答を提供できないときエージェント駆動の交渉を可能にするために300(複数のChoices)と406(Acceptableでない)のステータスコードを定義します。
12.3 Transparent Negotiation
12.3 わかりやすい交渉
Transparent negotiation is a combination of both server-driven and agent-driven negotiation. When a cache is supplied with a form of the list of available representations of the response (as in agent-driven negotiation) and the dimensions of variance are completely understood by the cache, then the cache becomes capable of performing server- driven negotiation on behalf of the origin server for subsequent requests on that resource.
わかりやすい交渉はサーバによる駆動の、そして、エージェント駆動の両方の交渉の組み合わせです。 応答の利用可能な表現のリストのフォームをキャッシュに供給して(エージェント駆動の交渉のように)、変化の次元をキャッシュに完全に解釈すると、キャッシュはそのリソースに関するその後の要求のための発生源サーバを代表してサーバ駆動交渉を実行できるようになります。
Transparent negotiation has the advantage of distributing the negotiation work that would otherwise be required of the origin server and also removing the second request delay of agent-driven negotiation when the cache is able to correctly guess the right response.
わかりやすい交渉で、そうでなければ発生源サーバが要求される交渉仕事を広げて、また、2番目を取り除く利点は、正しく正しい応答を推測するようキャッシュができるときのエージェント駆動の交渉の遅れに要求します。
This specification does not define any mechanism for transparent negotiation, though it also does not prevent any such mechanism from being developed as an extension and used within HTTP/1.1. An HTTP/1.1 cache performing transparent negotiation MUST include a Vary header field in the response (defining the dimensions of its variance) if it is cachable to ensure correct interoperation with all HTTP/1.1 clients. The agent-driven negotiation information supplied by the origin server SHOULD be included with the transparently negotiated response.
この仕様はわかりやすい交渉のためにどんなメカニズムも定義しません、また、どんなそのようなメカニズムも拡大として開発されて、HTTP/1.1の中で使用されるのを防ぎませんが。 すべてのHTTP/1.1人のクライアントと共に正しいinteroperationを確実にするのがキャッシュ可能であるなら、わかりやすい交渉を実行するHTTP/1.1キャッシュは応答(変化の次元を定義する)にVaryヘッダーフィールドを含まなければなりません。 含まれていて、情報が発生源サーバSHOULDから透過的に交渉された応答を供給したエージェント駆動の交渉。
13 Caching in HTTP
13 HTTPにおけるキャッシュ
HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the basic caching design of HTTP separately from the detailed descriptions of methods,
分配された情報システムにHTTPを通常使用します。そこでは、応答キャッシュの使用で性能を向上させることができます。 HTTP/1.1プロトコルはまた、仕事をキャッシュするのを可能にすることを意図する多くの要素を含んでいます。 これらの要素がプロトコルの他の局面から解決できなく、互いに対話するので、別々にメソッドの詳述からHTTPの基本的なキャッシュデザインについて説明するのは役に立ちます。
Fielding, et. al. Standards Track [Page 70] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[70ページ]RFC2068HTTP/1997年1月1.1日
headers, response codes, etc.
ヘッダー、応答コードなど
Caching would be useless if it did not significantly improve performance. The goal of caching in HTTP/1.1 is to eliminate the need to send requests in many cases, and to eliminate the need to send full responses in many other cases. The former reduces the number of network round-trips required for many operations; we use an "expiration" mechanism for this purpose (see section 13.2). The latter reduces network bandwidth requirements; we use a "validation" mechanism for this purpose (see section 13.3).
性能をかなり向上させないなら、キャッシュは役に立たないでしょうに。 HTTP/1.1におけるキャッシュの目標は多くの場合、要求を送って、他の多くの場合における完全な応答を送る必要性を排除する必要性をなくします。 前者は周遊旅行が多くの操作のために必要としたネットワークの数を減少させます。 私たちはこのために「満了」メカニズムを使用します(セクション13.2を見てください)。 後者はネットワーク帯域幅要件を減らします。 私たちはこのために「合法化」メカニズムを使用します(セクション13.3を見てください)。
Requirements for performance, availability, and disconnected operation require us to be able to relax the goal of semantic transparency. The HTTP/1.1 protocol allows origin servers, caches, and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and may be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed
性能、有用性、および切断している操作のための要件は、私たちが意味の透明性の目標を弛緩できるのを必要とします。 必要であるときに、HTTP/1.1プロトコルで、発生源サーバ、キャッシュ、およびクライアントは透明を明らかに減少させることができます。 しかしながら、非透過の操作が非の専門家のユーザを混乱させるかもしれなくて、あるサーバ・アプリケーション(商品を注文するためのそれらなどの)と両立しないかもしれないので、プロトコルは、透明がリラックスするのを必要とします。
o only by an explicit protocol-level request when relaxed by client
or origin server
o 単に明白なプロトコルレベル要求で、いつがクライアントか発生源サーバでリラックスしましたか?
o only with an explicit warning to the end user when relaxed by cache
or client
o 単にいつがキャッシュかクライアントでリラックスしたかというエンドユーザへの明白な警告で
Fielding, et. al. Standards Track [Page 71] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[71ページ]RFC2068HTTP/1997年1月1.1日
Therefore, the HTTP/1.1 protocol provides these important elements:
したがって、HTTP/1.1プロトコルはこれらの重要な要素を提供します:
1. Protocol features that provide full semantic transparency when this
is required by all parties.
1. これがすべてのパーティーによって必要とされるとき完全な意味の透明性を提供する特徴について議定書の中で述べてください。
2. Protocol features that allow an origin server or user agent to
explicitly request and control non-transparent operation.
2. 発生源サーバかユーザエージェントが明らかに非透過の操作を要求して、制御する特徴について、議定書の中で述べてください。
3. Protocol features that allow a cache to attach warnings to
responses that do not preserve the requested approximation of
semantic transparency.
3. キャッシュが意味の透明性の要求された近似を保存しない応答に警告を添付できる特徴について議定書の中で述べてください。
A basic principle is that it must be possible for the clients to detect any potential relaxation of semantic transparency.
基本原理はクライアントが意味の透明性のどんな潜在的緩和も検出するのが、可能であるに違いないということです。
Note: The server, cache, or client implementer may be faced with
design decisions not explicitly discussed in this specification. If
a decision may affect semantic transparency, the implementer ought
to err on the side of maintaining transparency unless a careful and
complete analysis shows significant benefits in breaking
transparency.
以下に注意してください。 サーバ、キャッシュ、またはクライアントimplementerはこの仕様で明らかに議論しないデザイン決定に直面するかもしれません。 決定が意味の透明性に影響するかもしれなくて、慎重で完全な分析が壊れている透明における重要な利益を示さない場合、implementerは維持透明の側で間違えるべきです。
13.1.1 Cache Correctness
13.1.1 キャッシュの正当性
A correct cache MUST respond to a request with the most up-to-date response held by the cache that is appropriate to the request (see sections 13.2.5, 13.2.6, and 13.12) which meets one of the following conditions:
そして、最も最新の応答が要求に適切なキャッシュによって保持されている状態で正しいキャッシュが要求に応じなければならない、(見る、セクション13.2 .5 13.2 .6、13.12) 以下の条件のどの大会1:
1. It has been checked for equivalence with what the origin server
would have returned by revalidating the response with the origin
server (section 13.3);
1. それは等価性がないかどうか発生源サーバが発生源サーバ(セクション13.3)で応答を再有効にすることによって返したものに問い合わせられました。
2. It is "fresh enough" (see section 13.2). In the default case, this
means it meets the least restrictive freshness requirement of the
client, server, and cache (see section 14.9); if the origin server
so specifies, it is the freshness requirement of the origin server
alone.
2. それは「十分新鮮である」(セクション13.2を見てください)。 不履行格では、これは、クライアント、サーバ、およびキャッシュの最も制限していない新しさ必要条件を満たすことを(セクション14.9を見てください)意味します。 したがって、発生源サーバが指定するなら、唯一のそれは発生源サーバの新しさ要件です。
3. It includes a warning if the freshness demand of the client or the
origin server is violated (see section 13.1.5 and 14.45).
3. クライアントの新しさ要求か発生源サーバが違反されるなら(セクション13.1 .5と14.45を見てください)、それは警告を含んでいます。
4. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or
error (4xx or 5xx) response message.
4. それは適切な304(Modifiedでない)、305(プロキシRedirect)、または誤り(4xxか5xx)応答メッセージです。
If the cache can not communicate with the origin server, then a correct cache SHOULD respond as above if the response can be correctly served from the cache; if not it MUST return an error or
キャッシュが起源サーバとコミュニケートできないなら、キャッシュからSHOULDが応答であるなら同じくらい上で反応させる正しいキャッシュに正しく、役立つことができます。 またはそうでなければ、誤りを返さなければならない。
Fielding, et. al. Standards Track [Page 72] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[72ページ]RFC2068HTTP/1997年1月1.1日
warning indicating that there was a communication failure.
そこでそれを示した警告は通信障害でした。
If a cache receives a response (either an entire response, or a 304 (Not Modified) response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache SHOULD forward it to the requesting client without adding a new Warning (but without removing any existing Warning headers). A cache SHOULD NOT attempt to revalidate a response simply because that response became stale in transit; this might lead to an infinite loop. An user agent that receives a stale response without a Warning MAY display a warning indication to the user.
キャッシュが通常、それが要求しているクライアントに送る応答(全体の応答か304(Modifiedでない)応答のどちらか)を受けて、容認された応答がもう新鮮でないなら、新しいWarning(しかしどんな既存のWarningヘッダーも取り除かないで)を加えないで、キャッシュSHOULDは要求しているクライアントにそれを送ります。 単にその応答がトランジットで聞き古したであるなったので、キャッシュSHOULD NOTはrevalidateに応答を試みます。 これは無限ループに通じるかもしれません。 Warningなしで聞き古した応答を受けるユーザエージェントは警告指示をユーザに表示するかもしれません。
13.1.2 Warnings
13.1.2 警告
Whenever a cache returns a response that is neither first-hand nor "fresh enough" (in the sense of condition 2 in section 13.1.1), it must attach a warning to that effect, using a Warning response- header. This warning allows clients to take appropriate action.
キャッシュが応答を返すときはいつも、それは、直でなくて、また「十分生々しさ」(セクション13.1.1における状態2の意味で)、その趣旨で警告を添付しなければならなくて、Warning応答を使用してヘッダーではありません。 この警告で、クライアントは適切な行動を取ることができます。
Warnings may be used for other purposes, both cache-related and otherwise. The use of a warning, rather than an error status code, distinguish these responses from true failures.
警告は、他の目的のために中古で、かつキャッシュ関連で、かつそうでないかもしれません。 警告の使用は本当の失敗とこれらの応答を誤りステータスコードよりむしろ区別します。
Warnings are always cachable, because they never weaken the transparency of a response. This means that warnings can be passed to HTTP/1.0 caches without danger; such caches will simply pass the warning along as an entity-header in the response.
応答の透明を決して弱めないので、警告はいつもキャッシュ可能です。 これは、危険なしでHTTP/1.0のキャッシュに警告を通過できることを意味します。 そのようなキャッシュは実体ヘッダーとして応答で単に警告を伝えるでしょう。
Warnings are assigned numbers between 0 and 99. This specification defines the code numbers and meanings of each currently assigned warnings, allowing a client or cache to take automated action in some (but not all) cases.
警告は0〜99の規定番号です。 この仕様は警告が現在割り当てられているそれぞれのコード番号と意味を定義します、クライアントかキャッシュがいくつかの(すべてでない)場合における自動化された行動を取るのを許容して。
Warnings also carry a warning text. The text may be in any appropriate natural language (perhaps based on the client's Accept headers), and include an optional indication of what character set is used.
また、警告は警告テキストを運びます。 テキストは、どんな適切な自然言語(恐らく、クライアントのAcceptヘッダーに基づいている)にもあって、どんな文字の組が使用されているかの任意のしるしを含むかもしれません。
Multiple warnings may be attached to a response (either by the origin server or by a cache), including multiple warnings with the same code number. For example, a server may provide the same warning with texts in both English and Basque.
複数の警告が応答(起源サーバかキャッシュによる)に添付されるかもしれません、同じコード番号がある複数の警告を含んでいて。 例えば、サーバはイギリス人とバスク人の両方で同じ警告にテキストを提供するかもしれません。
When multiple warnings are attached to a response, it may not be practical or reasonable to display all of them to the user. This version of HTTP does not specify strict priority rules for deciding which warnings to display and in what order, but does suggest some heuristics.
複数の警告が応答に添付されるとき、それらを皆、ユーザに表示するのは、実用的であるか、または妥当でないかもしれません。 HTTPのこのバージョンは表示するというどの警告について決めるか、そして、命令しますが、いくつかの発見的教授法を示すことにおける厳しい優先権規則を指定しません。
Fielding, et. al. Standards Track [Page 73] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[73ページ]RFC2068HTTP/1997年1月1.1日
The Warning header and the currently defined warnings are described in section 14.45.
Warningヘッダーと現在定義された警告はセクション14.45で説明されます。
13.1.3 Cache-control Mechanisms
13.1.3 キャッシュ制御メカニズム
The basic cache mechanisms in HTTP/1.1 (server-specified expiration times and validators) are implicit directives to caches. In some cases, a server or client may need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose.
HTTP/1.1(サーバで指定された満了の回とvalidators)における基本的なキャッシュメカニズムはキャッシュへの暗黙の指示です。 いくつかの場合、サーバかクライアントが、明白な指示をHTTPキャッシュに提供する必要があるかもしれません。 私たちはこのためにCache-コントロールヘッダーを使用します。
The Cache-Control header allows a client or server to transmit a variety of directives in either requests or responses. These directives typically override the default caching algorithms. As a general rule, if there is any apparent conflict between header values, the most restrictive interpretation should be applied (that is, the one that is most likely to preserve semantic transparency). However, in some cases, Cache-Control directives are explicitly specified as weakening the approximation of semantic transparency (for example, "max-stale" or "public").
Cache-コントロールヘッダーはクライアントかサーバに要求か応答のどちらかにおけるさまざまな指示を伝えさせます。 これらの指示はアルゴリズムをキャッシュするデフォルトを通常くつがえします。ヘッダー値の間には、何か明らかな矛盾があれば、概して、最も制限している解釈は適用されるべきです(すなわち、意味の透明性を最も保存しそうなもの)。 しかしながら、いくつかの場合、Cache-コントロール指示は意味の透明性(例えば、「最大に古くさくなってください」か「公衆」)の近似を弱めると明らかに指定されます。
The Cache-Control directives are described in detail in section 14.9.
Cache-コントロール指示はセクション14.9で詳細に説明されます。
13.1.4 Explicit User Agent Warnings
13.1.4 明白なユーザエージェント警告
Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent may allow the user to specify that cached entities (even explicitly stale ones) are never validated. Or the user agent might habitually add "Cache-Control: max-stale=3600" to every request. The user should have to explicitly request either non-transparent behavior, or behavior that results in abnormally ineffective caching.
多くのユーザエージェントがユーザが基本的なキャッシュメカニズムをくつがえすのを可能にします。例えば、ユーザエージェントは、ユーザが、キャッシュされた実体(明らかに聞き古したものさえ)が決して有効にされないと指定するのを許すかもしれません。 または、「キャッシュで制御してください。」と、ユーザエージェントは習慣的に言い足すかもしれません。 あらゆる要求への「最大聞き古した=3600。」 ユーザは明らかに異常に効果がないキャッシュをもたらす非透過の振舞いか振舞いのどちらかを要求しなければならないはずです。
If the user has overridden the basic caching mechanisms, the user agent should explicitly indicate to the user whenever this results in the display of information that might not meet the server's transparency requirements (in particular, if the displayed entity is known to be stale). Since the protocol normally allows the user agent to determine if responses are stale or not, this indication need only be displayed when this actually happens. The indication need not be a dialog box; it could be an icon (for example, a picture of a rotting fish) or some other visual indicator.
ユーザが基本的なキャッシュメカニズムをくつがえしたなら、ユーザエージェントは、これが情報表示をもたらすときはいつも、それがサーバの透明必要条件を満たさないかもしれないのを(表示された実体が聞き古したである特に知られているなら)明らかにユーザに示すべきです。 ユーザエージェントが、プロトコルで応答が聞き古したであるかどうか通常決心できるので、これが実際に起こるとき、この指示を表示するだけでよいです。 指示はダイアログボックスである必要はありません。 それは、アイコン(例えば、腐った魚の絵)かある他の視覚インディケータであるかもしれません。
If the user has overridden the caching mechanisms in a way that would abnormally reduce the effectiveness of caches, the user agent should continually display an indication (for example, a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency.
ユーザがキャッシュの有効性を異常に減少させる方法でキャッシュメカニズムをくつがえしたなら、ユーザエージェントが絶えず指示(例えば、炎の中の通貨の絵)を表示するべきであるので、ユーザは、うっかり余分なリソースを消費もしませんし、過度の潜在に悩みもしません。
Fielding, et. al. Standards Track [Page 74] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[74ページ]RFC2068HTTP/1997年1月1.1日
13.1.5 Exceptions to the Rules and Warnings
13.1.5 規則と警告への例外
In some cases, the operator of a cache may choose to configure it to return stale responses even when not requested by clients. This decision should not be made lightly, but may be necessary for reasons of availability or performance, especially when the cache is poorly connected to the origin server. Whenever a cache returns a stale response, it MUST mark it as such (using a Warning header). This allows the client software to alert the user that there may be a potential problem.
いくつかの場合、クライアントによって要求されないと、キャッシュのオペレータは、聞き古した応答を返すためにそれを構成するのを選ぶかもしれません。 この決定が、軽く作るべきではありませんが、有用性か性能の理由に必要であるかもしれません、特にキャッシュが起源サーバに不十分に接続されるとき。キャッシュが聞き古した応答を返すときはいつも、それはそういうものとしてそれをマークしなければなりません(Warningヘッダーを使用して)。 これで、クライアントソフトウェアは、潜在的な問題があるかもしれないとユーザに警告できます。
It also allows the user agent to take steps to obtain a first-hand or fresh response. For this reason, a cache SHOULD NOT return a stale response if the client explicitly requests a first-hand or fresh one, unless it is impossible to comply for technical or policy reasons.
また、それで、ユーザエージェントは、直の、または、新鮮な応答を得るために手を打つことができます。 この理由で、SHOULD NOTがクライアントであるなら明らかに聞き古した応答を返すキャッシュは直の、または、新鮮なものを要求します、技術的であるか方針理由で応じるのが不可能でない場合。
13.1.6 Client-controlled Behavior
13.1.6 クライアントによって制御された振舞い
While the origin server (and to a lesser extent, intermediate caches, by their contribution to the age of a response) are the primary source of expiration information, in some cases the client may need to control a cache's decision about whether to return a cached response without validating it. Clients do this using several directives of the Cache-Control header.
起源サーバ(そして、ある程度応答の時代への彼らの貢献による中間的キャッシュ)は満了情報の一次資料ですが、いくつかの場合、クライアントは、それを有効にしないでキャッシュされた応答を返すかどうかに関するキャッシュの決定を制御する必要があるかもしれません。 クライアントは、Cache-コントロールヘッダーのいくつかの指示を使用することでこれをします。
A client's request may specify the maximum age it is willing to accept of an unvalidated response; specifying a value of zero forces the cache(s) to revalidate all responses. A client may also specify the minimum time remaining before a response expires. Both of these options increase constraints on the behavior of caches, and so cannot further relax the cache's approximation of semantic transparency.
クライアントの要求はそれが受け入れても構わないと思っている非有効にされた応答の最大の時代を指定するかもしれません。 ゼロの値を指定するので、キャッシュはやむを得ずすべての応答を再有効にします。 また、クライアントは、応答が期限が切れる前に残りながら、最小の時間を指定するかもしれません。 これらのオプションの両方が、キャッシュの振舞いのときに規制を増加させるので、さらにキャッシュの意味の透明性の近似を弛緩できません。
A client may also specify that it will accept stale responses, up to some maximum amount of staleness. This loosens the constraints on the caches, and so may violate the origin server's specified constraints on semantic transparency, but may be necessary to support disconnected operation, or high availability in the face of poor connectivity.
また、クライアントは、聞き古した応答をいくらかの最大の量の腐敗まで受け入れると指定するかもしれません。 不十分な接続性に直面して外された操作、または高い有用性を支持するのに必要であるかもしれないのを除いて、これは、キャッシュで規制を緩めるので、意味の透明性で起源サーバの指定された規制に違反するかもしれません。
13.2 Expiration Model
13.2 満了モデル
13.2.1 Server-Specified Expiration
13.2.1 サーバで指定された満了
HTTP caching works best when caches can entirely avoid making requests to the origin server. The primary mechanism for avoiding requests is for an origin server to provide an explicit expiration time in the future, indicating that a response may be used to satisfy subsequent requests. In other words, a cache can return a fresh
キャッシュが、要求を起源サーバにするのを完全に避けることができるとき、HTTPキャッシュはうまくいきます。要求を避けるための一次機構は起源サーバが将来明白な満了時間を提供することです、応答がその後の要求を満たすのに使用されるかもしれないのを示して。 言い換えれば、キャッシュは新たにaを返すことができます。
Fielding, et. al. Standards Track [Page 75] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[75ページ]RFC2068HTTP/1997年1月1.1日
response without first contacting the server.
最初にサーバに連絡することのない応答。
Our expectation is that servers will assign future explicit expiration times to responses in the belief that the entity is not likely to change, in a semantically significant way, before the expiration time is reached. This normally preserves semantic transparency, as long as the server's expiration times are carefully chosen.
私たちの期待はサーバが実体が変化しそうにないという信念における応答に将来の明白な満了時間を割り当てるということです、意味的に重要な方法で、満了時間に達する前に。 サーバの満了時代が慎重に選ばれている限り、通常、これは意味の透明性を保存します。
The expiration mechanism applies only to responses taken from a cache and not to first-hand responses forwarded immediately to the requesting client.
満了メカニズムはすぐに進められた直の応答ではなく、キャッシュから要求しているクライアントまで取られた応答だけに適用されます。
If an origin server wishes to force a semantically transparent cache to validate every request, it may assign an explicit expiration time in the past. This means that the response is always stale, and so the cache SHOULD validate it before using it for subsequent requests. See section 14.9.4 for a more restrictive way to force revalidation.
起源サーバが、意味的に透明なキャッシュにあらゆる要求を有効にさせる必要があるなら、それは過去に明白な満了時間を割り当てるかもしれません。 これが、応答がいつも聞き古したである意味するので、その後の要求にそれを使用する前に、キャッシュSHOULDはそれを有効にします。 再合法化を強制するより制限している方法に関してセクション14.9.4を見てください。
If an origin server wishes to force any HTTP/1.1 cache, no matter how it is configured, to validate every request, it should use the "must-revalidate" Cache-Control directive (see section 14.9).
起源サーバがどんなHTTP/1.1キャッシュも強制したいなら、あらゆる要求を有効にするためにどのように構成されても、それは「必須-revalidate」Cache-コントロール指示を使用するべきです(セクション14.9を見てください)。
Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.
サーバは、Cache-コントロールヘッダーのExpiresヘッダーか最大時代指示のどちらかを使用することで明白な満了時間を指定します。
An expiration time cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated. See section 13.13 for explanation of the difference between caches and history mechanisms.
ユーザエージェントに表示をリフレッシュするか、またはリソースを再び積ませるのに満了時間を使用できません。 意味論はメカニズムをキャッシュするだけに当てはまります、そして、そのリソースに関する新しい要求が開始されるとき、そのようなメカニズムはリソースの満了状態をチェックするだけでよいです。 キャッシュと歴史メカニズムの違いの説明に関してセクション13.13を見てください。
13.2.2 Heuristic Expiration
13.2.2 発見的な満了
Since origin servers do not always provide explicit expiration times, HTTP caches typically assign heuristic expiration times, employing algorithms that use other header values (such as the Last-Modified time) to estimate a plausible expiration time. The HTTP/1.1 specification does not provide specific algorithms, but does impose worst-case constraints on their results. Since heuristic expiration times may compromise semantic transparency, they should be used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.
起源サーバがいつも明白な満了時間を提供するというわけではないので、HTTPキャッシュは発見的な満了時間を通常割り当てます、もっともらしい満了時間を見積もるのに、他のヘッダー値(最終更新日時間などの)を使用するアルゴリズムを使って。 HTTP/1.1仕様は、特定のアルゴリズムを提供しませんが、最悪の場合規制をそれらの結果に課します。 発見的な満了時間が意味の透明性で妥協するかもしれないので、それらは用心深く使用されるべきです、そして、私たちは起源サーバが明白な満了時間をできるだけ提供するよう奨励します。
Fielding, et. al. Standards Track [Page 76] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[76ページ]RFC2068HTTP/1997年1月1.1日
13.2.3 Age Calculations
13.2.3 時代計算
In order to know if a cached entry is fresh, a cache needs to know if its age exceeds its freshness lifetime. We discuss how to calculate the latter in section 13.2.4; this section describes how to calculate the age of a response or cache entry.
キャッシュされたエントリーが新鮮であるかどうかを知るために、キャッシュは、時代が新しさ生涯を超えているかどうかを知る必要があります。 私たちはセクション13.2.4における後者について計算する方法について議論します。 このセクションは応答かキャッシュエントリーの時代について計算する方法を説明します。
In this discussion, we use the term "now" to mean "the current value of the clock at the host performing the calculation." Hosts that use HTTP, but especially hosts running origin servers and caches, should use NTP [28] or some similar protocol to synchronize their clocks to a globally accurate time standard.
この議論では、私たちは、「現在、」「計算を実行しているホストの時計の現行価値」を意味するのに用語を使用します。 HTTPを使用するホスト(特に起源サーバとキャッシュを走らせているホストだけ)は、グローバルに正確な時間規格にそれらの時計を連動させるのにNTP[28]か何らかの同様のプロトコルを使用するべきです。
Also note that HTTP/1.1 requires origin servers to send a Date header with every response, giving the time at which the response was generated. We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations.
また、HTTP/1.1があらゆる応答と共にDateヘッダーを送るために起源サーバを必要とすることに注意してください、応答が発生した時を与えて。 私たちは、四則演算に、適切なフォームでのDateヘッダーの値を指示するのに「日付_値」という用語を使用します。
HTTP/1.1 uses the Age response-header to help convey age information between caches. The Age header value is the sender's estimate of the amount of time since the response was generated at the origin server. In the case of a cached response that has been revalidated with the origin server, the Age value is based on the time of revalidation, not of the original response.
HTTP/1.1は、時代情報をキャッシュの間に伝えるのを助けるのにAge応答ヘッダを使用します。 Ageヘッダー価値は送付者の応答が起源サーバで発生して以来の時間の見積りです。起源サーバで再有効にされたキャッシュされた応答の場合では、Age値はオリジナルの応答ではなく、再合法化の時間に基づいています。
In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus the amount of time it has been in transit along network paths.
本質では、Age値は起源サーバからの経路、および時間に沿ったそれがトランジットネットワーク経路に沿って中であった応答がそれぞれのキャッシュで居住していることの現代の合計です。
We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.
私たちは、四則演算に、適切なフォームでのAgeヘッダーの値を指示するのに「時代_値」という用語を使用します。
A response's age can be calculated in two entirely independent ways:
2つの完全に独立している方法で応答の時代について計算できます:
1. now minus date_value, if the local clock is reasonably well
synchronized to the origin server's clock. If the result is
negative, the result is replaced by zero.
1. 現在、日付_値を引いて、地方の時計が合理的によく連動するなら、起源サーバのものに時間を計ってください。 結果が否定的であるなら、結果をゼロに取り替えます。
2. age_value, if all of the caches along the response path
implement HTTP/1.1.
2. 応答経路に沿ったキャッシュのすべてがHTTP/1.1を実行するなら、_値の年をとってください。
Given that we have two independent ways to compute the age of a response when it is received, we can combine these as
私たちがそれが受け取られている、私たちがそうすることができる応答の時代を計算する2つの独立している方法にこれらを結合させる当然のこと
corrected_received_age = max(now - date_value, age_value)
直っている_は_時代=最大を受けました。(今度は、_値、時代_を値とデートしてください)
and as long as we have either nearly synchronized clocks or all-
私たちが時計をほとんど連動させた限り、または、オール
Fielding, et. al. Standards Track [Page 77] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[77ページ]RFC2068HTTP/1997年1月1.1日
HTTP/1.1 paths, one gets a reliable (conservative) result.
HTTP/1.1の経路であり、1つは信頼できる(保守的な)結果を得ます。
Note that this correction is applied at each HTTP/1.1 cache along the path, so that if there is an HTTP/1.0 cache in the path, the correct received age is computed as long as the receiving cache's clock is nearly in sync. We don't need end-to-end clock synchronization (although it is good to have), and there is no explicit clock synchronization step.
この修正が経路に沿ったそれぞれのHTTP/1.1キャッシュで適用されることに注意してください、HTTP/1.0キャッシュが経路にあれば、ほとんど同時性に受信キャッシュの時計がある限り、適度の容認された時代が計算されるように。 私たちは終わりから終わりとの時計同期を必要としません、そして、(それが持つために良いのですが)どんな明白な時計同期ステップもありません。
Because of network-imposed delays, some significant interval may pass from the time that a server generates a response and the time it is received at the next outbound cache or client. If uncorrected, this delay could result in improperly low ages.
ネットワークによって課された遅れのために、いくつかの重要な間隔がサーバが応答を発生させる時、それが次の外国行きのキャッシュかクライアントに受け取られる時から変化するかもしれません。 非修正であるなら、この遅れは不適切に低時代に結果として生じるかもしれません。
Because the request that resulted in the returned Age value must have been initiated prior to that Age value's generation, we can correct for delays imposed by the network by recording the time at which the request was initiated. Then, when an Age value is received, it MUST be interpreted relative to the time the request was initiated, not the time that the response was received. This algorithm results in conservative behavior no matter how much delay is experienced. So, we compute:
返されたAge値をもたらした要求がそのAge値の世代前に開始されたに違いないので、私たちは要求が開始された時を記録することによってネットワークによって課された遅れのために修正できます。 そして、Age値が受け取られているとき、応答を受けた時間ではなく、要求が開始された時に比例してそれを解釈しなければなりません。 どのくらいの遅れが経験豊富であっても、このアルゴリズムは保守的な振舞いをもたらします。 それで、私たちは計算します:
corrected_initial_age = corrected_received_age
+ (now - request_time)
直っている直っている_初期の_時代=_は_時代+を受けました。(今度は、_時間を要求してください)
where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.
「要求_時間」がこの応答を引き出した要求が送られた時(地方の時計に従って)であるところ。
Summary of age calculation algorithm, when a cache receives a response:
キャッシュが応答を受けるときの時代計算アルゴリズムの概要
/*
* age_value
* is the value of Age: header received by the cache with
* this response.
* date_value
* is the value of the origin server's Date: header
* request_time
* is the (local) time when the cache made the request
* that resulted in this cached response
* response_time
* is the (local) time when the cache received the
* response
* now
* is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
/**時代_値*はAgeの値です: ヘッダーはキャッシュで*によるこの応答を受けました。 * 日付_値*は起源サーバの日付:の値です。 キャッシュが*現在の*がキャッシュが*応答を受けた(地方)の時であるこのキャッシュされた応答*応答_時間で結果として生じた要求*を*にしたとき、*が(地方)の時間であるヘッダー*要求_時間は現在(地方の)の時間*/見かけの_時代=最大(0、応答_時間--値と_をデートする)です。
Fielding, et. al. Standards Track [Page 78] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[78ページ]RFC2068HTTP/1997年1月1.1日
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
直っている_は_時代=最大(見かけの_時代、時代_価値)を受けました。 応答_遅れ=応答_時間--_時間を要求してください。 直っている直っている_初期の_時代=_は_時代+応答_遅れを受けました。 = 現在の居住者_時間--応答_時間。 現在の_時代=は__時間の初期の_の時代+居住者の誤りを正しました。
When a cache sends a response, it must add to the corrected_initial_age the amount of time that the response was resident locally. It must then transmit this total age, using the Age header, to the next recipient cache.
キャッシュが応答を送るとき、それは局所的に直っている_初期の_時代に応答が居住していたことの時間を加えなければなりません。 そして、次の受取人キャッシュにAgeヘッダーを使用して、それはこの総時代に伝わらなければなりません。
Note that a client cannot reliably tell that a response is first-
hand, but the presence of an Age header indicates that a response
is definitely not first-hand. Also, if the Date in a response is
earlier than the client's local request time, the response is
probably not first-hand (in the absence of serious clock skew).
クライアントが、応答が最初の手であると確かに言うことができませんが、Ageヘッダーの存在が、応答が確実に直でないことを示すというメモ。 また、応答におけるDateがクライアントの地方の要求時間より初期であるなら、応答もたぶん直ではありません(重大な時計斜行がないとき)。
13.2.4 Expiration Calculations
13.2.4 満了計算
In order to decide whether a response is fresh or stale, we need to compare its freshness lifetime to its age. The age is calculated as described in section 13.2.3; this section describes how to calculate the freshness lifetime, and to determine if a response has expired. In the discussion below, the values can be represented in any form appropriate for arithmetic operations.
応答が新鮮であるか、または聞き古したであるか決めるために、私たちは、新しさ生涯から時代を比較する必要があります。 時代はセクション13.2.3で説明されるように計算されます。 このセクションは、どのように新しさ生涯を見込んで、応答が期限が切れたかどうか決定するかを説明します。 以下での議論では、四則演算に、適切などんなフォームにも値を表すことができます。
We use the term "expires_value" to denote the value of the Expires header. We use the term "max_age_value" to denote an appropriate value of the number of seconds carried by the max-age directive of the Cache-Control header in a response (see section 14.10.
私たちはExpiresヘッダーの値を指示するために「_値を吐き出す」という用語を使用します。 私たちは、応答における、Cache-コントロールヘッダーの最大時代指示で運ばれた秒数の適切な値を指示するのに用語「最大_時代_価値」を使用します。(セクション14.10を見てください。
The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:
指示がExpiresの上で優先する最大時代であり、したがって、最大年令が応答で存在しているなら、計算は単に以下の通りです。
freshness_lifetime = max_age_value
新しさ_生涯=最大_時代_価値
Otherwise, if Expires is present in the response, the calculation is:
さもなければ、Expiresが応答で存在しているなら、計算は以下の通りです。
freshness_lifetime = expires_value - date_value
新しさ_寿命=は_値を吐き出します--値と_をデートしてください。
Note that neither of these calculations is vulnerable to clock skew, since all of the information comes from the origin server.
これらの計算のどちらも斜行の時間を計るのにおいて傷つきやすくないことに注意してください、情報のすべてが起源サーバから来るので。
If neither Expires nor Cache-Control: max-age appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. If the value is greater than 24 hours, the cache must attach Warning 13 to any response whose age is more than 24 hours if
どちらもExpiresかCache-コントロールであるなら: 最大時代は応答に現れます、そして、応答はキャッシュの他の制限を含んでいません、そして、ヒューリスティックを使用して、キャッシュは新しさ生涯を計算するかもしれません。 値が24時間以上であるなら、キャッシュは時代が24時間以上であるどんな応答にもWarning13を取り付けなければなりません。
Fielding, et. al. Standards Track [Page 79] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[79ページ]RFC2068HTTP/1997年1月1.1日
such warning has not already been added.
そのような警告は既に加えられていません。
Also, if the response does have a Last-Modified time, the heuristic expiration value SHOULD be no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.
また、応答に最終更新日時間があるなら、発見的な満了値のSHOULDはその時以来の間隔のある部分ほど持っていません。 この断片の典型的な設定は10%であるかもしれません。
The calculation to determine if a response has expired is quite simple:
応答が期限が切れたなら、決定する計算はかなり簡単です:
response_is_fresh = (freshness_lifetime > current_age)
応答_は_の新鮮な=です。(新しさ_生涯の>の現在の_時代)
13.2.5 Disambiguating Expiration Values
13.2.5 満了値のあいまいさを除くこと。
Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same resource that are different.
満了値が楽観的に割り当てられるので、2つのキャッシュが同じリソースのための異なった新鮮な値を含むのは、可能です。
If a client performing a retrieval receives a non-first-hand response for a request that was already fresh in its own cache, and the Date header in its existing cache entry is newer than the Date on the new response, then the client MAY ignore the response. If so, it MAY retry the request with a "Cache-Control: max-age=0" directive (see section 14.9), to force a check with the origin server.
検索を実行しているクライアントがそれ自身のキャッシュで既に新鮮であった要求のための非直の応答を受けて、既存のキャッシュエントリーにおけるDateヘッダーが新しい応答でのDateより新しいなら、クライアントは応答を無視するかもしれません。 そうだとすれば、それは「キャッシュで制御してください」というaとの要求を再試行するかもしれません。 最大時代は、起源サーバによるチェックを強制するために0インチの指示(セクション14.9を見る)と等しいです。
If a cache has two fresh responses for the same representation with different validators, it MUST use the one with the more recent Date header. This situation may arise because the cache is pooling responses from other caches, or because a client has asked for a reload or a revalidation of an apparently fresh cache entry.
キャッシュに異なったvalidatorsとの同じ表現のための2つの新鮮な応答があるなら、それは、より最近のDateヘッダーがあるものを使用しなければなりません。 他のキャッシュか、クライアントが明らかに新鮮なキャッシュエントリーの再ロードか再合法化を求めたのでキャッシュが応答をプールしているので、この状況は起こるかもしれません。
13.2.6 Disambiguating Multiple Responses
13.2.6 複数の応答のあいまいさを除くこと。
Because a client may be receiving responses via multiple paths, so that some responses flow through one set of caches and other responses flow through a different set of caches, a client may receive responses in an order different from that in which the origin server sent them. We would like the client to use the most recently generated response, even if older responses are still apparently fresh.
クライアントが1セットのキャッシュと他の応答による何らかの応答流動が異なったセットのキャッシュを通して流れるように複数の経路を通して応答を受けているかもしれないので、クライアントは起源サーバがそれらを送ったそれと異なったオーダーにおける応答を受けるかもしれません。 より古い応答がまだ明らかに新鮮であっても、私たちは、クライアントに最も最近発生している応答を使用して欲しいと思います。
Neither the entity tag nor the expiration value can impose an ordering on responses, since it is possible that a later response intentionally carries an earlier expiration time. However, the HTTP/1.1 specification requires the transmission of Date headers on every response, and the Date values are ordered to a granularity of one second.
実体タグも満了値も注文を応答に課すことができません、後の応答が故意に以前の満了時間を運ぶのが、可能であるので。 しかしながら、HTTP/1.1仕様はあらゆる応答のDateヘッダーのトランスミッションを必要とします、そして、Date値は1秒の粒状に命令されます。
Fielding, et. al. Standards Track [Page 80] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[80ページ]RFC2068HTTP/1997年1月1.1日
When a client tries to revalidate a cache entry, and the response it receives contains a Date header that appears to be older than the one for the existing entry, then the client SHOULD repeat the request unconditionally, and include
いつクライアントはキャッシュエントリーをrevalidateに試みて、それが受ける応答はものより既存のエントリーには古いように見えるDateヘッダーを含んでいて、次に、クライアントSHOULDは無条件に要求を繰り返しますか、そして、インクルード
Cache-Control: max-age=0
キャッシュ制御: 最大時代=0
to force any intermediate caches to validate their copies directly with the origin server, or
またはどんな中間的も直接起源サーバでそれらのコピーを有効にするためにキャッシュする力に。
Cache-Control: no-cache
キャッシュ制御: キャッシュがありません。
to force any intermediate caches to obtain a new copy from the origin server.
どんな中間的キャッシュにも起源サーバから新しいコピーを入手させるように。
If the Date values are equal, then the client may use either response (or may, if it is being extremely prudent, request a new response). Servers MUST NOT depend on clients being able to choose deterministically between responses generated during the same second, if their expiration times overlap.
Date値が等しいなら、クライアントは応答(または、それが非常に慎重な状態であるなら、新しい応答を要求するかもしれない)を使用するかもしれません。 サーバを決定論的に同じ2番目の間に発生する応答を選ぶことができるクライアントに頼ってはいけません、彼らの満了時代が重なるなら。
13.3 Validation Model
13.3 合法化モデル
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. We call this "validating" the cache entry. Since we do not want to have to pay the overhead of retransmitting the full response if the cached entry is good, and we do not want to pay the overhead of an extra round trip if the cached entry is invalid, the HTTP/1.1 protocol supports the use of conditional methods.
キャッシュにそれがクライアントの要求への応答として使用したがっている聞き古したエントリーがあるとき、それは、最初に、キャッシュされたエントリーがまだ使用可能であるかどうか確認するために、起源サーバ(または、ことによると新鮮な応答がある中間的キャッシュ)に問い合わせなければなりません。 私たちは、これをキャッシュエントリーが「有効にする」であると呼びます。 キャッシュされたエントリーが良いなら私たちが、完全な応答を再送するオーバーヘッドを支払わなければならなくて欲しいと思わないで、キャッシュされたエントリーが無効であるなら余分な周遊旅行のオーバーヘッドを支払いたいと思わないので、HTTP/1.1プロトコルは条件付きの方法の使用を支持します。
The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request.
条件付きの方法を支持するための主要なプロトコル機能は「キャッシュvalidators」に関するものです。 起源サーバが完全な応答を発生させると、それはそれへのある種のvalidatorを取り付けます。(validatorはキャッシュエントリーで保たれます)。 クライアント(ユーザエージェントかプロキシキャッシュ)がそれがキャッシュエントリーを持っているリソースのための条件付き要求をするとき、それは要求に関連validatorを含んでいます。
The server then checks that validator against the current validator for the entity, and, if they match, it responds with a special status code (usually, 304 (Not Modified)) and no entity-body. Otherwise, it returns a full response (including entity-body). Thus, we avoid transmitting the full response if the validator matches, and we avoid an extra round trip if it does not match.
サーバは次に、現在のvalidatorに対して実体がないかどうかそのvalidatorをチェックします、そして、彼らが合っているなら、それは特別なステータスコード(通常304(Modifiedでない))にもかかわらず、どんな実体本体でも応じません。 さもなければ、それは完全な応答を返します(実体本体を含んでいて)。 したがって、validatorが合っているなら、私たちは、完全な応答を伝えるのを避けます、そして、合っていないなら、余分な周遊旅行を避けます。
Fielding, et. al. Standards Track [Page 81] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[81ページ]RFC2068HTTP/1997年1月1.1日
Note: the comparison functions used to decide if validators match
are defined in section 13.3.3.
以下に注意してください。 validatorsが合っているかどうか決めるのに使用される比較関数はセクション13.3.3で定義されます。
In HTTP/1.1, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually, GET) into a conditional.
コネHTTP/1.1、条件付き要求はまさに同じリソースに関する通常の要求と同じに見えます、それとなく、aへの方法(通常GET)を条件付きに変える特別なヘッダー(validatorを含んでいる)を運ぶのを除いて。
The protocol includes both positive and negative senses of cache- validating conditions. That is, it is possible to request either that a method be performed if and only if a validator matches or if and only if no validators match.
プロトコルは積極的なものとキャッシュが状態を有効にするという同様に否定的な感覚を含んでいます。 そして、または、すなわち、方法が実行されるよう要求するのが可能である、validatorが単に合わせる、validatorsが全く合っていない場合にだけ。
Note: a response that lacks a validator may still be cached, and
served from cache until it expires, unless this is explicitly
prohibited by a Cache-Control directive. However, a cache cannot do
a conditional retrieval if it does not have a validator for the
entity, which means it will not be refreshable after it expires.
以下に注意してください。 validatorを欠いている応答は、キャッシュからまだ期限が切れるまでキャッシュされて、役立たれているかもしれません、これがCache-コントロール指示で明らかに禁止されない場合。 しかしながら、リフレッシュ可能であることを期限が切れた後にそれがならない意味する実体のためのvalidatorを持っていないなら、キャッシュは条件付きの検索ができません。
13.3.1 Last-modified Dates
13.3.1 最終更新日日付
The Last-Modified entity-header field value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the entity has not been modified since the Last-Modified value.
最終更新日実体ヘッダーフィールド価値はキャッシュvalidatorとしてしばしば使用されます。 簡単に言えば、最終更新日値以来実体が変更されていないなら、キャッシュエントリーが有効であると考えられます。
13.3.2 Entity Tag Cache Validators
13.3.2 実体タグキャッシュValidators
The ETag entity-header field value, an entity tag, provides for an "opaque" cache validator. This may allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of HTTP date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that may arise from the use of modification dates.
ETag実体ヘッダーフィールド価値(実体タグ)は「不透明な」キャッシュvalidatorに備えます。 これはHTTP日付の値の2分の1の解決が十分でない変更日付を格納するのが不便であるか、または起源サーバが変更日付の使用から起こるかもしれないあるパラドックスを避けたがっている状況における、より信頼できる合法化を許すかもしれません。
Entity Tags are described in section 3.11. The headers used with entity tags are described in sections 14.20, 14.25, 14.26 and 14.43.
実体Tagsはセクション3.11で説明されます。 実体タグと共に使用されるヘッダーはセクション14.20、14.25、14.26、および14.43で説明されます。
13.3.3 Weak and Strong Validators
13.3.3 弱くて強いValidators
Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the entity (the entity-body or any entity- headers) changes in any way, then the associated validator would change as well. If this is true, then we call this validator a "strong validator."
起源サーバとキャッシュの両方が彼らが同じであるか異なった実体を表すかどうか決めるために2validatorsを比較するので、通常、人は、実体(実体本体かどんな実体ヘッダーも)が何らかの方法で変化するならまた、関連validatorが変化すると予想するでしょう。 これが本当であるなら、私たちは、このvalidatorを「強いvalidator」と呼びます。
However, there may be cases when a server prefers to change the validator only on semantically significant changes, and not when
しかしながら、サーバが、いつではなく、意味的に重要な変化だけでvalidatorを変えるかを好むとき、ケースがあるかもしれません。
Fielding, et. al. Standards Track [Page 82] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[82ページ]RFC2068HTTP/1997年1月1.1日
insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator."
実体のわずかな局面は変化します。 リソースがいつ変化するかをいつも変えるというわけではないvalidatorは「弱いvalidator」です。
Entity tags are normally "strong validators," but the protocol provides a mechanism to tag an entity tag as "weak." One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
実体タグは通常「強いvalidators」ですが、プロトコルは、「弱い」として実体タグにタグ付けをするためにメカニズムを提供します。 人は1としての実体のビットが変化するときはいつも、変化する強いvalidatorを考えることができます、実体の意味が変化するときはいつも、弱い値が変化しますが。 あるいはまた、人は特定の実体のための識別子の一部として強いvalidatorを考えることができます、弱いvalidatorが1セットの意味的に同等な実体のための識別子の一部ですが。
Note: One example of a strong validator is an integer that is
incremented in stable storage every time an entity is changed.
以下に注意してください。 強いvalidatorに関する1つの例が実体を変えるときはいつも、安定貯蔵で増加される整数です。
An entity's modification time, if represented with one-second
resolution, could be a weak validator, since it is possible that
the resource may be modified twice during a single second.
2分の1の解決で表されるなら、実体の変更時間は弱いvalidatorであるかもしれません、リソースが1秒間二度変更されるのが、可能であるので。
Support for weak validators is optional; however, weak validators
allow for more efficient caching of equivalent objects; for
example, a hit counter on a site is probably good enough if it is
updated every few days or weeks, and any value during that period
is likely "good enough" to be equivalent.
弱いvalidatorsのサポートは任意です。 しかしながら、弱いvalidatorsは同等なオブジェクトの、より効率的なキャッシュを考慮します。 例えば、あらゆる数日か週に、それをアップデートするなら、サイトのヒットカウンタはたぶん十分良いです、そして、その期間のどんな値も、相当しているようにおそらく「十分良いです」。
A "use" of a validator is either when a client generates a request
and includes the validator in a validating header field, or when a
server compares two validators.
クライアントが有効にするヘッダーフィールドで要求を生成して、validatorを入れるか、またはサーバが2validatorsを比較するとき、validatorの「使用」はどちらかです。
Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional GET of a full entity. However, only a strong validator is usable for a sub-range retrieval, since otherwise the client may end up with an internally inconsistent entity.
強いvalidatorsはどんな文脈でも使用可能です。 弱いvalidatorsは単に実体の正確な平等によらない文脈で使用可能です。 例えば、完全な実体の条件付きのGETに、どちらかの種類が使用可能です。 しかしながら、サブ範囲検索に、強いvalidatorだけが使用可能です、さもなければ、クライアントが内部的に矛盾した実体で終わるかもしれないので。
The only function that the HTTP/1.1 protocol defines on validators is comparison. There are two validator comparison functions, depending on whether the comparison context allows the use of weak validators or not:
HTTP/1.1プロトコルがvalidatorsで定義する唯一の機能は比較です。 比較文脈が弱いvalidatorsの使用を許すかどうかによって、2つのvalidator比較関数があります:
o The strong comparison function: in order to be considered equal,
both validators must be identical in every way, and neither may be
weak.
o The weak comparison function: in order to be considered equal, both
validators must be identical in every way, but either or both of
them may be tagged as "weak" without affecting the result.
o 強い比較関数: 等しいと考えられるために、両方のvalidatorsはあらゆる点で同じでなければならなく、どちらも弱くないかもしれません。○ 弱い比較は機能します: 等しいと考えられるために、両方のvalidatorsはあらゆる点で同じでなければなりませんが、彼らのどちらかか両方が「弱い」として結果に影響するのなしでタグ付けをされるかもしれません。
The weak comparison function MAY be used for simple (non-subrange)
機能が簡単な状態で使用されているかもしれない弱い比較(非サブレンジ)です。
Fielding, et. al. Standards Track [Page 83] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[83ページ]RFC2068HTTP/1997年1月1.1日
GET requests. The strong comparison function MUST be used in all other cases.
GET要求。 他のすべての場合に強い比較関数を使用しなければなりません。
An entity tag is strong unless it is explicitly tagged as weak. Section 3.11 gives the syntax for entity tags.
それが弱いとして明らかにタグ付けをされない場合、実体タグは強いです。 セクション3.11は実体タグのために構文を与えます。
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
validatorとして要求で使用されて、それが強いと推論するのが可能でない場合、最終更新日時間はそれとなく弱いです、以下の規則を使用して:
o The validator is being compared by an origin server to the actual
current validator for the entity and,
o That origin server reliably knows that the associated entity did
not change twice during the second covered by the presented
validator.
or
o validatorは実体のために発生源サーバによって実際の現在のvalidatorと比較されています、そして、o That発生源サーバは関連実体が提示されたvalidatorでカバーされた2番目の間二度変化しなかったのを確かに知っています。
o The validator is about to be used by a client in an If-Modified-
Since or If-Unmodified-Since header, because the client has a cache
entry for the associated entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
or
o validatorは-以来、Ifによって変更されたか以来If変更されていないヘッダーというクライアントによって使用されようとしています、○ クライアントには関連実体のためのキャッシュエントリーがあって、o Thatキャッシュエントリーが発生源サーバがオリジナルの応答を送った時を与えるDate値を含んで、提示された最終更新日時間がDate値の少なくとも60秒前であるので。
o The validator is being compared by an intermediate cache to the
validator stored in its cache entry for the entity, and
o That cache entry includes a Date value, which gives the time when
the origin server sent the original response, and
o The presented Last-Modified time is at least 60 seconds before the
Date value.
o ○ validatorは中間的キャッシュによって実体のためのキャッシュエントリーに保存されたvalidatorと比較されています、そして、o ThatキャッシュエントリーはDate値を含んでいます、そして、提示された最終更新日時間はDate値の少なくとも60秒前です。(それは、発生源サーバがオリジナルの応答を送った時を与えます)。
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time. The arbitrary 60- second limit guards against the possibility that the Date and Last- Modified values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation may use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
このメソッドは同じ2番目の間発生源サーバで2つの異なった応答を送りましたが、両方に同最終更新日時間があるなら少なくともそれらの応答の1つでDate値が最終更新日時間まで等しくなるだろうという事実を当てにします。 DateとLastが値を変更した可能性に対する2番目の任意の60限界番人は異なった時計、または応答の準備の間のいくらかいろいろな時間に生成されます。 60秒が短過ぎると信じられているなら、実装は60秒より大きい値を使用するかもしれません。
If a client wishes to perform a sub-range retrieval on a value for which it has only a Last-Modified time and no opaque validator, it may do this only if the Last-Modified time is strong in the sense described here.
クライアントが最終更新日時間しか持っていませんが、それがどんな不透明なvalidatorも持っていない値にサブ範囲検索を実行したいなら、最終更新日時間がここで説明された意味に強い場合にだけ、それがこれをするかもしれません。
Fielding, et. al. Standards Track [Page 84] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[84ページ]RFC2068HTTP/1997年1月1.1日
A cache or origin server receiving a cache-conditional request, other than a full-body GET request, MUST use the strong comparison function to evaluate the condition.
GETが要求するいっぱいのボディーを除いて、キャッシュ条件付き要求を受けるキャッシュか発生源サーバが、状態を評価するのに強い比較関数を使用しなければなりません。
These rules allow HTTP/1.1 caches and clients to safely perform sub- range retrievals on values that have been obtained from HTTP/1.0 servers.
これらの規則で、HTTP/1.1人のキャッシュとクライアントが安全にHTTP/1.0のサーバから得られた値にサブ範囲retrievalsを実行できます。
13.3.4 Rules for When to Use Entity Tags and Last-modified Dates
13.3.4 いつ実体タグを使用するか間の規則と最終更新日日付
We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types should be used, and for what purposes.
私たちは様々なvalidatorタイプが使用されるべきである時と、どんな目的のために1セットの規則と発生源サーバ、クライアント、およびキャッシュのための推薦を採用するか。
HTTP/1.1 origin servers:
HTTP/1.1の発生源サーバ:
o SHOULD send an entity tag validator unless it is not feasible to
generate one.
o MAY send a weak entity tag instead of a strong entity tag, if
performance considerations support the use of weak entity tags, or
if it is unfeasible to send a strong entity tag.
o SHOULD send a Last-Modified value if it is feasible to send one,
unless the risk of a breakdown in semantic transparency that could
result from using this date in an If-Modified-Since header would
lead to serious problems.
o oは強い実体タグの代わりに弱い実体タグを送るかもしれません、性能問題が弱い実体タグの使用をサポートするか、または強い実体タグを送るのが実行不可能であるなら。1つを送るのが可能であるなら、o SHOULDは最終更新日値を送ります、それが生じることができた意味の透明性における以来変更されたIfヘッダーでこの日付を使用する故障のリスクが深刻な問題につながらないなら。1つを生成するのが可能である場合、SHOULDは実体タグvalidatorを送ります。
In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity tag and a Last-Modified value.
言い換えれば、HTTP/1.1発生源サーバのための都合のよい振舞いは強い実体タグと最終更新日値の両方を送ることです。
In order to be legal, a strong entity tag MUST change whenever the associated entity value changes in any way. A weak entity tag SHOULD change whenever the associated entity changes in a semantically significant way.
法的になるように、関連実体値が何らかの方法で変化するときはいつも、強い実体タグは変化しなければなりません。 関連実体が意味的に重要な方法で変化するときはいつも、弱い実体タグSHOULD変化。
Note: in order to provide semantically transparent caching, an
origin server must avoid reusing a specific strong entity tag value
for two different entities, or reusing a specific weak entity tag
value for two semantically different entities. Cache entries may
persist for arbitrarily long periods, regardless of expiration
times, so it may be inappropriate to expect that a cache will never
again attempt to validate an entry using a validator that it
obtained at some point in the past.
以下に注意してください。 意味的に透明なキャッシュを提供するために、発生源サーバは、2つの異なった実体のために特定の強い実体タグ価値を再利用するか、または2つの意味的に異なった実体のために特定の弱い実体タグ価値を再利用するのを避けなければなりません。 キャッシュエントリーは任意に長い期間、固執するかもしれません、キャッシュが、二度とそれが過去に何らかのポイントで入手したvalidatorを使用することでエントリーを有効にするのを試みないと予想するのが不適当であるかもしれないことで満了時間にかかわらず。
HTTP/1.1 clients:
HTTP/1.1人のクライアント:
o If an entity tag has been provided by the origin server, MUST
use that entity tag in any cache-conditional request (using
If-Match or If-None-Match).
o 実体タグが発生源サーバによって提供されて、どんなキャッシュ条件付き要求にもその実体タグを使用しなければならないなら(If-マッチかなにも合わせないIfを使用して)。
Fielding, et. al. Standards Track [Page 85] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[85ページ]RFC2068HTTP/1997年1月1.1日
o If only a Last-Modified value has been provided by the origin
server, SHOULD use that value in non-subrange cache-conditional
requests (using If-Modified-Since).
o If only a Last-Modified value has been provided by an HTTP/1.0
origin server, MAY use that value in subrange cache-conditional
requests (using If-Unmodified-Since:). The user agent should
provide a way to disable this, in case of difficulty.
o If both an entity tag and a Last-Modified value have been
provided by the origin server, SHOULD use both validators in
cache-conditional requests. This allows both HTTP/1.0 and
HTTP/1.1 caches to respond appropriately.
o 発生源サーバで最終更新日値だけを提供したなら、SHOULDは非サブレンジキャッシュ条件付き要求にその値を使用します(以来変更されたIfを使用して)。最終更新日値だけがHTTP/1.0発生源サーバ、5月までに提供されたo Ifはサブレンジキャッシュ条件付き要求にその値を使用します(以来変更されていない使用If:)。 ユーザエージェントはこれを無効にする方法を提供するべきです、困難な場合は。実体タグと最終更新日値の両方が発生源サーバによって提供されたo If、SHOULDはキャッシュ条件付き要求に両方のvalidatorsを使用します。 これで、両方のHTTP/1.0とHTTP/1.1のキャッシュが適切に応じます。
An HTTP/1.1 cache, upon receiving a request, MUST use the most restrictive validator when deciding whether the client's cache entry matches the cache's own cache entry. This is only an issue when the request contains both an entity tag and a last-modified-date validator (If-Modified-Since or If-Unmodified-Since).
要求を受け取るときクライアントのキャッシュエントリーがキャッシュの自己のキャッシュエントリーに合っているかどうか決めるとき、HTTP/1.1キャッシュは最も制限しているvalidatorを使用しなければなりません。 または、要求が実体タグと最後に変更された期日validatorの両方を含むときだけ、これが問題である、(以来変更される、以来変更されていないIf)
A note on rationale: The general principle behind these rules is
that HTTP/1.1 servers and clients should transmit as much non-
redundant information as is available in their responses and
requests. HTTP/1.1 systems receiving this information will make the
most conservative assumptions about the validators they receive.
原理に関する注: これらの規則の後ろの一般的な原則はHTTP/1.1人のサーバとクライアントが彼らの応答と要求で利用可能であるのと同じくらい多くの非余分な情報を伝えるべきであるということです。 この情報を受け取るHTTP/1.1台のシステムが彼らが受けるvalidatorsに関する最も保守的な仮定をするでしょう。
HTTP/1.0 clients and caches will ignore entity tags. Generally,
last-modified values received or used by these systems will support
transparent and efficient caching, and so HTTP/1.1 origin servers
should provide Last-Modified values. In those rare cases where the
use of a Last-Modified value as a validator by an HTTP/1.0 system
could result in a serious problem, then HTTP/1.1 origin servers
should not provide one.
HTTP/1.0のクライアントとキャッシュが実体タグを無視するでしょう。 一般に、これらのシステムで受け取るか、または使用する最後変更された値が透明で効率的なキャッシュをサポートするので、HTTP/1.1の発生源サーバが最終更新日値を提供するべきです。 そして、HTTP/1.0システムによるvalidatorとしての最終更新日価値の使用が深刻な問題をもたらすことができたそれらのまれなケースの中では、HTTP/1.1の発生源サーバは1つを提供するべきではありません。
13.3.5 Non-validating Conditionals
13.3.5 非の有効にするConditionals
The principle behind entity tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than byte-equality would open up a can of worms. Thus, comparisons of any other headers (except Last-Modified, for compatibility with HTTP/1.0) are never used for purposes of validating a cache entry.
実体タグの後ろの原則はサービス作者だけがリソースの意味論をバイト平等が複雑な問題を開けるだろうより複雑な状態で適切なキャッシュ合法化メカニズム、およびどんなvalidator比較関数の仕様も選択できるくらいよく知っているということです。その結果、いかなる他のヘッダー(HTTP/1.0との互換性のための最終更新日を除いた)の比較もキャッシュエントリーを有効にする目的に決して使用されません。
13.4 Response Cachability
13.4 応答Cachability
Unless specifically constrained by a Cache-Control (section 14.9) directive, a caching system may always store a successful response (see section 13.8) as a cache entry, may return it without validation if it is fresh, and may return it after successful validation. If
Cache-コントロール(セクション14.9)指示で明確に抑制されない場合、キャッシュシステムは、キャッシュエントリーとしていつもうまくいっている応答(セクション13.8を見る)を保存して、それが新鮮であるなら合法化なしでそれを返して、うまくいっている合法化の後にそれを返すかもしれません。 if
Fielding, et. al. Standards Track [Page 86] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[86ページ]RFC2068HTTP/1997年1月1.1日
there is neither a cache validator nor an explicit expiration time associated with a response, we do not expect it to be cached, but certain caches may violate this expectation (for example, when little or no network connectivity is available). A client can usually detect that such a response was taken from a cache by comparing the Date header to the current time.
キャッシュvalidatorも応答に関連している明白な満了時間もありませんが、私たちは、それがキャッシュされると予想しませんが、あるキャッシュはこの期待に違反するかもしれません(ほとんどどんなネットワークの接続性も例えば利用可能でないときに)。 通常、クライアントはそれを検出できます。キャッシュからDateヘッダーを現在の時間と比較することによって、そのような応答を取りました。
Note that some HTTP/1.0 caches are known to violate this
expectation without providing any Warning.
いくつかのHTTP/1.0のキャッシュがどんなWarningも提供しないでこの期待に違反するのが知られていることに注意してください。
However, in some cases it may be inappropriate for a cache to retain an entity, or to return it in response to a subsequent request. This may be because absolute semantic transparency is deemed necessary by the service author, or because of security or privacy considerations. Certain Cache-Control directives are therefore provided so that the server can indicate that certain resource entities, or portions thereof, may not be cached regardless of other considerations.
しかしながら、いくつかの場合、キャッシュが実体を保有するか、またはその後の要求に対応してそれを返すのが不適当であるかもしれません。 これは絶対意味の透明性が必要であるとサービス作者によって考えられるためかセキュリティかプライバシー問題からです。 したがって、サーバが、あるリソース実体、またはそれの部分が他の問題にかかわらずキャッシュされないかもしれないのを示すことができるように、あるCache-コントロール指示を提供します。
Note that section 14.8 normally prevents a shared cache from saving and returning a response to a previous request if that request included an Authorization header.
通常、セクション14.8が、その要求がAuthorizationヘッダーを含んでいたなら、共有されたキャッシュが前の要求への応答を保存して、返すのを防ぐことに注意してください。
A response received with a status code of 200, 203, 206, 300, 301 or 410 may be stored by a cache and used in reply to a subsequent request, subject to the expiration mechanism, unless a Cache-Control directive prohibits caching. However, a cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial Content) responses.
200、203、206、300、301または410のステータスコードで受けられた応答は、満了メカニズムを条件としてキャッシュによって保存されて、その後の要求に対して使用されるかもしれません、Cache-コントロール指示が、キャッシュするのを禁止しない場合。 しかしながら、RangeとContent-範囲ヘッダーを支えないキャッシュは206(部分的なContent)の応答をキャッシュしてはいけません。
A response received with any other status code MUST NOT be returned in a reply to a subsequent request unless there are Cache-Control directives or another header(s) that explicitly allow it. For example, these include the following: an Expires header (section 14.21); a "max-age", "must-revalidate", "proxy-revalidate", "public" or "private" Cache-Control directive (section 14.9).
Cache-コントロール指示か明らかにそれを許容する別のヘッダーがない場合、回答でいかなる他のステータスコードでも受けられた応答をその後の要求に返してはいけません。 例えば、これらは以下を含んでいます: Expiresヘッダー(セクション14.21)。 「最大時代」、「必須-revalidate」「プロキシrevalidateである」か、「公共」の、または、「個人的な」Cache-コントロール指示(セクション14.9)。
13.5 Constructing Responses From Caches
13.5 キャッシュから応答を構成すること。
The purpose of an HTTP cache is to store information received in response to requests, for use in responding to future requests. In many cases, a cache simply returns the appropriate parts of a response to the requester. However, if the cache holds a cache entry based on a previous response, it may have to combine parts of a new response with what is held in the cache entry.
HTTPキャッシュの目的は要求に対応して受け取られた情報を保存することです、今後の要求に応じることにおける使用のために。 多くの場合、キャッシュは単にリクエスタへの応答の適切な部分を返します。 しかしながら、キャッシュが、キャッシュエントリーが前の応答に基づいているままにするなら、それはキャッシュエントリーに保持されるものに新しい応答の部品を結合しなければならないかもしれません。
Fielding, et. al. Standards Track [Page 87] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[87ページ]RFC2068HTTP/1997年1月1.1日
13.5.1 End-to-end and Hop-by-hop Headers
13.5.1 終わりから終わりとホップごとのヘッダー
For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories:
キャッシュと非キャッシュしているプロキシの振舞いを定義する目的のために、私たちはHTTPヘッダを2つのカテゴリに分割します:
o End-to-end headers, which must be transmitted to the
ultimate recipient of a request or response. End-to-end
headers in responses must be stored as part of a cache entry
and transmitted in any response formed from a cache entry.
o Hop-by-hop headers, which are meaningful only for a single
transport-level connection, and are not stored by caches or
forwarded by proxies.
o 終わりから終わりへのヘッダー。(要求か応答の究極の受取人にそのヘッダーを伝えなければなりません)。 キャッシュエントリーの一部として応答における終わりから終わりへのヘッダーを保存しなければなりませんでした、そして、伝えられて、どんな応答でも. oホップによるHopヘッダー(単独の輸送レベル接続だけに重要であり、キャッシュによって保存されるか、またはプロキシによって進められない)はキャッシュエントリーから形成していました。
The following HTTP/1.1 headers are hop-by-hop headers:
以下のHTTP/1.1個のヘッダーがホップごとのヘッダーです:
o Connection
o Keep-Alive
o Public
o Proxy-Authenticate
o Transfer-Encoding
o Upgrade
o ○ o UpgradeをTransferコード化して、生きているKeep o Public oがProxy認証する接続o
All other headers defined by HTTP/1.1 are end-to-end headers.
HTTP/1.1によって定義された他のすべてのヘッダーが終わりから終わりへのヘッダーです。
Hop-by-hop headers introduced in future versions of HTTP MUST be listed in a Connection header, as described in section 14.10.
ホップごとのHTTPの将来のバージョンで紹介されたヘッダーはセクション14.10で説明されるようにConnectionヘッダーに記載されているに違いありません。
13.5.2 Non-modifiable Headers
13.5.2 非修正できるヘッダー
Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. A cache or non-caching proxy SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that.
HTTP/1.1プロトコルのDigest Authenticationなどのいくつかの特徴が終わりから終わりへの確信しているヘッダーの値に依存します。 そのヘッダーの定義がそれを必要である、または明確に許容しない場合、キャッシュか非キャッシュしているプロキシSHOULD NOTが終わりから終わりへのヘッダーを変更します。
A cache or non-caching proxy MUST NOT modify any of the following fields in a request or response, nor may it add any of these fields if not already present:
キャッシュか非キャッシュしているプロキシが要求か応答で以下の分野のどれかを変更してはいけません、そして、これらの分野か既にプレゼントのどれかを加えませんように:
o Content-Location
o ETag
o Expires
o Last-Modified
o 満足している位置のo ETag o Expires o最終更新日
Fielding, et. al. Standards Track [Page 88] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[88ページ]RFC2068HTTP/1997年1月1.1日
A cache or non-caching proxy MUST NOT modify or add any of the following fields in a response that contains the no-transform Cache- Control directive, or in any request:
キャッシュか非キャッシュしているプロキシが、変換がないCacheコントロール指示を含む応答、またはどんな要求でも以下の分野のどれかを変更してはいけませんし、また加えてはいけません:
o Content-Encoding
o Content-Length
o Content-Range
o Content-Type
o 内容をコード化するo Content-長さのo Content-範囲oコンテントタイプ
A cache or non-caching proxy MAY modify or add these fields in a response that does not include no-transform, but if it does so, it MUST add a Warning 14 (Transformation applied) if one does not already appear in the response.
キャッシュか非キャッシュしているプロキシが、変換を全く含んでいない応答で、これらの分野を変更するか、または加えるかもしれませんが、そうして、人が応答に既に現れないなら、それはWarning14(変換は適用されました)を加えなければなりません。
Warning: unnecessary modification of end-to-end headers may cause
authentication failures if stronger authentication mechanisms are
introduced in later versions of HTTP. Such authentication
mechanisms may rely on the values of header fields not listed here.
警告: より強い認証機構がHTTPの後のバージョンで紹介されるなら、終わりから終わりへのヘッダーの不要な変更は認証失敗を引き起こすかもしれません。 そのような認証機構はここに記載されなかったヘッダーフィールドの値を当てにするかもしれません。
13.5.3 Combining Headers
13.5.3 ヘッダーを結合すること。
When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response, the cache must construct a response to send to the requesting client. The cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. The end-to-end headers stored in the cache entry are used for the constructed response, except that any end-to-end headers provided in the 304 response MUST replace the corresponding headers from the cache entry. Unless the cache decides to remove the cache entry, it MUST also replace the end-to-end headers stored with the cache entry with corresponding headers received in the incoming response.
キャッシュが有効にする要求をサーバにして、サーバが304(Modifiedでない)応答を提供するとき、キャッシュは、要求しているクライアントに発信するために応答を構成しなければなりません。 キャッシュはこの外向的な応答の実体本体としてキャッシュエントリーに保存された実体本体を使用します。 終わりから終わりへのキャッシュエントリーに保存されたヘッダーは組み立てられた応答に使用されます、終わりから終わりへの304応答に提供されたどんなヘッダーもキャッシュエントリーから対応するヘッダーの後任にならなければならないのを除いて。 また、キャッシュが、キャッシュエントリーを取り除くと決めない場合、それは入って来る応答で受け取る対応するヘッダーでヘッダーが保存した終わりから終わりをキャッシュエントリーに取り替えなければなりません。
In other words, the set of end-to-end headers received in the incoming response overrides all corresponding end-to-end headers stored with the cache entry. The cache may add Warning headers (see section 14.45) to this set.
言い換えれば、終わりから終わりへのヘッダーのセットは入って来る応答オーバーライドで終わりから終わりへのキャッシュエントリーで保存されたすべての対応するヘッダーを受けました。 キャッシュはWarningヘッダー(セクション14.45を見る)をこのセットに追加するかもしれません。
If a header field-name in the incoming response matches more than one header in the cache entry, all such old headers are replaced.
入って来る応答におけるヘッダーフィールド名がキャッシュエントリーにおける1個以上のヘッダーに合っているなら、そのようなすべての年取ったヘッダーを取り替えます。
Note: this rule allows an origin server to use a 304 (Not Modified)
response to update any header associated with a previous response
for the same entity, although it might not always be meaningful or
correct to do so. This rule does not allow an origin server to use
a 304 (not Modified) response to entirely delete a header that it
had provided with a previous response.
以下に注意してください。 発生源サーバは同じ実体のための前の応答に関連しているどんなヘッダーもアップデートするのにこの規則で304(Modifiedでない)応答を使用できます、そうするのがいつも重要であるか、または正しいかもしれないというわけではありませんが。 この規則で、発生源サーバは、それが前の応答に提供したヘッダーを完全に削除するのに304(Modifiedでない)応答を使用できません。
Fielding, et. al. Standards Track [Page 89] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[89ページ]RFC2068HTTP/1997年1月1.1日
13.5.4 Combining Byte Ranges
13.5.4 バイト範囲を結合すること。
A response may transfer only a subrange of the bytes of an entity- body, either because the request included one or more Range specifications, or because a connection was broken prematurely. After several such transfers, a cache may have received several ranges of the same entity-body.
応答は実体本体のバイトのサブレンジだけを移すかもしれません、要求が1つ以上のRange仕様を含んでいたか、または接続が早まって失意であったので。 そのような数回の転送の後に、キャッシュはいくつかの範囲の同じ実体本体を受けたかもしれません。
If a cache has a stored non-empty set of subranges for an entity, and an incoming response transfers another subrange, the cache MAY combine the new subrange with the existing set if both the following conditions are met:
キャッシュには実体のためのサブレンジの保存された非空集合があって、入って来る応答が別のサブレンジを移すなら、以下の条件の両方が満たされるなら、キャッシュは新しいサブレンジを既存のセットに結合するかもしれません:
o Both the incoming response and the cache entry must have a cache
validator.
o The two cache validators must match using the strong comparison
function (see section 13.3.3).
o 入って来る応答とキャッシュエントリーの両方には、キャッシュvalidatorがなければなりません。○ 強い比較関数を使用することで2キャッシュvalidatorsは合わなければなりません(セクション13.3.3を見てください)。
If either requirement is not meant, the cache must use only the most recent partial response (based on the Date values transmitted with every response, and using the incoming response if these values are equal or missing), and must discard the other partial information.
どちらの要件も意味されないなら、キャッシュは、最新の部分応答(あらゆる応答のときに伝えられたDate値に基づいていて、これらの値が等しいか、またはなくなるなら、入って来る応答を使用する)だけを使用しなければならなくて、もう片方の部分的な情報を捨てなければなりません。
13.6 Caching Negotiated Responses
13.6 キャッシュは応答を交渉しました。
Use of server-driven content negotiation (section 12), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests.
サーバ駆動の満足している交渉(セクション12)の応答における、Varyヘッダーフィールドの存在によって示される使用はキャッシュがその後の要求に応答を使用できる状態と手順を変更します。
A server MUST use the Vary header field (section 14.43) to inform a cache of what header field dimensions are used to select among multiple representations of a cachable response. A cache may use the selected representation (the entity included with that particular response) for replying to subsequent requests on that resource only when the subsequent requests have the same or equivalent values for all header fields specified in the Vary response-header. Requests with a different value for one or more of those header fields would be forwarded toward the origin server.
サーバは、寸法がキャッシュ可能応答の複数の表現の中で選択するのにおいてどんなヘッダーフィールドに使用されているかをキャッシュに知らせるのに、Varyヘッダーフィールド(セクション14.43)を使用しなければなりません。 キャッシュはVary応答ヘッダで指定されたすべてのヘッダーフィールドに、その後の要求に同じであるか同等な値があるときだけそのリソースに関するその後の要求に答える選択された表現(その特定の応答で含まれていた実体)を使用するかもしれません。 それらのヘッダーフィールドの1つ以上の異価がある要求を発生源サーバに向かって転送するでしょう。
If an entity tag was assigned to the representation, the forwarded request SHOULD be conditional and include the entity tags in an If- None-Match header field from all its cache entries for the Request- URI. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the
実体タグが表現に割り当てられたなら、進められた要求SHOULDが条件付きであり、Ifに実体タグを含んでいる、-なにもに、合ってください、Request URIのためのすべてのキャッシュエントリーからのヘッダーフィールド。 これは現在キャッシュによって開催されている実体のセットをサーバまで運びます、これらの実体のどれかが要求された実体に合っているなら、サーバがどのエントリーが適切であるかをキャッシュに言うのに304(Modifiedでない)応答にETagヘッダーを使用できるように。 新しい応答の実体タグが既存のエントリーのものに合っているなら
Fielding, et. al. Standards Track [Page 90] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[90ページ]RFC2068HTTP/1997年1月1.1日
new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
新しい応答SHOULD、使用されて、既存のエントリーのヘッダーフィールド、および結果をアップデートするために、クライアントに返さなければならないということになってください。
The Vary header field may also inform the cache that the representation was selected using criteria not limited to the request-headers; in this case, a cache MUST NOT use the response in a reply to a subsequent request unless the cache relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates which entity should be used.
また、Varyヘッダーフィールドは、表現が要求ヘッダーに制限されなかった評価基準を使用することで選択されたことをキャッシュに知らせるかもしれません。 この場合、キャッシュが条件付き要求における発生源サーバに新しい要求をリレーして、サーバが304(Modifiedでない)で反応しない場合、キャッシュはその後の要求に回答における応答を使用してはいけません、どの実体が使用されるべきであるかを示す実体タグかContent-位置を含んでいて。
If any of the existing cache entries contains only partial content for the associated entity, its entity-tag SHOULD NOT be included in the If-None-Match header unless the request is for a range that would be fully satisfied by that entry.
含まれているコネがなにも合わせないIfヘッダーであり、要求がそのエントリーで完全に満たされている範囲に含んでいない場合既存のキャッシュエントリーのどれかが関連実体のための部分的な内容だけ、実体タグSHOULD NOTを含んでいるなら。
If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same Request- URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD NOT be returned in response to future requests, and should be deleted from the cache.
キャッシュがContent-位置の分野が同じRequest URIのために既存のキャッシュエントリーのものに合って、実体タグが既存のエントリーのものと異なっていて、既存のエントリーにおいてDateがそれより最近であるうまくいっている応答を受けるなら、既存のエントリーSHOULD NOTは今後の要求に対応して返されて、キャッシュから削除されるべきです。
13.7 Shared and Non-Shared Caches
13.7 共有されて非共有されたキャッシュ
For reasons of security and privacy, it is necessary to make a distinction between "shared" and "non-shared" caches. A non-shared cache is one that is accessible only to a single user. Accessibility in this case SHOULD be enforced by appropriate security mechanisms. All other caches are considered to be "shared." Other sections of this specification place certain constraints on the operation of shared caches in order to prevent loss of privacy or failure of access controls.
セキュリティとプライバシーの理由に、「共有され」て「非共有された」キャッシュの間で区別をするのが必要です。 非共有されたキャッシュはシングルユーザーだけに、アクセスしやすいものです。 適切なセキュリティー対策によって実施されてください。この場合アクセシビリティSHOULD、他のすべてのキャッシュが「共有される」と考えられます。 この仕様の他のセクションは、プライバシーの損失かアクセス制御の失敗を防ぐために共有されたキャッシュの操作に、ある規制を置きます。
13.8 Errors or Incomplete Response Cache Behavior
13.8の誤りか不完全な応答が振舞いをキャッシュします。
A cache that receives an incomplete response (for example, with fewer bytes of data than specified in a Content-Length header) may store the response. However, the cache MUST treat this as a partial response. Partial responses may be combined as described in section 13.5.4; the result might be a full response or might still be partial. A cache MUST NOT return a partial response to a client without explicitly marking it as such, using the 206 (Partial Content) status code. A cache MUST NOT return a partial response using a status code of 200 (OK).
不完全な応答(例えばContent-長さのヘッダーで指定されるより少ないバイトのデータで)を受けるキャッシュは応答を保存するかもしれません。 しかしながら、キャッシュは部分応答としてこれを扱わなければなりません。 部分応答はセクション13.5.4で説明されるように結合されるかもしれません。 結果は、完全な応答であるかもしれないかまだ部分であるかもしれません。 明らかにそういうものとしてそれをマークしないで、キャッシュは部分応答をクライアントに返してはいけません、206(部分的なContent)ステータスコードを使用して。 200(OK)のステータスコードを使用して、キャッシュは部分応答を返してはいけません。
If a cache receives a 5xx response while attempting to revalidate an entry, it may either forward this response to the requesting client,
キャッシュがrevalidateにエントリーを試みている間、5xx応答を受けるなら、それは要求しているクライアントへのこの応答を進めるかもしれません。
Fielding, et. al. Standards Track [Page 91] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[91ページ]RFC2068HTTP/1997年1月1.1日
or act as if the server failed to respond. In the latter case, it MAY return a previously received response unless the cached entry includes the "must-revalidate" Cache-Control directive (see section 14.9).
または、まるでサーバが応じないかのように、行動してください。 後者の場合では、キャッシュされたエントリーが「必須-revalidate」Cache-コントロール指示を含んでいない場合(セクション14.9を見てください)、それは以前に容認された応答を返すかもしれません。
13.9 Side Effects of GET and HEAD
13.9回の副作用、得て、上に立つ。
Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache. They may still have side effects, but a cache is not required to consider such side effects in its caching decisions. Caches are always expected to observe an origin server's explicit restrictions on caching.
発生源サーバが明らかに彼らの応答のキャッシュ、GETのアプリケーションを禁止して、どんなリソースSHOULD NOTへのHEADメソッドにもキャッシュからこれらの応答を取るなら誤った振舞いに通じる副作用がない場合。 彼らには、副作用がまだあるかもしれませんが、キャッシュは、決定をキャッシュする際にそのような副作用を考えるのに必要ではありません。 いつもキャッシュが発生源サーバの明白な制限をキャッシュに観測すると予想されます。
We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URLs as fresh unless the server provides an explicit expiration time. This specifically means that responses from HTTP/1.0 servers for such URIs should not be taken from a cache. See section 9.1.1 for related information.
私たちはこの規則への1つの例外に注意します: いくつかのアプリケーションが重要な副作用に伴う操作を実行するのに質問URL(rel_経路部分に“?"を含むもの)があるGETsとHEADsを伝統的に使用したので、サーバが明白な満了時間を提供しない場合、キャッシュは新鮮であるようなURLへの応答を扱ってはいけません。 これは、そのようなURIのためのHTTP/1.0のサーバからの応答がキャッシュから取られるべきでないことを明確に意味します。 関連する情報に関してセクション9.1.1を見てください。
13.10 Invalidation After Updates or Deletions
13.10 無効にするアップデートか削除の後の
The effect of certain methods at the origin server may cause one or more existing cache entries to become non-transparently invalid. That is, although they may continue to be "fresh," they do not accurately reflect what the origin server would return for a new request.
発生源サーバにおける、あるメソッドの効果によって、1つ以上の既存のキャッシュエントリーが非透過的に無効になるかもしれません。 すなわち、「新鮮であり」続けるかもしれませんが、彼らは正確に、発生源サーバが新しい要求のために返すものを反映しません。
There is no way for the HTTP protocol to guarantee that all such cache entries are marked invalid. For example, the request that caused the change at the origin server may not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior.
HTTPプロトコルが、そのようなすべてのキャッシュエントリーが無効であることが示されるのを保証する方法が全くありません。 例えば、発生源サーバで変化を引き起こした要求はキャッシュエントリーが保存されるところにプロキシに直面していないかもしれません。 しかしながら、いくつかの規則が、誤った振舞いの見込みを減少させるのを助けます。
In this section, the phrase "invalidate an entity" means that the cache should either remove all instances of that entity from its storage, or should mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request.
このセクションでは、「実体を無効にする」という句は、キャッシュがストレージからその実体のすべてのインスタンスを取り除くべきであることを意味するべきであるか、またはその後の要求に対応してそれらを返すことができる前に「病人」と義務的な再合法化を必要としてこれらをマークするべきです。
Fielding, et. al. Standards Track [Page 92] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[92ページ]RFC2068HTTP/1997年1月1.1日
Some HTTP methods may invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content- Location response-headers (if present). These methods are:
いくつかのHTTPメソッドが実体を無効にするかもしれません。 これは実体がRequest-URI、またはLocationかContent位置の応答ヘッダで言及したどちらか(存在しているなら)です。 これらのメソッドは以下の通りです。
o PUT
o DELETE
o POST
o PUT o DELETE oポスト
In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI.
サービス不能攻撃を防ぐために、ホスト部分がRequest-URIと同じであるなら、LocationかContent-位置のヘッダーでURIに基づく無効にするのを実行するだけでよいです。
13.11 Write-Through Mandatory
13.11は-通じて義務的な状態で書きます。
All methods that may be expected to cause modifications to the origin server's resources MUST be written through to the origin server. This currently includes all methods except for GET and HEAD. A cache MUST NOT reply to such a request from a client before having transmitted the request to the inbound server, and having received a corresponding response from the inbound server. This does not prevent a cache from sending a 100 (Continue) response before the inbound server has replied.
発生源サーバに突き抜けた状態で発生源サーバのリソースへの変更を引き起こすと予想されるかもしれないすべてのメソッドを書かなければなりません。これは現在、GETとHEAD以外のすべてのメソッドを含んでいます。 本国行きのサーバに要求を送信して、本国行きのサーバから対応する応答を受ける前に、キャッシュはクライアントからのそのような要求に答えてはいけません。これは、本国行きのサーバが返答する前にキャッシュが100(続けている)応答を送るのを防ぎません。
The alternative (known as "write-back" or "copy-back" caching) is not allowed in HTTP/1.1, due to the difficulty of providing consistent updates and the problems arising from server, cache, or network failure prior to write-back.
代替手段(「-裏に書いてください」か「コピー逆」キャッシュとして、知られている)はHTTP/1.1で許容されていません、書き返す前にサーバ、キャッシュ、またはネットワーク失敗から起こることにおける一貫したアップデートと問題を提供するという困難のため。
13.12 Cache Replacement
13.12 キャッシュ交換
If a new cachable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8) response is received from a resource while any existing responses for the same resource are cached, the cache SHOULD use the new response to reply to the current request. It may insert it into cache storage and may, if it meets all other requirements, use it to respond to any future requests that would previously have caused the old response to be returned. If it inserts the new response into cache storage it should follow the rules in section 13.5.3.
セクション14.9.2を見てください、13.2。新しいキャッシュ可能である、(.5 13.2 .6と13.8) 同じリソースのためのどんな既存の応答もキャッシュしますが、リソースから応答を受けて、キャッシュSHOULDは、現在の要求に答えるのに新しい応答を使用します。 それは、キャッシュストレージにそれを挿入して、他のすべての必要条件を満たすなら、以前に古い応答を返したどんな今後の要求にも応じるのにそれを使用するかもしれません。 新しい応答をキャッシュストレージに挿入するなら、それはセクション13.5.3で約束を守るべきです。
Note: a new response that has an older Date header value than
existing cached responses is not cachable.
以下に注意してください。 既存のキャッシュされた応答より古いDateヘッダー価値がある新しい応答はキャッシュ可能ではありません。
13.13 History Lists
13.13 歴史リスト
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session.
ユーザエージェントには、歴史メカニズムがしばしばあります、「逆」ボタンや履歴リストなどのように。(実体がセッションのときに前に検索した「再-ディスプレイ」に履歴リストを使用できます)。
Fielding, et. al. Standards Track [Page 93] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[93ページ]RFC2068HTTP/1997年1月1.1日
History mechanisms and caches are different. In particular history mechanisms SHOULD NOT try to show a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved.
歴史メカニズムとキャッシュは異なっています。 特に、歴史メカニズムSHOULD NOTはリソースの現状の意味的に見え透いた視点を示そうとします。 むしろ、歴史メカニズムは、リソースが検索されたとき、ユーザがまさに何を見たかを示すことになっています。
By default, an expiration time does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.
デフォルトで、満了時間は歴史メカニズムに適用しません。実体がまだストレージ中であるなら、実体が期限が切れたとしても、歴史メカニズムはそれを表示するはずです、ユーザが、リフレッシュするエージェントが歴史ドキュメントを吐き出したのを明確に構成していない場合。
This should not be construed to prohibit the history mechanism from telling the user that a view may be stale.
歴史メカニズムが、眺めが聞き古したであるかもしれないユーザに言うのを禁止するためにこれを解釈するべきではありません。
Note: if history list mechanisms unnecessarily prevent users from
viewing stale resources, this will tend to force service authors to
avoid using HTTP expiration controls and cache controls when they
would otherwise like to. Service authors may consider it important
that users not be presented with error messages or warning messages
when they use navigation controls (such as BACK) to view previously
fetched resources. Even though sometimes such resources ought not
to cached, or ought to expire quickly, user interface
considerations may force service authors to resort to other means
of preventing caching (e.g. "once-only" URLs) in order not to
suffer the effects of improperly functioning history mechanisms.
以下に注意してください。 ユーザが履歴リストメカニズムによって不必要に聞き古したリソースを見ることができないと、これは、サービス作者にそうでなければ、使用したがっているとき、HTTP満了コントロールとキャッシュ制御を使用するのを避けさせる傾向があるでしょう。 サービス作者は、以前にとって来られたリソースを見るのに、ナビゲーションコントロール(BACKなどの)を使用する場合エラーメッセージか警告メッセージがユーザに与えられないのが、重要であると考えるかもしれません。 時々そのようなリソースは、キャッシュされて、そうするべきではありませんし、またすぐに期限が切れるべきですが、ユーザーインタフェース問題によって、サービス作者はやむを得ず効果を受けないオーダーにおける(例えば、「かつて唯一」のURL)をキャッシュするのを防ぐ他の手段に不適切に機能している歴史メカニズムを再ソートするかもしれません。
14 Header Field Definitions
14 ヘッダーフィールド定義
This section defines the syntax and semantics of all standard HTTP/1.1 header fields. For entity-header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
このセクションは標準のすべてのHTTP/1.1のヘッダーフィールドの構文と意味論を定義します。 実体ヘッダーフィールドについて、送付者と受取人の両方がクライアントかサーバのどちらかについて言及します、だれが発信するか、そして、だれが実体を受けるかによって。
Fielding, et. al. Standards Track [Page 94] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[94ページ]RFC2068HTTP/1997年1月1.1日
14.1 Accept
14.1は受け入れます。
The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
応答において、許容しているあるメディアタイプを指定するのにAccept要求ヘッダーフィールドを使用できます。 ヘッダーを受け入れてください。要求が明確に小さい必要なタイプに制限されるのを示すのに使用できます、インラインイメージに関する要求に関するケースのように。
Accept = "Accept" ":"
#( media-range [ accept-params ] )
「=「受諾」を受け入れてください」:、」 #(メディア範囲[paramsを受け入れている])
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
「メディア範囲=、(「*/*」| (」 「*」) | 」 /(」 タイプ」 /「副-タイプ」)をタイプします)*(「」、;、パラメタ)
accept-params = ";" "q" "=" qvalue *( accept-extension )
「paramsを受け入れている=」;、」 「q」はqvalue*と「等しいです」。(拡大を受け入れます)です。
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
「拡大を受け入れている=」;、」 トークン[「=」(トークン| 引用文字列)]
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The media-range MAY include media type parameters that are applicable to that range.
そのすべての血液型亜型を示す「アスタリスク「*」キャラクタはメディアタイプを範囲に分類するのに使用されます、」 */*で」示しているすべてのメディアタイプと「タイプ/*」タイプ。 メディア範囲はその範囲に適切なメディア型引数を含むかもしれません。
Each media-range MAY be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (section 3.9). The default value is q=1.
1つ以上はparamsを受け入れてそれぞれのメディア範囲のあとに続くかもしれません、相対的品質要素を示すための「q」パラメタで始まって。 0〜1までの(もしあれば)のパラメタがメディア範囲パラメタを切り離す最初の「q」paramsを受け入れqvalueを使用して. 線質係数でそのメディア範囲のための相対的な度合いの好みをユーザかユーザエージェントを示すスケール(セクション3.9)。 デフォルト値はq=1です。
Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type parameters
in Accept. Future media types should be discouraged from
registering any parameter named "q".
以下に注意してください。 Accept拡大パラメタとメディア型引数を切り離す「q」パラメタ名の使用は歴史的な習慣のためです。 これはどんなメディアも防ぎますが、型引数はメディア範囲で使用されていて、IANAメディアにおける、どんな「q」パラメタの不足も考えて、そのようなイベントがありそうもないと信じられているということであるのからのAcceptのどんなメディア型引数のタイプ登録とまれな用法とも「q」を命名しました。 将来のメディアタイプは、「q」というどんなパラメタも示して、がっかりするべきです。
The example
例
Accept: audio/*; q=0.2, audio/basic
受け入れます: オーディオ/*。 オーディオ的、または、基本的なq=0.2
SHOULD be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in quality."
SHOULD、「私は、オーディオ/基礎を好みますが、それが品質において下に80%のマークの後に利用可能な最善であるならどんなオーディオタイプも私に送る」として、解釈されてください。
Fielding, et. al. Standards Track [Page 95] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[95ページ]RFC2068HTTP/1997年1月1.1日
If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then the server SHOULD send a 406 (not acceptable) response.
どんなAcceptヘッダーフィールドも存在していないなら、クライアントがすべてのメディアタイプを受け入れると思われます。 サーバが結合したAccept分野価値に従って許容できる応答を送ることができないならAcceptヘッダーフィールドが存在しているなら、サーバSHOULDは406(許容できない)応答を送ります。
A more elaborate example is
より入念な例はそうです。
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
受け入れます: テキスト/平野。 q=0.5、テキスト/html、テキスト/x-dvi。 q=0.8、テキスト/x-c
Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then send the text/x-dvi entity, and if that does not exist, send the text/plain entity."
口頭で、これは「テキスト/htmlとテキスト/x-cは都合のよいメディアタイプですが、彼らが存在しないなら、テキスト/x-dvi実体を送ってください、そして、それが存在しないなら、テキスト/明瞭な実体を送ってください」として解釈されるでしょう。
Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence. For example,
より特定のメディア範囲か特定のメディアタイプがメディア範囲をくつがえすことができます。 1つ以上のメディア範囲が与えられたタイプに適用されるなら、最も特定の参照には、先行があります。 例えば
Accept: text/*, text/html, text/html;level=1, */*
受け入れます: テキスト/*、テキスト/html、テキスト/html; =1を平らにする*/*
have the following precedence:
以下の先行を持ってください:
1) text/html;level=1
2) text/html
3) text/*
4) */*
1)テキスト/html; =1 2) テキスト/html3) テキスト/*4を)平らにしてください。 */*
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence which matches that type. For example,
線質係数が与えられたタイプに関連づけたメディアタイプは、メディア範囲を見つけることによって、そのタイプに合っている最も高い先行に決定しています。 例えば
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5
受け入れます: テキスト/*; q=0.3、テキスト/html; q=0.7、テキスト/html; レベル=1、テキスト/html; =2; q=0.4、*/*; q=0.5を平らにしてください。
would cause the following values to be associated:
以下の値が関連していることを引き起こすでしょう:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
テキスト/html; レベル= 1 = 1 テキスト/html=0.7テキスト/明瞭な=0.3イメージ/jpeg=0.5テキスト/html; レベル=2 = 0.4テキスト/html; レベル=3 = 0.7
Note: A user agent may be provided with a default set of quality
values for certain media ranges. However, unless the user agent is
a closed system which cannot interact with other rendering agents,
以下に注意してください。 ユーザエージェントは上質の値のデフォルトセットをある一定のメディア範囲に提供するかもしれません。 しかしながら、ユーザエージェントがクローズドシステムでないなら、どれが他のレンダリングエージェントと対話できないか。
Fielding, et. al. Standards Track [Page 96] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[96ページ]RFC2068HTTP/1997年1月1.1日
this default set should be configurable by the user.
このデフォルトセットはユーザが構成可能であるべきです。
14.2 Accept-Charset
14.2、Charsetを受け入れます。
The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special- purpose character sets to signal that capability to a server which is capable of representing documents in those character sets. The ISO- 8859-1 character set can be assumed to be acceptable to all user agents.
応答において、どんな文字集合が許容できるかを示すのにAccept-Charset要求ヘッダーフィールドを使用できます。 この分野は包括的であるか特別な目的文字集合がそれらの文字集合でドキュメントを表すことができるサーバにその能力を示すのを理解できるクライアントを許容します。 ISO8859-1文字集合がすべてのユーザエージェントにとって許容できると思うことができます。
Accept-Charset = "Accept-Charset" ":"
1#( charset [ ";" "q" "=" qvalue ] )
「Charsetを受け入れている=、「Charsetを受け入れる、」、」、:、」 1#(charset、[「」、;、「q」「=」qvalue)
Character set values are described in section 3.4. Each charset may be given an associated quality value which represents the user's preference for that charset. The default value is q=1. An example is
文字集合値はセクション3.4で説明されます。 そのcharsetのためにユーザの好みを表す関連上質の値を各charsetに与えるかもしれません。 デフォルト値はq=1です。 例はそうです。
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Charsetを受け入れます: iso-8859-5、ユニコード1-1; q=0.8
If no Accept-Charset header is present, the default is that any character set is acceptable. If an Accept-Charset header is present, and if the server cannot send a response which is acceptable according to the Accept-Charset header, then the server SHOULD send an error response with the 406 (not acceptable) status code, though the sending of an unacceptable response is also allowed.
どんなAccept-Charsetヘッダーも出席していないなら、デフォルトはどんな文字集合も許容できるということです。 サーバがAccept-Charsetヘッダーに従って許容できる応答を送ることができないならAccept-Charsetヘッダーが出席しているなら、サーバSHOULDは406(許容できない)ステータスコードによる誤り応答を送ります、また、容認できない応答の発信が許されていますが。
14.3 Accept-Encoding
14.3、コード化を受け入れます。
The Accept-Encoding request-header field is similar to Accept, but restricts the content-coding values (section 14.12) which are acceptable in the response.
Acceptをコード化している要求ヘッダーフィールドは、Acceptと同様ですが、応答で許容できる内容をコード化する値(セクション14.12)を制限します。
Accept-Encoding = "Accept-Encoding" ":"
#( content-coding )
「コード化を受け入れている=、「コード化を受け入れる、」、」、:、」 #(内容をコード化しています)です。
An example of its use is
使用に関する例はそうです。
Accept-Encoding: compress, gzip
コード化を受け入れます: 湿布、gzip
If no Accept-Encoding header is present in a request, the server MAY assume that the client will accept any content coding. If an Accept- Encoding header is present, and if the server cannot send a response which is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
どんなAcceptをコード化しているヘッダーも要求に出席していないなら、サーバは、クライアントがどんな満足しているコード化も受け入れると仮定するかもしれません。 サーバがAcceptをコード化しているヘッダーに従って許容できる応答を送ることができないならヘッダーをコード化するAcceptが存在しているなら、サーバSHOULDは406(Acceptableでない)ステータスコードによる誤り応答を送ります。
Fielding, et. al. Standards Track [Page 97] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[97ページ]RFC2068HTTP/1997年1月1.1日
An empty Accept-Encoding value indicates none are acceptable.
空のAcceptをコード化している値は、なにも許容できないのを示します。
14.4 Accept-Language
14.4、言語を受け入れます。
The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request.
Accept-言語要求ヘッダーフィールドは、Acceptと同様ですが、応答として好まれる自然言語のセットを要求に制限します。
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
「言語を受け入れている=、「言語を受け入れる、」、」、:、」 1#(言語範囲、[「」、;、「q」「=」qvalue)
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
言語範囲=((1*8ALPHA*(「-」1*8ALPHA))| 「*」)
Each language-range MAY be given an associated quality value which represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example,
その範囲によって指定された言語のためのユーザの好みの見積りを表す関連上質の値をそれぞれの言語範囲に与えるかもしれません。 上質の値は「q=1インチ」をデフォルトとします。 例えば
Accept-Language: da, en-gb;q=0.8, en;q=0.7
言語を受け入れます: da、アン-gb; q=0.8、アン; q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first tag character following the prefix is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in the Accept-Language field.
以下を意味するでしょう。 「私は、デンマーク語を好みますが、英語のイギリス英語と他のタイプを受け入れるつもりです。」 まさにタグと等しい、またはまさにタグの接頭語と等しいなら、言語範囲は、接頭語に従う最初のタグキャラクタが「-」であるように言語タグに合っています。 言語を受け入れている分野に存在しているなら、特別な範囲「*」は言語を受け入れている分野の現在のいかなる他の範囲によっても合わせられたというわけではないあらゆるタグに合っています。
Note: This use of a prefix matching rule does not imply that
language tags are assigned to languages in such a way that it is
always true that if a user understands a language with a certain
tag, then this user will also understand all languages with tags
for which this tag is a prefix. The prefix rule simply allows the
use of prefix tags if this is the case.
以下に注意してください。 接頭語マッチング規則のこの使用は、言語タグがまた、ユーザが、あるタグで言語を理解しているとこのユーザがこのタグが接頭語であるタグですべての言語を理解しているのが、いつも本当であるような方法で言語に割り当てられるのを含意しません。 接頭語規則はこれがそうであるなら単に接頭語タグの使用を許します。
The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language- range in the field that matches the language-tag. If no language- range in the field matches the tag, the language quality factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable.
Accept-言語分野によって言語タグに割り当てられた言語線質係数は言語タグに合っている分野の最も長い言語範囲の上質の値です。 その分野でどんな言語範囲もタグに合っていないなら、線質係数が割り当てた言語は0です。 どんなAccept-言語ヘッダーも要求に出席していないなら、サーバSHOULDは、すべての言語が等しく許容できると仮定します。 Accept-言語ヘッダーが出席しているなら、線質係数より多くの0が割り当てられるすべての言語が許容できます。
It may be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic preferences of the user in every request. For a discussion of this issue, see
それは、あらゆる要求における、ユーザの完全な言語学の好みでAccept-言語ヘッダーを送るためにユーザへのプライバシー期待に合わないかもしれません。 この問題の議論に関しては、見てください。
Fielding, et. al. Standards Track [Page 98] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[98ページ]RFC2068HTTP/1997年1月1.1日
section 15.7.
セクション15.7。
Note: As intelligibility is highly dependent on the individual
user, it is recommended that client applications make the choice of
linguistic preference available to the user. If the choice is not
made available, then the Accept-Language header field must not be
given in the request.
以下に注意してください。 明瞭さが個々のユーザに非常に依存しているように、クライアントアプリケーションで言語学の好みの選択がユーザにとって利用可能になるのは、お勧めです。 選択を利用可能にしないなら、要求でAccept-言語ヘッダーフィールドを与えてはいけません。
14.5 Accept-Ranges
14.5、範囲を受け入れます。
The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource:
Accept-範囲応答ヘッダ分野で、サーバはリソースに関する範囲要求の承認を示すことができます:
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
「範囲を受け入れている=、「範囲を受け入れる、」、」、:、」 許容できる範囲
acceptable-ranges = 1#range-unit | "none"
許容できる範囲は1#レンジ・ユニットと等しいです。| 「なにも」
Origin servers that accept byte-range requests MAY send
バイト範囲要求を受け入れる発生源サーバは発信するかもしれません。
Accept-Ranges: bytes
範囲を受け入れます: バイト
but are not required to do so. Clients MAY generate byte-range requests without having received this header for the resource involved.
しかし、そうするのが必要ではありません。 クライアントはリソースのためにこのヘッダーを受けたことのない要求がかかわったバイト範囲を生成するかもしれません。
Servers that do not accept any kind of range request for a resource MAY send
リソースに関するどんな種類の範囲要求も受け入れないサーバは発信するかもしれません。
Accept-Ranges: none
範囲を受け入れます: なし
to advise the client not to attempt a range request.
クライアントが範囲要求を試みないようにアドバイスするために。
14.6 Age
14.6 時代
The Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) was generated at the origin server. A cached response is "fresh" if its age does not exceed its freshness lifetime. Age values are calculated as specified in section 13.2.3.
Age応答ヘッダ分野は送付者の応答(または、再合法化)が発生源サーバで生成されて以来の時間の見積りを伝えます。時代が新しさ生涯を超えていないなら、キャッシュされた応答は「新鮮です」。 時代値はセクション13.2.3で指定されるように計算されます。
Age = "Age" ":" age-value
「=「時代」時代」:、」 時代値
age-value = delta-seconds
デルタ時代値=秒
Age values are non-negative decimal integers, representing time in seconds.
秒に時間を表して、時代値は非負の10進整数です。
Fielding, et. al. Standards Track [Page 99] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[99ページ]RFC2068HTTP/1997年1月1.1日
If a cache receives a value larger than the largest positive integer it can represent, or if any of its age calculations overflows, it MUST transmit an Age header with a value of 2147483648 (2^31). HTTP/1.1 caches MUST send an Age header in every response. Caches SHOULD use an arithmetic type of at least 31 bits of range.
キャッシュが表すことができる中で最も大きい正の整数より大きい値を受けるか、または時代計算のどれかがあふれるなら、それは2147483648(2^31)の値でAgeヘッダーを伝えなければなりません。 HTTP/1.1のキャッシュがあらゆる応答でAgeヘッダーを送らなければなりません。 SHOULDが少なくとも31人の算術型にビットを使用するキャッシュは及びます。
14.7 Allow
14.7は許容します。
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response.
Allow実体ヘッダーフィールドはRequest-URIによって特定されたリソースによってサポートされたメソッドのセットを記載します。 この分野の目的はリソースに関連している有効なメソッドについて厳密に受取人に知らせることです。 Allowヘッダーフィールドは405(メソッドNot Allowed)応答で存在していなければなりません。
Allow = "Allow" ":" 1#method
「=「許容」を許してください」:、」 1#メソッド
Example of use:
使用に関する例:
Allow: GET, HEAD, PUT
許容します: 置かれて、得てください、そして、向かってください。
This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value SHOULD be followed. The actual set of allowed methods is defined by the origin server at the time of each request.
この分野のために、クライアントは他のメソッドを試みることができません。 しかしながら、Allowヘッダーフィールドによって与えられた指摘はSHOULDを評価します。続かれています。 実際の許容メソッドは各要求時点で、発生源サーバによって定義されます。
The Allow header field MAY be provided with a PUT request to recommend the methods to be supported by the new or modified resource. The server is not required to support these methods and SHOULD include an Allow header in the response giving the actual supported methods.
新しいか変更されたリソースによってサポートするべきメソッドを推薦するというPUT要求をAllowヘッダーフィールドに提供するかもしれません。 サーバはこれらのメソッドをサポートするのに必要ではありません、そして、SHOULDは実際のサポートしているメソッドを与えながら、応答にAllowヘッダーを含んでいます。
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent MAY have other means of communicating with the origin server.
すべてのメソッドが指定したのを理解していなくても、プロキシはAllowヘッダーフィールドを変更してはいけません、ユーザエージェントには発生源サーバとコミュニケートする他の手段があるかもしれないので。
The Allow header field does not indicate what methods are implemented at the server level. Servers MAY use the Public response-header field (section 14.35) to describe what methods are implemented on the server as a whole.
Allowヘッダーフィールドは、どんなメソッドがサーバレベルで実装されるかを示しません。 サーバは、どんなメソッドが全体でサーバで実装されるかを説明するのに、Public応答ヘッダ分野(セクション14.35)を使用するかもしれません。
14.8 Authorization
14.8 承認
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--MAY do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
サーバで通常それ自体を認証しますが、401応答--要求でAuthorization要求ヘッダーフィールドを含んでいることによってそうするかもしれないのを受けた後に必ず認証したがっているというわけではないユーザエージェント。 Authorization分野価値は要求されているリソースの分野にユーザエージェントの認証情報を含む資格証明書から成ります。
Fielding, et. al. Standards Track [Page 100] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[100ページ]RFC2068HTTP/1997年1月1.1日
Authorization = "Authorization" ":" credentials
「承認=「承認」」:、」 資格証明書
HTTP access authentication is described in section 11. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm.
HTTPアクセス認証はセクション11で説明されます。 同じ資格証明書SHOULD、要求が認証されるか、そして、分野を指定しました。この分野の中の他のすべての要求において、有効であってください。
When a shared cache (see section 13.7) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
共有されたキャッシュ(セクション13.7を見る)がAuthorization分野を含む要求を受け取るとき、回答として対応する応答をいかなる他の要求にも返してはいけません、以下の特定の例外の1つが持ちこたえない場合:
1. If the response includes the "proxy-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but a proxy cache MUST first revalidate it with
the origin server, using the request-headers from the new request
to allow the origin server to authenticate the new request.
2. If the response includes the "must-revalidate" Cache-Control
directive, the cache MAY use that response in replying to a
subsequent request, but all caches MUST first revalidate it with
the origin server, using the request-headers from the new request
to allow the origin server to authenticate the new request.
3. If the response includes the "public" Cache-Control directive, it
may be returned in reply to any subsequent request.
1. 応答が発生源サーバで「プロキシ-revalidate」Cache-コントロール指示、応答が中でその後の要求、しかし、キャッシュが答えなければならないプロキシに答えて、それが最初に再有効にされるキャッシュ5月の使用を含んでいるなら、発生源サーバが新しい要求を認証するのを許容するという新しい要求から要求ヘッダーを使用します。 2. 応答が発生源サーバで「必須-revalidate」Cache-コントロール指示、応答が中でしかし、その後の要求、キャッシュがそうしなければならないすべてに答えて、それが最初に再有効にされるキャッシュ5月の使用を含んでいるなら、発生源サーバが新しい要求を認証するのを許容するという新しい要求から要求ヘッダーを使用します。 3. 応答が「公共」のCache-コントロール指示を含んでいるなら、どんなその後の要求に対してそれを返すかもしれません。
14.9 Cache-Control
14.9 キャッシュ制御
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive should be given in the response.
Cache-コントロールの一般的なヘッダーフィールドは、要求/応答チェーンに沿ってメカニズムをキャッシュして、すべてで従わなければならない指示を指定するのに使用されます。 指示はキャッシュが逆に要求か応答を妨げるのを防ぐことを意図する振舞いを指定します。 これらの指示はアルゴリズムをキャッシュするデフォルトを通常くつがえします。要求における、指示の存在が、同じ指示が応答で与えられるべきであるのを含意しないので、キャッシュ指示は単方向です。
Note that HTTP/1.0 caches may not implement Cache-Control and may
only implement Pragma: no-cache (see section 14.32).
HTTP/1.0のキャッシュがCache-コントロールを実装しないで、Pragmaを実装するだけであるかもしれないことに注意してください: キャッシュしません(セクション14.32を見ます)。
Cache directives must be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache- directive for a specific cache.
プロキシかゲートウェイアプリケーションでキャッシュ指示を通り抜けなければなりません、そのアプリケーションへのそれらの意味にかかわらず、指示が要求/応答チェーンに沿ったすべての受取人に適切であるかもしれないので。 特定のキャッシュのためのキャッシュ指示を指定するのは可能ではありません。
Cache-Control = "Cache-Control" ":" 1#cache-directive
「キャッシュ制御は「キャッシュ制御」と等しい」:、」 1#キャッシュ指示
cache-directive = cache-request-directive
| cache-response-directive
キャッシュ指示=キャッシュ要求指示| キャッシュ応答指示
Fielding, et. al. Standards Track [Page 101] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[101ページ]RFC2068HTTP/1997年1月1.1日
cache-request-directive =
"no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "max-age" "=" delta-seconds
| "max-stale" [ "=" delta-seconds ]
| "min-fresh" "=" delta-seconds
| "only-if-cached"
| cache-extension
キャッシュ要求指示=「キャッシュがありません」、[「=」<、「>1#フィールド名<、「>]」| 「店がありません」| 「最大時代」「=」デルタ秒| 「最大聞き古したである」[「=」デルタ秒]。| 「分新鮮である」「=」デルタ秒| 「キャッシュされる場合にだけ」| キャッシュ拡大
cache-response-directive =
"public"
| "private" [ "=" <"> 1#field-name <"> ]
| "no-cache" [ "=" <"> 1#field-name <"> ]
| "no-store"
| "no-transform"
| "must-revalidate"
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
キャッシュ応答指示=「公衆」| 「個人的である」、[「=」<、「>1#フィールド名<、「>]」| 「キャッシュがありません」、[「=」<、「>1#フィールド名<、「>]」| 「店がありません」| 「変形しないでください」| 「必須-revalidate」| 「プロキシ-revalidate」| 「最大時代」「=」デルタ秒| キャッシュ拡大
cache-extension = token [ "=" ( token | quoted-string ) ]
キャッシュ拡大はトークンと等しいです。[「=」(トークン| 引用文字列)]
When a directive appears without any 1#field-name parameter, the directive applies to the entire request or response. When such a directive appears with a 1#field-name parameter, it applies only to the named field or fields, and not to the rest of the request or response. This mechanism supports extensibility; implementations of future versions of the HTTP protocol may apply these directives to header fields not defined in HTTP/1.1.
指示が少しも1#フィールド名パラメタなしで現れるとき、指示は全体の要求か応答に適用されます。 そのような指示が1#フィールド名パラメタと共に現れるとき、それは要求か応答の残りではなく、命名された分野か分野だけに適用されます。 このメカニズムは伸展性をサポートします。 HTTPプロトコルの将来のバージョンの実装はHTTP/1.1で定義されなかったヘッダーフィールドにこれらの指示を適用するかもしれません。
The cache-control directives can be broken down into these general categories:
キャッシュ制御指示はこれらの一般的なカテゴリへ砕けている場合があります:
o Restrictions on what is cachable; these may only be imposed by the
origin server.
o Restrictions on what may be stored by a cache; these may be imposed
by either the origin server or the user agent.
o Modifications of the basic expiration mechanism; these may be
imposed by either the origin server or the user agent.
o Controls over cache revalidation and reload; these may only be
imposed by a user agent.
o Control over transformation of entities.
o Extensions to the caching system.
o キャッシュ可能であることに関する制限。 これらは発生源サーバによって課されるだけであるかもしれません。o Restrictionsはキャッシュによって何に関して保存されるかもしれないか。 これらは基本的な満了メカニズムの発生源サーバかユーザエージェントのどちらか. o Modificationsによって課されるかもしれません。 これらは、キャッシュ再合法化の上で発生源サーバかユーザエージェントのどちらか. o Controlsによって課されて、再び荷を積むかもしれません。 これらは実体o Extensionsの変換の上でaユーザエージェントo Controlによってキャッシュシステムに課されるだけであるかもしれません。
Fielding, et. al. Standards Track [Page 102] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[102ページ]RFC2068HTTP/1997年1月1.1日
14.9.1 What is Cachable
14.9.1 Cachableは何ですか?
By default, a response is cachable if the requirements of the request method, request header fields, and the response status indicate that it is cachable. Section 13.4 summarizes these defaults for cachability. The following Cache-Control response directives allow an origin server to override the default cachability of a response:
デフォルトで、要求メソッド、要求ヘッダーフィールド、および応答状態の要件が、それがキャッシュ可能であることを示すなら、応答はキャッシュ可能です。 セクション13.4はcachabilityのためにこれらのデフォルトをまとめます。 以下のCache-操舵応答指示で、発生源サーバは応答のデフォルトcachabilityをくつがえすことができます:
public Indicates that the response is cachable by any cache, even if it would normally be non-cachable or cachable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)
応答がそうである公共のIndicatesはどんなキャッシュでもキャッシュ可能します、それが非共有されたキャッシュだけの中で通常非キャッシュ可能であるか、またはキャッシュ可能であっても。 (また、追加詳細に関してAuthorization、セクション14.8を見てください。)
private Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache may cache the response.
応答メッセージのすべてか一部がそうである個人的なIndicatesはシングルユーザーのために意図して、共有されたキャッシュによってキャッシュされてはいけません。 これで、発生源サーバは応答の指定された部品が1人のユーザだけのために意図して、他のユーザによる要求のために有効回答でないと述べることができます。 個人的な(非共有された)キャッシュは応答をキャッシュするかもしれません。
Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.
以下に注意してください。 個人的であるという単語のこの用法は、応答がどこでキャッシュされるかもしれなくて、メッセージ内容のプライバシーを確実にすることができないかを制御するだけです。
no-cache Indicates that all or part of the response message MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
どこでもキャッシュされていた状態で応答メッセージのすべてか一部があるはずがないIndicatesをキャッシュしないでください。 これで、発生源サーバは、クライアント要求への聞き古した応答を返すために構成されたキャッシュでさえキャッシュするのを防ぐことができます。
Note: Most HTTP/1.0 caches will not recognize or obey this directive.
以下に注意してください。 ほとんどのHTTP/1.0のキャッシュは、この指示に認識もしませんし、従いもしないでしょう。
14.9.2 What May be Stored by Caches
14.9.2 どんな5月に、StoredがCachesでありますか?
The purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and may be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or any response to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non-shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.
店がない指示の目的は機密情報(例えばバックアップテープで)の不注意なリリースか保有を防ぐことです。 店がない指示は全体のメッセージに適用して、応答か要求で送るかもしれません。 要求で送るなら、キャッシュはそれへのこの要求かどんな応答のどちらかの少しの部分も保存してはいけません。 応答で送るなら、キャッシュはそれを引き出したこの応答か要求のどちらかの少しの部分も保存してはいけません。 この指示は非共有されて共有の両方にされたキャッシュに適用されます。 非揮発性記憶装置でこのような関係においてはキャッシュが故意に情報を保存してはいけない手段を「保存してはいけなく」て、それを進めた後に、できるだけ即座に揮発性記憶装置から情報を取り除くベストエフォート型試みをしなければなりません。
Fielding, et. al. Standards Track [Page 103] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[103ページ]RFC2068HTTP/1997年1月1.1日
Even when this directive is associated with a response, users may explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers may store such responses as part of their normal operation.
この指示が応答に関連してさえいるとき、ユーザはキャッシュシステム(例えば、aで、対話は「節約される」)の外に明らかにそのような応答を保存するかもしれません。 歴史バッファは彼らの通常操作の一部のような応答を保存するかもしれません。
The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive may improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficient mechanism for ensuring privacy. In particular, malicious or compromised caches may not recognize or obey this directive; and communications networks may be vulnerable to eavesdropping.
この指示の目的はデータ構造をキャッシュするために情報の偶発的放出に関して思いがけないアクセスで心配している確信しているユーザとサービス作者の述べられた必要条件を満たすことです。 いくつかの場合、この指示の使用がプライバシーを改良しているかもしれない間、私たちは、それがどんな方法で秘密を守るための信頼できるか十分なメカニズムでないとも警告します。 悪意があるか感染しているキャッシュは、この指示に特に、認識しませんし、また従わないかもしれません。 そして、通信網は盗聴に被害を受け易いかもしれません。
14.9.3 Modifications of the Basic Expiration Mechanism
14.9.3 基本的な満了メカニズムの変更
The expiration time of an entity may be specified by the origin server using the Expires header (see section 14.21). Alternatively, it may be specified using the max-age directive in a response.
実体の満了時間は、発生源サーバによってExpiresヘッダーを使用することで指定されるかもしれません(セクション14.21を見てください)。 あるいはまた、それは、応答における最大時代指示を使用することで指定されるかもしれません。
If a response includes both an Expires header and a max-age directive, the max-age directive overrides the Expires header, even if the Expires header is more restrictive. This rule allows an origin server to provide, for a given response, a longer expiration time to an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This may be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks.
応答がExpiresヘッダーと最大時代指示の両方を含んでいるなら、最大時代指示はExpiresヘッダーをくつがえします、Expiresヘッダーがさらに制限しているなら。 発生源サーバはこの規則によって提供されます、与えられた応答のために、HTTP/1.1(後で)キャッシュへのHTTP/1.0キャッシュより長い満了時間。。 あるHTTP/1.0のキャッシュが恐らく反連動している時計のため下品に時代か満了時間について計算するなら、これは役に立つかもしれません。
Note: most older caches, not compliant with this specification, do
not implement any Cache-Control directives. An origin server
wishing to use a Cache-Control directive that restricts, but does
not prevent, caching by an HTTP/1.1-compliant cache may exploit the
requirement that the max-age directive overrides the Expires
header, and the fact that non-HTTP/1.1-compliant caches do not
observe the max-age directive.
以下に注意してください。 ほとんどの、より古いこの仕様で対応でないキャッシュはどんなCache-コントロール指示も実装しません。 発生源サーバが制限しますが、それが防がないCache-コントロール指示を使用したいと思う場合、1.1HTTP/対応することのキャッシュによるキャッシュは最大時代指示がExpiresヘッダーをくつがえすという要件、および非HTTPの、または、1.1対応することのキャッシュが最大時代指示を観測しないという事実を利用するかもしれません。
Other directives allow an user agent to modify the basic expiration mechanism. These directives may be specified on a request:
他の指示で、ユーザエージェントは基本的な満了メカニズムを変更できます。 これらの指示は要求のときに指定されるかもしれません:
max-age
Indicates that the client is willing to accept a response whose age
is no greater than the specified time in seconds. Unless max-stale
directive is also included, the client is not willing to accept a
stale response.
秒に時代が指定されたより時間以下である応答を受け入れることを望んでいた状態で、クライアントがそうであるIndicatesの最大に年をとってください。 また、最大聞き古した指示が含まれていない場合、クライアントは聞き古した応答を受け入れることを望んでいません。
min-fresh
Indicates that the client is willing to accept a response whose
freshness lifetime is no less than its current age plus the
クライアントが新しさ寿命が少なくともその電流である応答を受け入れることを望んでいる分新鮮なIndicatesはそのうえ、年をとります。
Fielding, et. al. Standards Track [Page 104] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[104ページ]RFC2068HTTP/1997年1月1.1日
specified time in seconds. That is, the client wants a response
that will still be fresh for at least the specified number of
seconds.
秒の時に指定されています。 すなわち、クライアントはまだ秒の指定された数に新鮮になっている応答が欲しいです。
max-stale
Indicates that the client is willing to accept a response that has
exceeded its expiration time. If max-stale is assigned a value,
then the client is willing to accept a response that has exceeded
its expiration time by no more than the specified number of
seconds. If no value is assigned to max-stale, then the client is
willing to accept a stale response of any age.
満了時間を超えていた応答を受け入れることを望んでいた状態で、クライアントがそうであるIndicatesは最大に聞き古したになってください。 最大聞き古したである、割り当てられたa値、クライアントが指定された数だけに応じてそれが持っている応答を受け入れるのが満了時間を超えていたことを望んでいるその時は秒ですか? 値が全く最大に古くさくなるように割り当てられないなら、クライアントは、どんな時代の聞き古した応答も受け入れても構わないと思っています。
If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured to override the expiration time of a response, the cache MUST attach a Warning header to the stale response, using Warning 10 (Response is stale).
要求の最大聞き古した指示のためのどちらか、またはキャッシュが聞き古した応答を返すか、または応答の満了時間をくつがえすために構成されるので、キャッシュはWarningヘッダーを聞き古した応答に取り付けなければなりません、Warning10を使用して(応答は聞き古したです)。
14.9.4 Cache Revalidation and Reload Controls
14.9.4 キャッシュRevalidationと再ロードコントロール
Sometimes an user agent may want or need to insist that a cache revalidate its cache entry with the origin server (and not just with the next cache along the path to the origin server), or to reload its cache entry from the origin server. End-to-end revalidation may be necessary if either the cache or the origin server has overestimated the expiration time of the cached response. End-to-end reload may be necessary if the cache entry has become corrupted for some reason.
ユーザエージェントは、時々、欲しい、またはキャッシュが発生源サーバ(そして、まさしく次で、ずっと発生源サーバに経路をキャッシュしない)でキャッシュエントリーを再有効にすると主張するか、または発生源サーバからキャッシュエントリーを再び積む必要があるかもしれません。キャッシュか発生源サーバのどちらかがキャッシュされた応答の満了時間を過大評価したなら、終わりから終わりへの再合法化が必要であるかもしれません。 キャッシュエントリーがある理由で崩壊するようになったなら、終わりから終わりへの再ロードが必要であるかもしれません。
End-to-end revalidation may be requested either when the client does not have its own local cached copy, in which case we call it "unspecified end-to-end revalidation", or when the client does have a local cached copy, in which case we call it "specific end-to-end revalidation."
クライアントに地方のキャッシュされたコピーがあるとき、クライアントにはそれ自身の地方のキャッシュされたコピーがないか、その場合、私たちが、それを「終わりから終わりへの不特定の再合法化」と呼ぶか、またはその場合、私たちが、それを「終わりから終わりへの特定の再合法化」と呼ぶとき、終わりから終わりへの再合法化は要求されるかもしれません。
The client can specify these three kinds of action using Cache- Control request directives:
クライアントはCacheコントロール要求指示を使用することでこれらの3種類の動作を指定できます:
End-to-end reload
The request includes a "no-cache" Cache-Control directive or, for
compatibility with HTTP/1.0 clients, "Pragma: no-cache". No field
names may be included with the no-cache directive in a request. The
server MUST NOT use a cached copy when responding to such a
request.
または、終わらせる終わりがインクルードaがCache-コントロール指示を「キャッシュしない」という要求を再び積む、HTTP/1.0人のクライアントとの互換性のために「Pragma:」 「キャッシュしません」。 フィールド名は全く要求におけるキャッシュがない指示で含まれないかもしれません。 そのような要求に応じるとき、サーバはキャッシュされたコピーを使用してはいけません。
Specific end-to-end revalidation
The request includes a "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
特定の終わりから終わりへの要求がaを含む再合法化は「0インチの=Cache-コントロール指示の最大に年をとります」。(発生源サーバへの経路に沿った各キャッシュは指示によってサーバ次のキャッシュかイニシャルでやむを得ずもしあればそれ自身のエントリーを再有効にします)。
Fielding, et. al. Standards Track [Page 105] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[105ページ]RFC2068HTTP/1997年1月1.1日
request includes a cache-validating conditional with the client's
current validator.
要求はクライアントのものと共に条件付きのキャッシュ有効にすることの現在のvalidatorを含んでいます。
Unspecified end-to-end revalidation
The request includes "max-age=0" Cache-Control directive, which
forces each cache along the path to the origin server to revalidate
its own entry, if any, with the next cache or server. The initial
request does not include a cache-validating conditional; the first
cache along the path (if any) that holds a cache entry for this
resource includes a cache-validating conditional with its current
validator.
終わりから終わりへの要求が含む不特定の再合法化は「. 初期の要求が次のキャッシュかサーバで条件付きの状態でキャッシュ有効にすることを少しも含んでいないなら経路に沿ってrevalidateのそれ自身のエントリーへの発生源サーバに各キャッシュを強制する0インチの=Cache-コントロール指示の最大に年をとります」。 このリソースのためのキャッシュエントリーを保持する経路(もしあれば)に沿った最初のキャッシュは電流で条件付きのキャッシュ有効にするvalidatorを含んでいます。
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator may differ from the validator currently stored with the cache entry. In this case, the cache may use either validator in making its own request without affecting semantic transparency.
中間的キャッシュがrevalidateのそれ自身のキャッシュエントリーへの0最大時代=指示によって強制されて、クライアントが要求でそれ自身のvalidatorを供給したとき、供給されたvalidatorは現在キャッシュエントリーで保存されているvalidatorと異なるかもしれません。 この場合、キャッシュは意味の透明性に影響しないでそれ自身の要求をする際にvalidatorを使用するかもしれません。
However, the choice of validator may affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache should return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache should compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new entity with a 200 (OK) response.
しかしながら、validatorの選択は性能に影響するかもしれません。 最も良いアプローチは要求をするとき、中間的キャッシュがそれ自身のvalidatorを使用することです。 サーバが304(Modifiedでない)で返答するなら、キャッシュは200(OK)応答と共に現在有効にされたコピーをクライアントに返すべきです。 しかしながら、サーバが新しい実体とキャッシュvalidatorで返答するなら、中間的キャッシュはクライアントの要求に提供されたものと返されたvalidatorを比べるべきです、強い比較関数を使用して。 クライアントのvalidatorがサーバの発生源ものと等しいなら、中間的キャッシュは単に、304(Modifiedでない)を返します。 さもなければ、それは200(OK)応答と共に新しい実体を返します。
If a request includes the no-cache directive, it should not include min-fresh, max-stale, or max-age.
要求がキャッシュがない指示を含んでいるなら、それは生々しい最大聞き古した、または時代に最大限にしている分を含むべきではありません。
In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those responses that it currently has stored, and not to reload or revalidate with the origin server. To do this, the client may include the only-if-cached directive in a request. If it receives this directive, a cache SHOULD either respond using a cached entry that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request MAY be forwarded within that group of caches.
非常に不十分なネットワークの接続性の倍などのいくつかの場合では、クライアントは発生源サーバがあるそれが現在保存したそれらの応答だけを返して、再び荷を積まないキャッシュかrevalidateが欲しいかもしれません。これをするために、クライアントは要求における唯一の、しかし、キャッシュされた指示を入れるかもしれません。 この指示を受けるなら、キャッシュSHOULDは要求の他の規制と一致したキャッシュされたエントリーを使用することで応じるか、または504(ゲートウェイTimeout)状態で応じます。 しかしながら、統一されたシステムとして良い内部の接続性でキャッシュのグループを経営しているなら、キャッシュのそのグループの中でそのような要求を転送するかもしれません。
Because a cache may be configured to ignore a server's specified expiration time, and because a client request may include a max-stale directive (which has a similar effect), the protocol also includes a
キャッシュがサーバの指定された満了時間を無視するために構成されるかもしれなくて、クライアント要求が最大聞き古した指示(同様の効果を持っている)を含むかもしれないので、また、プロトコルはaを含んでいます。
Fielding, et. al. Standards Track [Page 106] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[106ページ]RFC2068HTTP/1997年1月1.1日
mechanism for the origin server to require revalidation of a cache entry on any subsequent use. When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache must do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.)
発生源サーバがどんなその後の使用のときにもキャッシュエントリーを再合法化に要求するメカニズム。 必須-revalidate指示であるときに、キャッシュ、そのキャッシュで受け取られていている応答が最初に再有効にしないでその後の要求に反応するのに聞き古したであるなった後にエントリーを使用してはいけない現在のコネはそれです。発生源サーバで。(すなわち、キャッシュは毎回終わりから終わりに再合法化しなければなりません、唯一発生源サーバのExpiresか最大時代値に基づいて、キャッシュされた応答が聞き古したである。)
The must-revalidate directive is necessary to support reliable operation for certain protocol features. In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.
必須-revalidate指示が、あるプロトコル機能のための信頼できる操作をサポートするのに必要です。 すべての事情では、HTTP/1.1キャッシュは必須-revalidate指示に従わなければなりません。 キャッシュがどんな理由でも発生源サーバに達することができないなら、特に、それは504(ゲートウェイTimeout)応答を生成しなければなりません。
Servers should send the must-revalidate directive if and only if failure to revalidate a request on the entity could result in incorrect operation, such as a silently unexecuted financial transaction. Recipients MUST NOT take any automated action that violates this directive, and MUST NOT automatically provide an unvalidated copy of the entity if revalidation fails.
サーバが必須-revalidate指示を送るべきである、単に、実体に関する要求を再有効にしない場合、不正確な操作(静かに非実行された金融取引としてのそのようなもの)をもたらすかもしれません。 受取人は、この指示に違反する少しの自動化された行動も取ってはいけなくて、再合法化が失敗するなら、自動的に実体の非有効にされたコピーを提供してはいけません。
Although this is not recommended, user agents operating under severe connectivity constraints may violate this directive but, if so, MUST explicitly warn the user that an unvalidated response has been provided. The warning MUST be provided on each unvalidated access, and SHOULD require explicit user confirmation.
これはお勧めではありませんが、厳しい接続性規制で働いているユーザエージェントはしかしそうだとすれば、この指示に違反するかもしれません。明らかに、非有効にされた応答が提供されたとユーザに警告しなければなりません。 それぞれの非有効にされたアクセスのときに警告を提供しなければなりません、そして、SHOULDは明白なユーザ確認を必要とします。
The proxy-revalidate directive has the same meaning as the must- revalidate directive, except that it does not apply to non-shared user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later return the response without needing to revalidate it (since it has already been authenticated once by that user), while still requiring proxies that service many users to revalidate each time (in order to make sure that each user has been authenticated). Note that such authenticated responses also need the public cache control directive in order to allow them to be cached at all.
プロキシ-revalidate指示には、必須revalidate指示と同じ意味があります、それが非共有されたユーザエージェントキャッシュに適用されないのを除いて。 ユーザのキャッシュがまだその都度多くのユーザにrevalidateにサービスを提供するプロキシを必要としている間(各ユーザが認証されたのを確実にするために)、それ(それが一度そのユーザによって既に認証されたことがあるので)をrevalidateに必要としないで応答を保存して、後で返すことを許可するという認証された要求への応答のときにそれを使用できます。 また、そのような認証された応答がそれらが全くキャッシュされるのを許容するために公共のキャッシュ制御指示を必要とすることに注意してください。
14.9.5 No-Transform Directive
14.9.5 指示を変えないでください。
Implementers of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A proxy might, for example, convert between image formats in order to save cache space or to reduce the amount of traffic on a slow link. HTTP has to date been silent on these transformations.
中間的キャッシュ(プロキシ)のImplementersは、ある実体本体のメディアタイプを変換するのが役に立つのがわかりました。 例えば、プロキシは、キャッシュスペースを節約するか、または遅いリンクでトラフィックの量を減少させるために画像形式の間で変換するかもしれません。 HTTPはこれまでこれらの変換で静かです。
Fielding, et. al. Standards Track [Page 107] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[107ページ]RFC2068HTTP/1997年1月1.1日
Serious operational problems have already occurred, however, when these transformations have been applied to entity bodies intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication, all depend on receiving an entity body that is bit for bit identical to the original entity-body.
しかしながら、これらの変換が、ある種類のアプリケーションのために意図する実体本体に適用されたとき、重大な運転上の問題は既に起こりました。 例えば、医療画像処理のアプリケーション(科学的データ分析と終わりから終わりへの認証を使用するもの)は、オリジナルの実体本体と同じビットのために噛み付かれる実体本体を受けるのにすべてよります。
Therefore, if a response includes the no-transform directive, an intermediate cache or proxy MUST NOT change those headers that are listed in section 13.5.2 as being subject to the no-transform directive. This implies that the cache or proxy must not change any aspect of the entity-body that is specified by these headers.
したがって、応答が変換がない指示を含んでいるなら、中間的キャッシュかプロキシが変換がない指示を受けることがあるとしてセクション13.5.2で記載されているそれらのヘッダーを変えてはいけません。 これは、キャッシュかプロキシがこれらのヘッダーによって指定される実体本体の少しの局面も変えてはいけないのを含意します。
14.9.6 Cache Control Extensions
14.9.6 キャッシュ制御拡大
The Cache-Control header field can be extended through the use of one or more cache-extension tokens, each with an optional assigned value. Informational extensions (those which do not require a change in cache behavior) may be added without changing the semantics of other directives. Behavioral extensions are designed to work by acting as modifiers to the existing base of cache directives. Both the new directive and the standard directive are supplied, such that applications which do not understand the new directive will default to the behavior specified by the standard directive, and those that understand the new directive will recognize it as modifying the requirements associated with the standard directive. In this way, extensions to the Cache-Control directives can be made without requiring changes to the base protocol.
1つ以上のキャッシュ拡大トークンの使用でCache-コントロールヘッダーフィールドを広げることができます、それぞれ任意の割り当てられた値で。 他の指示の意味論を変えないで、情報の拡大(キャッシュの振舞いにおける変化を必要としないもの)は加えられるかもしれません。 行動の拡大は、修飾語としてキャッシュ指示の存立基盤に機能することによって働くように設計されています。 新しい指示と標準の指示の両方を供給します、新しい指示を理解していないアプリケーションが標準の指示で指定された振舞いをデフォルトとして、新しい指示を理解している人が標準の指示に関連している要件を変更するとそれを認識するように。 このように、ベースプロトコルへの変化を必要としないで、Cache-コントロール指示への拡大をすることができます。
This extension mechanism depends on a HTTP cache obeying all of the cache-control directives defined for its native HTTP-version, obeying certain extensions, and ignoring all directives that it does not understand.
この拡張機能は固有のHTTPバージョンのために定義されたキャッシュ制御指示のすべてに従うHTTPキャッシュによります、ある拡大に従って、それが理解していないすべての指示を無視して。
For example, consider a hypothetical new response directive called "community" which acts as a modifier to the "private" directive. We define this new directive to mean that, in addition to any non-shared cache, any cache which is shared only by members of the community named within its value may cache the response. An origin server wishing to allow the "UCI" community to use an otherwise private response in their shared cache(s) may do so by including
例えば、修飾語として「個人的な」指示に機能する「共同体」と呼ばれる仮定している新しい応答指示を考えてください。 私たちは、単に値の中で指定された共同体のメンバーによって共有されるどんなキャッシュもどんな非共有されたキャッシュに加えて応答をキャッシュするかもしれないことを意味するためにこの新しい指示を定義します。 "UCI"共同体がそれらの共有されたキャッシュにそうでなければ、個人的な応答を使用するのを許容したがっている発生源サーバは、包含することによって、そうするかもしれません。
Cache-Control: private, community="UCI"
キャッシュ制御: 個人的であることで、共同体は"UCI"と等しいです。
A cache seeing this header field will act correctly even if the cache does not understand the "community" cache-extension, since it will also see and understand the "private" directive and thus default to the safe behavior.
キャッシュが「共同体」キャッシュ拡大を理解していなくても、このヘッダーフィールドを見るキャッシュは正しく行動するでしょう、また、それは、安全な振舞いに「個人的な」指示を見て、理解していて、その結果、デフォルトを理解するでしょう。
Fielding, et. al. Standards Track [Page 108] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[108ページ]RFC2068HTTP/1997年1月1.1日
Unrecognized cache-directives MUST be ignored; it is assumed that any cache-directive likely to be unrecognized by an HTTP/1.1 cache will be combined with standard directives (or the response's default cachability) such that the cache behavior will remain minimally correct even if the cache does not understand the extension(s).
認識されていないキャッシュ指示を無視しなければなりません。 HTTP/1.1キャッシュで認識されていない傾向があるどんなキャッシュ指示もキャッシュが拡大を理解していなくてもキャッシュの振舞いが最少量で正しいままで残るように標準の指示(または、応答のデフォルトcachability)に結合されると思われます。
14.10 Connection
14.10 接続
The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections.
Connectionの一般的なヘッダーフィールドは、送付者がその特定の接続のために望まれているオプションを指定するのを許容して、さらなる接続の上でプロキシによって伝えられてはいけません。
The Connection header has the following grammar:
Connectionヘッダーには、以下の文法があります:
Connection-header = "Connection" ":" 1#(connection-token)
connection-token = token
「接続ヘッダー=「接続」」:、」 1つの#接続(トークン)接続トークン=トークン
HTTP/1.1 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option. HTTP/1.1 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example,
この分野のそれぞれの接続トークンのために、HTTP/1.1のプロキシが、メッセージを転送する前にConnectionヘッダーフィールドを分析して、接続トークンと同じ名前があるメッセージからどんなヘッダーフィールドも取り除かなければなりません。 接続オプションはどんな対応する追加ヘッダーフィールドではなく、Connectionヘッダーフィールドにおける、接続トークンの存在によっても示されます、その接続オプションに関連しているどんなパラメタもなければ追加ヘッダーフィールドが送られないかもしれないので。 送付者が、接続が応答の完成の後に閉店すると合図するように、HTTP/1.1は「近い」接続オプションを定義します。 例えば
Connection: close
接続: 閉鎖
in either the request or the response header fields indicates that the connection should not be considered `persistent' (section 8.1) after the current request/response is complete.
要求か応答ヘッダ分野のどちらかで、現在の要求/応答が完全になった後に接続が'永続的であること'は(セクション8.1)考えられるべきでないのを示します。
HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
パーシステントコネクションをサポートしないHTTP/1.1のアプリケーションがあらゆるメッセージに「近い」接続オプションを含まなければなりません。
14.11 Content-Base
14.11 満足している基地
The Content-Base entity-header field may be used to specify the base URI for resolving relative URLs within the entity. This header field is described as Base in RFC 1808, which is expected to be revised.
Content-基地の実体ヘッダーフィールドは、実体の中で相対的なURLを決議するのにベースURIを指定するのに使用されるかもしれません。 このヘッダーフィールドはRFC1808の基地として記述されています。(RFCは改訂されると予想されます)。
Content-Base = "Content-Base" ":" absoluteURI
「満足している基地は「満足している基地」と等しい」:、」 absoluteURI
If no Content-Base field is present, the base URI of an entity is defined either by its Content-Location (if that Content-Location URI is an absolute URI) or the URI used to initiate the request, in that
どんなContent-基地の分野も存在していないなら、実体のベースURIはContent-位置(そのContent-位置のURIが絶対URIであるなら)か要求を開始するのに使用されるURIによって定義されます、それで
Fielding, et. al. Standards Track [Page 109] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[109ページ]RFC2068HTTP/1997年1月1.1日
order of precedence. Note, however, that the base URI of the contents within the entity-body may be redefined within that entity-body.
先行の注文。 しかしながら、実体本体の中のコンテンツのベースURIがその実体本体の中で再定義されるかもしれないことに注意してください。
14.12 Content-Encoding
14.12 内容コード化
The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
Contentをコード化している実体ヘッダーフィールドは修飾語としてメディアタイプに使用されます。 存在しているとき、値はどんな追加満足しているコーディングが実体本体に適用されるか、そして、その結果、コンテントタイプヘッダーフィールドによって参照をつけられるメディアタイプを得るためにどんな解読メカニズムを適用しなければならないかを示します。 内容コード化は、ドキュメントが基本的なメディアタイプのアイデンティティを失わないで圧縮されるのを許容するのに主として使用されます。
Content-Encoding = "Content-Encoding" ":" 1#content-coding
「「内容コード化内容をコード化する=」」:、」 1#内容をコード化しています。
Content codings are defined in section 3.5. An example of its use is
満足しているコーディングはセクション3.5で定義されます。 使用に関する例はそうです。
Content-Encoding: gzip
内容をコード化しています: gzip
The Content-Encoding is a characteristic of the entity identified by the Request-URI. Typically, the entity-body is stored with this encoding and is only decoded before rendering or analogous usage.
Content-コード化はRequest-URIによって特定された実体の特性です。 実体本体は、通常、このコード化で保存されて、レンダリングか類似の用法の前に解読されるだけです。
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied.
複数のencodingsが実体に適用されたなら、それらが適用されたオーダーに満足しているコーディングを記載しなければなりません。
Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
この仕様で定義されなかった他の実体ヘッダーフィールドでコード化パラメタに関する追加情報を提供するかもしれません。
14.13 Content-Language
14.13 満足している言語
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this may not be equivalent to all the languages used within the entity-body.
Content-言語実体ヘッダーフィールドは同封の実体のために対象とする訪問者の自然言語について説明します。 これが実体本体の中で使用されたすべての言語に同等でないかもしれないことに注意してください。
Content-Language = "Content-Language" ":" 1#language-tag
「満足している言語は「満足している言語」と等しい」:、」 1#言語タグ
Language tags are defined in section 3.10. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is
言語タグはセクション3.10で定義されます。 Content-言語のプライマリ目的はユーザの自己の都合のよい言語によると、ユーザが実体を特定して、差別化するのを許容することです。 したがって、ボディー内容がデンマークに学識がある聴衆のためだけに意図するなら、適切な分野は意図します。
Content-Language: da
満足している言語: da
If no Content-Language is specified, the default is that the content is intended for all language audiences. This may mean that the sender
Content-言語が全く指定されないなら、デフォルトは内容がすべての言語聴衆のために意図するということです。 これがそれを意味するかもしれない、送付者
Fielding, et. al. Standards Track [Page 110] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[110ページ]RFC2068HTTP/1997年1月1.1日
does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.
具体的に言うと、あらゆる自然言語とそれを考えてください。さもないと、送付者がどの言語でそれを知らないかは意図します。
Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi," presented simultaneously in the original Maori and English versions, would call for
複数の言語が複数の聴衆のために意図する内容のために記載されているかもしれません。 例えば、同時にオリジナルのマオリ族と英語版に示された「ワイタンギ条約」の表現は求めるでしょう。
Content-Language: mi, en
満足している言語: ミ、アン
However, just because multiple languages are present within an entity does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin," which is clearly intended to be used by an English-literate audience. In this case, the Content-Language should only include "en".
しかしながら、まさしく複数の言語が中に存在しているので、実体は、それが複数の言語学の聴衆のために意図することを意味しません。 例は初心者の言語入門書でしょう、「ラテンにおける最初のレッスン」のように。(それは、イギリスに学識がある聴衆によって明確に使用されるつもりです)。 この場合、Content-言語は「アン」を含んでいるだけであるべきです。
Content-Language may be applied to any media type -- it is not limited to textual documents.
満足している言語はどんなメディアタイプにも適用されるかもしれません--それは原文のドキュメントに制限されません。
14.14 Content-Length
14.14 コンテンツの長さ
The Content-Length entity-header field indicates the size of the message-body, in decimal number of octets, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
Content-長さの実体ヘッダーフィールドは、八重奏の10進数における、メッセージ本体のサイズが受取人かHEADメソッドの場合における、要求がGETであったなら送られた実体本体のサイズに発信したのを示します。
Content-Length = "Content-Length" ":" 1*DIGIT
「コンテンツの長さは「コンテンツの長さ」と等しい」:、」 1*ケタ
An example is
例はそうです。
Content-Length: 3495
コンテンツの長さ: 3495
Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. It must be possible for the recipient to reliably determine the end of HTTP/1.1 requests containing an entity-body, e.g., because the request has a valid Content-Length field, uses Transfer-Encoding: chunked or a multipart body.
アプリケーションSHOULDは移すためにメッセージ本体のサイズを示すのにこの分野を使用します、実体のメディアタイプにかかわらず。 受取人が、例えば、要求には有効なContent-長さの分野があるので実体本体を含むHTTP/1.1の要求の終わりがTransfer-コード化を使用すると確かに決心しているのは、可能であるに違いありません: chunkedされるかa複合ボディー。
Any Content-Length greater than or equal to zero is a valid value. Section 4.4 describes how to determine the length of a message-body if a Content-Length is not given.
どんなゼロ以上のContent-長さも有効値です。 Content-長さが与えられないなら、セクション4.4はメッセージ本体の長さを測定する方法を説明します。
Fielding, et. al. Standards Track [Page 111] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[111ページ]RFC2068HTTP/1997年1月1.1日
Note: The meaning of this field is significantly different from the
corresponding definition in MIME, where it is an optional field
used within the "message/external-body" content-type. In HTTP, it
SHOULD be sent whenever the message's length can be determined
prior to being transferred.
以下に注意してください。 この分野の意味はMIMEとの対応する定義とかなり異なっています。(そこでは、それが「外部のメッセージ/ボディー」content typeの中で使用された任意の分野です)。 HTTPでそれ、SHOULD、移す前にメッセージの長さを測定できるときはいつも、送ってください。
14.15 Content-Location
14.15 満足している位置
The Content-Location entity-header field may be used to supply the resource location for the entity enclosed in the message. In the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server should provide a Content-Location for the particular variant which is returned. In addition, a server SHOULD provide a Content-Location for the resource corresponding to the response entity.
Content-位置の実体ヘッダーフィールドは、メッセージに同封された実体にリソース位置を供給するのに使用されるかもしれません。 それ、およびそれらの実体に関連している複数の実体が実際に、リソースで、それらが個別にアクセスされるかもしれない別々の位置を持っている場合では、サーバはContent-位置を返される特定の異形に提供するべきです。 追加、SHOULDが応答実体に対応するリソースのためのContent-位置を提供するサーバで。
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
「満足している位置は「満足している位置」と等しい」:、」 (absoluteURI| relativeURI)
If no Content-Base header field is present, the value of Content- Location also defines the base URL for the entity (see section 14.11).
また、どんなContent-基地のヘッダーフィールドも存在していないなら、Content位置の値は実体のためにベースURLを定義します(セクション14.11を見てください)。
The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. Future requests MAY use the Content-Location URI if the desire is to identify the source of that particular entity.
Content-位置の値はオリジナルの要求されたURIへの交換ではありません。 それは要求時点でこの特定の実体に対応するリソースの位置の声明にすぎません。 今後の要求は願望がその特定の実体の源を特定することであるならContent-位置のURIを使用するかもしれません。
A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content- Location can be used to differentiate between multiple entities retrieved from a single requested resource, as described in section 13.6.
キャッシュは、そのContent-位置のURIに関する後の要求に応じるのにそれを検索するのに使用されるURIと異なったContent-位置がある実体を使用できると仮定できません。 しかしながら、ただ一つの要求されたリソースから検索された複数の実体を区別するのにContent位置を使用できます、セクション13.6で説明されるように。
If the Content-Location is a relative URI, the URI is interpreted relative to any Content-Base URI provided in the response. If no Content-Base is provided, the relative URI is interpreted relative to the Request-URI.
Content-位置が相対的なURIであるなら、URIは応答に提供されたどんなContent-基地のURIに比例して解釈されます。 Content-基地を全く供給しないなら、Request-URIに比例して相対的なURIを解釈します。
Fielding, et. al. Standards Track [Page 112] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[112ページ]RFC2068HTTP/1997年1月1.1日
14.16 Content-MD5
14.16 内容-MD5
The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.)
RFC1864[23]で定義されるContent-MD5実体ヘッダーフィールドは終わりから終わりへの実体本体のメッセージの保全チェック(MIC)を提供する目的のための実体本体のMD5ダイジェストです。 (注意: MICはトランジットにおける、実体本体の偶然の変更を検出するのに良いのですが、悪意ある攻撃に対する証拠ではありません。)
Content-MD5 = "Content-MD5" ":" md5-digest
「内容-MD5は「内容-MD5"」と等しいです」 md5-ダイジェスト
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
MD5がRFC1864>に従って消化する128ビットのmd5-ダイジェスト=<base64
The Content-MD5 header field may be generated by an origin server to function as an integrity check of the entity-body. Only origin servers may generate the Content-MD5 header field; proxies and gateways MUST NOT generate it, as this would defeat its value as an end-to-end integrity check. Any recipient of the entity-body, including gateways and proxies, MAY check that the digest value in this header field matches that of the entity-body as received.
Content-MD5ヘッダーフィールドは発生源サーバによって生成されて、実体本体の保全チェックとして機能するかもしれません。 発生源サーバだけが、Content-MD5がヘッダーフィールドであると生成するかもしれません。 これが終わりから終わりへの保全チェックとして値を破るようにプロキシとゲートウェイはそれを生成してはいけません。 ゲートウェイとプロキシを含む実体本体のどんな受取人も、このヘッダーフィールドにおけるダイジェスト値が受け取るように実体本体のものに合っているのをチェックするかもしれません。
The MD5 digest is computed based on the content of the entity-body, including any Content-Encoding that has been applied, but not including any Transfer-Encoding that may have been applied to the message-body. If the message is received with a Transfer-Encoding, that encoding must be removed prior to checking the Content-MD5 value against the received entity.
MD5ダイジェストは実体本体の内容に基づいて計算されます、適用されたどんなContent-コード化も含んでいますが、メッセージ本体に当てられたどんなTransfer-コード化も含んでいなくて。 Transfer-コード化でメッセージを受け取るなら、容認された実体に対してContent-MD5値をチェックする前に、そのコード化を取り除かなければなりません。
This has the result that the digest is computed on the octets of the entity-body exactly as, and in the order that, they would be sent if no Transfer-Encoding were being applied.
これにはダイジェストがちょうど注文と注文における、実体本体の八重奏のときに計算されるという結果がある、それ、Transfer-コード化でないのを適用しているなら、それらを送るでしょうに。
HTTP extends RFC 1864 to permit the digest to be computed for MIME composite media-types (e.g., multipart/* and message/rfc822), but this does not change how the digest is computed as defined in the preceding paragraph.
HTTPはダイジェストがMIMEの合成メディアタイプ(例えば、複合/*とメッセージ/rfc822)のために計算されることを許可するためにRFC1864を広げていますが、これはダイジェストが先行のパラグラフで定義されるようにどう計算されるかを変えません。
Note: There are several consequences of this. The entity-body for
composite types may contain many body-parts, each with its own MIME
and HTTP headers (including Content-MD5, Content-Transfer-Encoding,
and Content-Encoding headers). If a body-part has a Content-
Transfer-Encoding or Content-Encoding header, it is assumed that
the content of the body-part has had the encoding applied, and the
body-part is included in the Content-MD5 digest as is -- i.e.,
after the application. The Transfer-Encoding header field is not
allowed within body-parts.
以下に注意してください。 このいくつかの結果があります。 合成型のための実体本体は多くの身体部分を含むかもしれません、それぞれそれ自身のMIMEとHTTPヘッダで(Content-MD5、Content転送コード化、およびContentをコード化しているヘッダーを含んでいて)。 身体部分に転送をコード化しているか、またはContentをコード化しているContentヘッダーがあるなら、身体部分の内容でコード化を適用したと思われて、身体部分はすなわち、そのままで、アプリケーションの後のContent-MD5ダイジェストに含まれています。 Transferをコード化しているヘッダーフィールドは身体部分の中に許容されていません。
Note: while the definition of Content-MD5 is exactly the same for
HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
以下に注意してください。 HTTPには、Content-MD5の定義はMIME実体本体のためにまさにRFC1864と同じですが、いくつかの道があります。
Fielding, et. al. Standards Track [Page 113] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[113ページ]RFC2068HTTP/1997年1月1.1日
in which the application of Content-MD5 to HTTP entity-bodies
differs from its application to MIME entity-bodies. One is that
HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does
use Transfer-Encoding and Content-Encoding. Another is that HTTP
more frequently uses binary content types than MIME, so it is worth
noting that, in such cases, the byte order used to compute the
digest is the transmission byte order defined for the type. Lastly,
HTTP allows transmission of text types with any of several line
break conventions and not just the canonical form using CRLF.
Conversion of all line breaks to CRLF should not be done before
computing or checking the digest: the line break convention used in
the text actually transmitted should be left unaltered when
computing the digest.
HTTP実体本体へのContent-MD5のアプリケーションはアプリケーションからMIME実体本体まで異なります。 1つはHTTPがMIMEと異なってContent転送コード化を使用しないで、Transfer-コード化とContent-コード化を使用するということです。 別のものがMIMEよりHTTPがさらに頻繁に2進のcontent typeを使用するということであるので、ダイジェストを計算するのに使用されるバイトオーダーがそのような場合でタイプのために定義されたトランスミッションバイトオーダーであることに注意する価値があります。 最後に、HTTPは標準形だけではなく、数人のラインブレイクコンベンションのどれかがCRLFを使用しているテキストタイプのトランスミッションを許容します。 ダイジェストを計算するか、またはチェックする前に、CRLFへのすべてのラインブレイクの変換をするべきではありません: 実際に伝えられたテキストで使用されるラインブレイクコンベンションはダイジェストを計算するときには非変更されるように残されるべきです。
14.17 Content-Range
14.17 満足している範囲
The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be inserted. It also indicates the total size of the full entity-body. When a server returns a partial response to a client, it must describe both the extent of the range covered by the response, and the length of the entire entity-body.
いっぱいの実体本体に、部分的なボディーがどこで挿入されるべきであるかを指定するために部分的な実体本体と共にContent-範囲実体ヘッダーを送ります。 また、それはいっぱいの実体本体の総サイズを示します。 サーバが部分応答をクライアントに返すとき、それは応答でカバーされた範囲の範囲と全体の実体本体の長さの両方について説明しなければなりません。
Content-Range = "Content-Range" ":" content-range-spec
「満足している範囲は「満足している範囲」と等しい」:、」 満足している範囲仕様
content-range-spec = byte-content-range-spec
満足している範囲仕様はバイトの満足している範囲仕様と等しいです。
byte-content-range-spec = bytes-unit SP first-byte-pos "-"
last-byte-pos "/" entity-length
「最後のバイトがposされていた状態で、バイトの満足している範囲仕様はバイト-ユニットSP最初のバイトpos「-」と等しく」/、」 実体長さ
entity-length = 1*DIGIT
実体長さは1*DIGITと等しいです。
Unlike byte-ranges-specifier values, a byte-content-range-spec may only specify one range, and must contain absolute byte positions for both the first and last byte of the range.
バイト範囲特許説明書の作成書値と異なって、バイトの満足している範囲仕様は、1つの範囲しか指定しないかもしれなくて、1番目と範囲の最後のバイトの両方のための絶対バイト位置を含まなければなりません。
A byte-content-range-spec whose last-byte-pos value is less than its first-byte-pos value, or whose entity-length value is less than or equal to its last-byte-pos value, is invalid. The recipient of an invalid byte-content-range-spec MUST ignore it and any content transferred along with it.
バイトposを持続している値が最初のバイトpos値以下であるか実体長さの値がバイトposを持続しているより値が無効であるということであるバイトの満足している範囲仕様。 無効のバイト満足している範囲仕様の受取人はそれと共に移されたそれとどんな内容も無視しなければなりません。
Fielding, et. al. Standards Track [Page 114] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[114ページ]RFC2068HTTP/1997年1月1.1日
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
実体が合計1234バイトを含むと仮定するバイトの満足している範囲仕様値に関する例:
o The first 500 bytes:
o 最初の500バイト:
bytes 0-499/1234
バイト0-499/1234
o The second 500 bytes:
o 2番目の500バイト:
bytes 500-999/1234
バイト500-999/1234
o All except for the first 500 bytes:
o 優に最初の500バイトを除いて:
bytes 500-1233/1234
バイト500-1233/1234
o The last 500 bytes:
o 最後の500バイト:
bytes 734-1233/1234
バイト734-1233/1234
When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to a request for a set of ranges that overlap without any holes), this content is transmitted with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example,
HTTPメッセージがただ一つの範囲(例えば、ただ一つの範囲を求める要求、または、少しも穴なしで重なる1セットの範囲を求める要求への応答)の内容を含んでいるとき、この内容はContent-範囲ヘッダーと共に伝えられました、そして、バイト数を示しているContent-長さのヘッダーは実際に移しました。 例えば
HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif
HTTP/1.1 206Partial内容日付: グリニッジ標準時1995年11月15日水曜日6時25分24秒の最終更新日: グリニッジ標準時1995年11月15日水曜日4時58分8秒の満足している範囲: バイト21010-47021/47022のContent-長さ: 26012コンテントタイプ: イメージ/gif
When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart MIME message. The multipart MIME content-type used for this purpose is defined in this specification to be "multipart/byteranges". See appendix 19.2 for its definition.
HTTPメッセージが複数の範囲の内容を含んでいるとき(例えば、複数の非の重なるのを求める要求への応答は及びます)、これらは複合MIMEメッセージとして伝えられます。 このために使用される複合MIME content typeは、「複合/byteranges」になるようにこの仕様に基づき定義されます。 定義に関して付録19.2を見てください。
A client that cannot decode a MIME multipart/byteranges message should not ask for multiple byte-ranges in a single request.
MIME複合/byterangesメッセージを解読できないクライアントはただ一つの要求における複数のバイト範囲を求めるべきではありません。
When a client requests multiple byte-ranges in one request, the server SHOULD return them in the order that they appeared in the request.
クライアントが1つの要求における複数のバイト範囲を要求するとき、サーバSHOULDはそれらが要求で見えたオーダーでそれらを返します。
If the server ignores a byte-range-spec because it is invalid, the server should treat the request as if the invalid Range header field
それが無効であるのでサーバがバイト範囲仕様を無視するなら、サーバが要求を扱うべきである、無効のRangeヘッダーフィールド
Fielding, et. al. Standards Track [Page 115] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[115ページ]RFC2068HTTP/1997年1月1.1日
did not exist. (Normally, this means return a 200 response containing the full entity). The reason is that the only time a client will make such an invalid request is when the entity is smaller than the entity retrieved by a prior request.
存在しませんでした。 (通常、これは、完全な実体を含む200応答を返すことを意味します。) 理由はクライアントがそのような無効の要求をする唯一の時間が実体が先の要求で検索された実体より小さい時であるということです。
14.18 Content-Type
14.18 コンテントタイプ
The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.
コンテントタイプ実体ヘッダーフィールドは、実体本体のメディアタイプが受取人かHEADメソッドの場合における要求がGETであったなら送られたメディアタイプに発信したのを示します。
Content-Type = "Content-Type" ":" media-type
Media types are defined in section 3.7. An example of the field is
「コンテントタイプは「コンテントタイプ」と等しい」:、」 メディアタイプメディアタイプはセクション3.7で定義されます。 分野に関する例はそうです。
Content-Type: text/html; charset=ISO-8859-4
コンテントタイプ: テキスト/html。 charset=ISO-8859-4
Further discussion of methods for identifying the media type of an entity is provided in section 7.2.1.
実体のメディアタイプを特定するためのメソッドのさらなる議論をセクション7.2.1に提供します。
14.19 Date
14.19 日付
The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in section 3.3.1.
Dateの一般的なヘッダーフィールドはメッセージが溯源された日時を表します、RFC822のorig-日付と同じ意味論を持っていて。 分野値はセクション3.3.1で説明されるようにHTTP日付です。
Date = "Date" ":" HTTP-date
「「日付」と=の日付を入れてください」:、」 HTTP日付
An example is
例はそうです。
Date: Tue, 15 Nov 1994 08:12:31 GMT
日付: グリニッジ標準時1994年11月15日火曜日8時12分31秒
If a message is received via direct connection with the user agent (in the case of requests) or the origin server (in the case of responses), then the date can be assumed to be the current date at the receiving end. However, since the date--as it is believed by the origin--is important for evaluating cached responses, origin servers MUST include a Date header field in all responses. Clients SHOULD only send a Date header field in messages that include an entity- body, as in the case of the PUT and POST requests, and even then it is optional. A received message which does not have a Date header field SHOULD be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date.
ユーザエージェント(要求の場合における)か発生源サーバ(応答の場合における)とのダイレクト関係でメッセージを受け取るなら、現在の期日の犠牲者に、あると日付を思うことができます。 しかしながら、キャッシュされた応答を評価するのに、それが発生源によって信じられているような期日が重要であるので、発生源サーバはすべての応答にDateヘッダーフィールドを含まなければなりません。 クライアントSHOULDは実体本体を含んでいるメッセージのDateヘッダーフィールドを送るだけです、それがPUTとポストの要求のケースと、その時でさえ任意であるので。 メッセージがその受取人によってキャッシュされるか、またはDateを必要とするプロトコルでgatewayedされるなら受取人がDateヘッダーフィールドSHOULDに1つを割り当てない受信されたメッセージ。
Fielding, et. al. Standards Track [Page 116] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[116ページ]RFC2068HTTP/1997年1月1.1日
In theory, the date SHOULD represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.
理論上、実体が発生しているすぐ前に日付SHOULDは瞬間を表します。 実際には、意味値に影響しないで、いつでも、メッセージ創作の間、日付を生成することができます。
The format of the Date is an absolute date and time as defined by HTTP-date in section 3.3; it MUST be sent in RFC1123 [8]-date format.
Dateの形式はセクション3.3でHTTP日付で定義されるように絶対日時です。 RFC1123[8]日付の形式でそれを送らなければなりません。
14.20 ETag
14.20 ETag
The ETag entity-header field defines the entity tag for the associated entity. The headers used with entity tags are described in sections 14.20, 14.25, 14.26 and 14.43. The entity tag may be used for comparison with other entities from the same resource (see section 13.3.2).
ETag実体ヘッダーフィールドは関連実体のために実体タグを定義します。 実体タグと共に使用されるヘッダーはセクション14.20、14.25、14.26、および14.43で説明されます。 実体タグは他の実体との比較に同じリソースから使用されるかもしれません(セクション13.3.2を見てください)。
ETag = "ETag" ":" entity-tag
「ETagは"ETag"と等しい」:、」 実体タグ
Examples:
例:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
ETag: "xyzzy"ETag: 「」 xyzzy」ETag: ""
14.21 Expires
14.21は期限が切れます。
The Expires entity-header field gives the date/time after which the response should be considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13.2 for further discussion of the expiration model.
Expires実体ヘッダーフィールドは応答が聞き古したである考えられるべきである日付/時を与えます。 それが最初に発生源サーバ(または実体の新鮮なコピーを持っている中間的キャッシュで)で有効にされない場合、キャッシュ(プロキシキャッシュかユーザエージェントキャッシュのどちらか)によって通常、聞き古したキャッシュエントリーは返されないかもしれません。 満了モデルのさらなる議論に関してセクション13.2を見てください。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expires分野の存在は、オリジナルのリソースが変化するのを含意もしませんし、その時の前かその時か、その時以降存在するのをやめもしません。
The format is an absolute date and time as defined by HTTP-date in section 3.3; it MUST be in RFC1123-date format:
形式はセクション3.3でHTTP日付で定義されるように絶対日時です。 RFC1123-日付の形式にはそれがあるに違いありません:
Expires = "Expires" ":" HTTP-date
「=「期限が切れること」を吐き出す」:、」 HTTP日付
Fielding, et. al. Standards Track [Page 117] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[117ページ]RFC2068HTTP/1997年1月1.1日
An example of its use is
使用に関する例はそうです。
Expires: Thu, 01 Dec 1994 16:00:00 GMT
期限が切れます: グリニッジ標準時1994年12月1日木曜日16時0分0秒
Note: if a response includes a Cache-Control field with the max-age
directive, that directive overrides the Expires field.
以下に注意してください。 応答が最大時代指示があるCache-制御フィールドを含んでいるなら、その指示はExpires分野をくつがえします。
HTTP/1.1 clients and caches MUST treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
HTTP/1.1のクライアントとキャッシュが他の無効の日付の形式を扱わなければなりません、値を特に含んでいて「過去(すなわち、「既に、期限が切れる」)のような0インチ
To mark a response as "already expired," an origin server should use an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.)
「既に吐き出されます」のように応答をマークするために、発生源サーバはDateヘッダー価値と等しいExpires期日を使用するべきです。 (セクション13.2.4における満了計算のための規則を見てください。)
To mark a response as "never expires," an origin server should use an Expires date approximately one year from the time the response is sent. HTTP/1.1 servers should not send Expires dates more than one year in the future.
「決して期限が切れない」で応答をマークするために、発生源サーバは応答が送られる時からのExpiresおよそ1年日付を使用するべきです。 HTTP/1.1のサーバは将来、1年以上日付をExpiresに送るべきではありません。
The presence of an Expires header field with a date value of some time in the future on an response that otherwise would by default be non-cacheable indicates that the response is cachable, unless indicated otherwise by a Cache-Control header field (section 14.9).
将来いつかの日付の値がそうでなければ、デフォルトで非「キャッシュ-可能」である応答にあるExpiresヘッダーフィールドの存在は、応答がキャッシュ可能であることを示します、Cache-コントロールヘッダーフィールド(セクション14.9)によって別の方法で示されない場合。
14.22 From
14.22
The From request-header field, if given, SHOULD contain an Internet e-mail address for the human user who controls the requesting user agent. The address SHOULD be machine-usable, as defined by mailbox in RFC 822 (as updated by RFC 1123 ):
From要求ヘッダーフィールド、考えて、SHOULDは要求しているユーザエージェントを監督する人間のユーザへのインターネットEメールアドレスを含んでいます。 マシンメールボックスで定義されるとして使用可能なコネがRFC822であった(RFC1123によってアップデートされるように)ならSHOULDを扱ってください:
From = "From" ":" mailbox
「=“From"」:、」 メールボックス
An example is:
例は以下の通りです。
From: webmaster@w3.org
From: webmaster@w3.org
This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.
このヘッダーフィールドは伐採目的と無効の、または、求められていない要求の源を特定するための手段として使用されるかもしれません。 それ、SHOULD NOT、不安定な形式のアクセス保護として、使用されてください。 この分野の解釈はメソッドが働いたので要求が与えられている人を代表して実行されているということです。その人は、責任を引き受けます。 特に、ロボットエージェントSHOULDは、問題が受ける側になって起こるならロボットを動かすのに責任がある人に連絡できるようにこのヘッダーを含んでいます。
Fielding, et. al. Standards Track [Page 118] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[118ページ]RFC2068HTTP/1997年1月1.1日
The Internet e-mail address in this field MAY be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original issuer's address SHOULD be used.
この分野のインターネット電子メールアドレスはインターネット・ホストから別々であるかもしれません(要求を出しました)。 例えば、要求がオリジナルの発行人のプロキシアドレスSHOULDに通り抜けたら、使用されてください。
Note: The client SHOULD not send the From header field without the
user's approval, as it may conflict with the user's privacy
interests or their site's security policy. It is strongly
recommended that the user be able to disable, enable, and modify
the value of this field at any time prior to a request.
以下に注意してください。 クライアントSHOULDはヘッダーフィールドからユーザの賛成なしで送りません、ユーザのプライバシー利益のためかそれらのサイトの安全保障政策と衝突するとき。 ユーザが要求の前にいつでもこの分野の値を無効にして、可能にして、変更できることが強く勧められます。
14.23 Host
14.23 ホスト
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URL given by the user or referring resource (generally an HTTP URL, as described in section 3.2.2). The Host field value MUST represent the network location of the origin server or gateway given by the original URL. This allows the origin server or gateway to differentiate between internally-ambiguous URLs, such as the root "/" URL of a server for multiple host names on a single IP address.
Host要求ヘッダーフィールドは要求されているリソースのインターネット・ホストとポートナンバーを指定します、ユーザによって与えられたオリジナルのURLから得るか、またはリソース(一般に説明されたコネセクション3.2.2としてのHTTP URL)を参照するとして。 Host分野価値はオリジナルのURLによって与えられた発生源サーバかゲートウェイのネットワークの位置を表さなければなりません。 」 単一のIPの複数のホスト名のためのサーバのURLが扱う「発生源サーバかゲートウェイがこれで内部的にあいまいなURLを区別できます、根などのように」/。
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
「ホスト=「ホスト」」:、」 ホスト[「:」 ポート]。 セクション3.2 .2
A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP URL). For example, a request on the origin server for <http://www.w3.org/pub/WWW/> MUST include:
少しも引きずっているポート情報のない「ホスト」がサービスのためのポートが要求したデフォルトを含意する、(例えば、「HTTP URLのための80インチ)」 例えば、<http://www.w3.org/pub/WWW/>のための発生源サーバに関する要求は以下を含まなければなりません。
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
/pub/WWW/ HTTP/1.1ホストを手に入れてください: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request messages on the Internet (i.e., on any message corresponding to a request for a URL which includes an Internet host address for the service being requested). If the Host field is not already present, an HTTP/1.1 proxy MUST add a Host field to the request message prior to forwarding it on the Internet. All Internet-based HTTP/1.1 servers MUST respond with a 400 status code to any HTTP/1.1 request message which lacks a Host header field.
クライアントはインターネット(すなわち、要求されているサービスのためのインターネットホスト・アドレスを含んでいるURLを求める要求に対応するどんなメッセージのも)に関するすべてのHTTP/1.1の要求メッセージでHostヘッダーフィールドを入れなければなりません。 Host分野が既に存在していないなら、インターネットでそれを進める前に、HTTP/1.1プロキシはHost分野を要求メッセージに追加しなければなりません。 インターネットを利用するすべてのHTTP/1.1のサーバが400ステータスコードでHostヘッダーフィールドを欠いているどんなHTTP/1.1要求メッセージにも反応しなければなりません。
See sections 5.2 and 19.5.1 for other requirements relating to Host.
Hostに関連する他の要件に関してセクション5.2と19.5.1を見てください。
14.24 If-Modified-Since
14.24、以来、変更されます。
The If-Modified-Since request-header field is used with the GET method to make it conditional: if the requested variant has not been modified since the time specified in this field, an entity will not
以来変更されたIf要求ヘッダーフィールドはそれを条件付きにするGETメソッドで使用されます: 時間がこの分野で指定して以来要求された異形が変更されていないと、実体は変更されないでしょう。
Fielding, et. al. Standards Track [Page 119] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[119ページ]RFC2068HTTP/1997年1月1.1日
be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.
サーバから、返してください。 代わりに、少しもメッセージ本体なしで304(変更されない)応答を返すでしょう。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
「= 以来変更されるなら「以来変更されるなら」」:、」 HTTP日付
An example of the field is:
分野に関する例は以下の通りです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
以来変更されるなら: グリニッジ標準時1994年10月29日土曜日19時43分31秒
A GET method with an If-Modified-Since header and no Range header requests that the identified entity be transferred only if it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the following cases:
以来変更されたIfヘッダーにもかかわらず、RangeヘッダーがないGETメソッドは、以来変更されたIfヘッダーによって与えられた日付以来それが変更されている場合にだけ特定された実体が移されるよう要求します。 これを決定するためのアルゴリズムは以下のケースを含んでいます:
a)If the request would normally result in anything other than a 200
(OK) status, or if the passed If-Modified-Since date is invalid, the
response is exactly the same as for a normal GET. A date which is
later than the server's current time is invalid.
a) 通常、要求が200(OK)状態以外の何かをもたらすだろうか、または通っている以来変更されたIf期日が無効であるなら、応答はまさに正常なGETのように同じです。 サーバの現在の時間より後半である期日は無効です。
b)If the variant has been modified since the If-Modified-Since date,
the response is exactly the same as for a normal GET.
b) 以来変更されたIf日付以来異形が変更されているなら、応答はまさに正常なGETのように同じです。
c)If the variant has not been modified since a valid If-Modified-Since
date, the server MUST return a 304 (Not Modified) response.
c) 有効な以来変更されたIf期日以来異形が変更されていないなら、サーバは304(Modifiedでない)応答を返さなければなりません。
The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
この特徴の目的は最小の量のトランザクションオーバーヘッドがあるキャッシュされた情報の効率的なアップデートを許すことです。
Note that the Range request-header field modifies the meaning of
If-Modified-Since; see section 14.36 for full details.
Range要求ヘッダーフィールドが以来変更されたIfの意味を変更することに注意してください。 一部始終に関してセクション14.36を見てください。
Note that If-Modified-Since times are interpreted by the server,
whose clock may not be synchronized with the client.
以来変更されたIf回がサーバによって解釈されることに注意してください。(サーバの時計はクライアントに連動しないかもしれません)。
Note that if a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time. The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the client and server. This includes the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified- Since date of a subsequent request, and the possibility of clock- skew-related problems if the If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between client and server are at best approximate due to network latency.
クライアントが最終更新日ヘッダーから同じ要求に取られた日付の代わりに以来変更されたIfヘッダーで任意の期日を使用するなら、クライアントがこの日付がサーバの時間の理解で解釈されるという事実を知るべきであることに注意してください。 クライアントは、時間の異なったencodingsのためクライアントとサーバの間で非連動している時計と問題を一周させると考えるべきです。修正のないクライアントの時計からサーバの時計まで以来変更されたIf日付を引き出すならそれが要求された1番目であり、-以来Ifに変更にされるのがその後の要求の日付と、時計の斜行関連の問題の可能性であった時に変えて、ドキュメントが含んでいたなら、これは競合条件の可能性を含んでいます。 クライアントとサーバの間の異なった時間ベースのための修正はネットワーク潜在のためにせいぜい大体です。
Fielding, et. al. Standards Track [Page 120] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[120ページ]RFC2068HTTP/1997年1月1.1日
14.25 If-Match
14.25、-合ってください。
The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches any current entity of the resource.
If-マッチ要求ヘッダーフィールドはそれを条件付きにするメソッドで使用されます。 以前にリソースから1つ以上の実体を得させるクライアントは、それらの実体の1つがIf-マッチヘッダーフィールドにそれらの関連実体タグのリストを含んでいることによってよく見られることを確かめることができます。 この特徴の目的は最小の量のトランザクションオーバーヘッドがあるキャッシュされた情報の効率的なアップデートを許すことです。 また、要求をアップデートするとき、それは、リソースの間違ったバージョンの不注意な変更を防ぐのに使用されます。 特殊なものとして、値の「*」はリソースのどんな現在の実体にも合っています。
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
「-合ってください、等しさ、「-合ってください、」、」、:、」 (「*」| 1#実体タグ)
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MAY perform the requested method as if the If-Match header field did not exist.
実体タグのどれかがそのリソースに関する同様のGET要求(If-マッチヘッダーのない)への応答で返された実体の実体タグに合っているか、「*」を与えて、または何か現在の実体がそのリソースのために存在しているならサーバが要求されたメソッドを実行するかもしれない、-合ってください、ヘッダーフィールドは存在しませんでした。
A server MUST use the strong comparison function (see section 3.11) to compare the entity tags in If-Match.
サーバは、If-マッチで実体タグを比較するのに、強い比較関数(セクション3.11を見る)を使用しなければなりません。
If none of the entity tags match, or if "*" is given and no current entity exists, the server MUST NOT perform the requested method, and MUST return a 412 (Precondition Failed) response. This behavior is most useful when the client wants to prevent an updating method, such as PUT, from modifying a resource that has changed since the client last retrieved it.
実体タグのいずれも合っていないか、「*」を与えて、またはどんな現在の実体も存在していないなら、サーバは、要求されたメソッドを実行してはいけなくて、412(前提条件は失敗した)応答を返さなければなりません。 クライアントがアップデートメソッドを防ぎたがっているとき、この振舞いは最も役に立ちます、PUTなどのように、クライアントが最後にそれを検索して以来変化しているリソースを変更するのから。
If the request would, without the If-Match header field, result in anything other than a 2xx status, then the If-Match header MUST be ignored.
要求がIf-マッチヘッダーフィールドなしで2xx状態以外の何かをもたらすなら、If-マッチヘッダーを無視しなければなりません。
The meaning of "If-Match: *" is that the method SHOULD be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.43) exists, and MUST NOT be performed if the representation does not exist.
意味、「-合ってください、:、」 *「発生源サーバ(キャッシュで、ことによるとVaryメカニズムを使用して、セクション14.43を見る)によって選択された表現が存在しているならメソッドSHOULDが実行されるということであり、表現が存在していないなら、実行されてはいけません。」
Fielding, et. al. Standards Track [Page 121] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[121ページ]RFC2068HTTP/1997年1月1.1日
A request intended to update a resource (e.g., a PUT) MAY include an If-Match header field to signal that the request method MUST NOT be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. This allows the user to indicate that they do not wish the request to be successful if the resource has been changed without their knowledge. Examples:
リソース(例えば、PUT)をアップデートすることを意図する要求は、If-マッチ値(単一体タグ)に対応する実体がもうそのリソースの表現でないなら要求メソッドを適用してはいけないと合図するためにIf-マッチヘッダーフィールドを含むかもしれません。 これで、ユーザは、それらの知識なしでリソースを変えたなら彼らが、要求にうまくいっていて欲しくないのを示すことができます。 例:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
-合ってください、: "xyzzy"、-合ってください、: "xyzzy"、"r2d2xxxx""c3piozzzz"、-合ってください、: *
14.26 If-None-Match
14.26 なにもであるなら、合ってください。
The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of a resource which was not known to exist.
なにも合わせないIf要求ヘッダーフィールドはそれを条件付きにするメソッドで使用されます。 以前にリソースから1つ以上の実体を得させるクライアントは、それらの実体のいずれもなにも合わせないIfヘッダーフィールドにそれらの関連実体タグのリストを含んでいることによってよく見られないことを確かめることができます。 この特徴の目的は最小の量のトランザクションオーバーヘッドがあるキャッシュされた情報の効率的なアップデートを許すことです。 また、要求をアップデートするとき、それは、存在するのは知られなかったリソースの不注意な変更を防ぐのに使用されます。
As a special case, the value "*" matches any current entity of the resource.
特殊なものとして、値の「*」はリソースのどんな現在の実体にも合っています。
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
「= なにも合っていないなら「なにも合っていないなら」」:、」 (「*」| 1#実体タグ)
If any of the entity tags match the entity tag of the entity that would have been returned in the response to a similar GET request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method. Instead, if the request method was GET or HEAD, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related entity-header fields (particularly ETag) of one of the entities that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed).
実体タグのどれかがそのリソースに関する同様のGET要求(なにも合わせないIfヘッダーのない)への応答で返された実体の実体タグに合っているか、「*」を与えて、または何か現在の実体がそのリソースのために存在しているなら、サーバは要求されたメソッドを実行してはいけません。 代わりに、サーバSHOULDは要求メソッドがGETかHEADであったなら、304(Modifiedでない)応答で応じます、合っていた実体の1つのキャッシュ関連の実体ヘッダーフィールド(特にETag)を含んでいて。 他のすべての要求メソッドのために、サーバは412の状態で反応しなければなりません(Failedをあらかじめ調整してください)。
See section 13.3.3 for rules on how to determine if two entity tags match. The weak comparison function can only be used with GET or HEAD requests.
2個の実体タグが合っているかどうかどう決定するかに関する規則に関してセクション13.3.3を見てください。 GETかHEAD要求と共に弱い比較関数を使用できるだけです。
If none of the entity tags match, or if "*" is given and no current entity exists, then the server MAY perform the requested method as if the If-None-Match header field did not exist.
実体タグのいずれも合っていないか、「*」を与えて、またはどんな現在の実体も存在していないならサーバが要求されたメソッドを実行するかもしれない、なにも合っていないなら、ヘッダーフィールドは存在しませんでした。
Fielding, et. al. Standards Track [Page 122] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[122ページ]RFC2068HTTP/1997年1月1.1日
If the request would, without the If-None-Match header field, result in anything other than a 2xx status, then the If-None-Match header MUST be ignored.
要求がなにも合わせないIfヘッダーフィールドなしで2xx状態以外の何かをもたらすなら、なにも合わせないIfヘッダーを無視しなければなりません。
The meaning of "If-None-Match: *" is that the method MUST NOT be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see section 14.43) exists, and SHOULD be performed if the representation does not exist. This feature may be useful in preventing races between PUT operations.
意味、「なにもであるなら、合ってください」 *それはメソッドです。「発生源サーバ(キャッシュで、ことによるとVaryメカニズムを使用して、セクション14.43を見る)によって選択された表現が存在しているなら実行されてはいけない、SHOULD、表現が存在しないなら実行されてください、」 この特徴はPUT操作の間のレースを防ぐ際に役に立つかもしれません。
Examples:
例:
If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *
なにも合っていないなら: 「xyzzy。」なにもであるなら、合ってください: 「」 xyzzy」と、なにもであるなら合ってください: "xyzzy"、"r2d2xxxx""c3piozzzz"、なにも合っていないなら: 」 r2d2xxxxがある「」 xyzzy」、」、」 c3piozzzz、」 なにも合っていないなら: *
14.27 If-Range
14.27、-及んでください。
If a client has a partial copy of an entity in its cache, and wishes to have an up-to-date copy of the entire entity in its cache, it could use the Range request-header with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition fails because the entity has been modified, the client would then have to make a second request to obtain the entire current entity-body.
クライアントがキャッシュにおける実体の部分的なコピーを持っていて、キャッシュにおける全体の実体の最新のコピーを持ちたいなら、それは条件付きのGETと共にRange要求ヘッダーを使用するかもしれません(以来変更されていないIfとIf-マッチのどちらかか両方を使用します。)。 しかしながら、実体が変更されたので状態が失敗するなら、クライアントはそして、全体の現在の実体本体を得るという2番目の要求をしなければならないでしょう。
The If-Range header allows a client to "short-circuit" the second request. Informally, its meaning is `if the entity is unchanged, send me the part(s) that I am missing; otherwise, send me the entire new entity.'
If-範囲ヘッダーは「短絡」への2番目の要求をクライアントに許します。 意味は非公式に、'実体が変わりがないなら、私が逃している部分を私に送ってください'です。 'さもなければ、全体の新しい実体を私に送ってください'。
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
「-及んでください、等しさ、「-及んでください、」、」、:、」 (HTTPでデートしていた状態で|実体でタグ付けをします)
If the client has no entity tag for an entity, but does have a Last- Modified date, it may use that date in a If-Range header. (The server can distinguish between a valid HTTP-date and any form of entity-tag by examining no more than two characters.) The If-Range header should only be used together with a Range header, and must be ignored if the request does not include a Range header, or if the server does not support the sub-range operation.
クライアントが実体のための実体タグを全く持っていませんが、Lastの変更された期日を過すなら、それはIf-範囲ヘッダーでその日付を使用するかもしれません。 (サーバは2つ未満のキャラクタを調べることによって、有効なHTTP期日とどんな形式の実体タグも見分けることができます。) 要求がRangeヘッダーを含まないで、またサーバが、サブ範囲が操作であるとサポートしないなら、If-範囲ヘッダーをRangeヘッダーと共に使用されるだけであるべきであり、無視しなければなりません。
Fielding, et. al. Standards Track [Page 123] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[123ページ]RFC2068HTTP/1997年1月1.1日
If the entity tag given in the If-Range header matches the current entity tag for the entity, then the server should provide the specified sub-range of the entity using a 206 (Partial content) response. If the entity tag does not match, then the server should return the entire entity using a 200 (OK) response.
If-範囲ヘッダーで与えられた実体タグが実体のための現在の実体タグに合っているなら、サーバは、206(部分的な内容)応答を使用することで実体の指定されたサブ範囲を提供するべきです。 実体タグが合っていないなら、サーバは、200(OK)応答を使用することで全体の実体を返すべきです。
14.28 If-Unmodified-Since
14.28、以来、変更されていません。
The If-Unmodified-Since request-header field is used with a method to make it conditional. If the requested resource has not been modified since the time specified in this field, the server should perform the requested operation as if the If-Unmodified-Since header were not present.
以来変更されていないIf要求ヘッダーフィールドはそれを条件付きにするメソッドで使用されます。 時間がこの分野で指定して以来要求されたリソースが変更されていないなら、まるで以来変更されていないIfヘッダーが出席していないかのようにサーバは要求された操作を実行するべきです。
If the requested variant has been modified since the specified time, the server MUST NOT perform the requested operation, and MUST return a 412 (Precondition Failed).
指定された時間以来要求された異形が変更されているなら、サーバは、要求された操作を実行してはいけなくて、412を返さなければなりません(Failedをあらかじめ調整してください)。
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
「= 以来変更されていないなら「以来変更されていないなら」」:、」 HTTP日付
An example of the field is:
分野に関する例は以下の通りです。
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
以来変更されていないなら: グリニッジ標準時1994年10月29日土曜日19時43分31秒
If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx status, the If- Unmodified-Since header should be ignored.
要求が通常2xx状態以外の何かをもたらすなら(すなわち、以来変更されていないIfヘッダーなしで)、-以来変更されていないIfヘッダーは無視されるべきです。
If the specified date is invalid, the header is ignored.
指定された期日が無効であるなら、ヘッダーは無視されます。
14.29 Last-Modified
14.29 最終更新日
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
最終更新日実体ヘッダーフィールドは、発生源サーバが異形を信じている日時が最後に変更されたのを示します。
Last-Modified = "Last-Modified" ":" HTTP-date
「最終更新日は「最終更新日」と等しい」:、」 HTTP日付
An example of its use is
使用に関する例はそうです。
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
最終更新日: グリニッジ標準時1994年11月15日火曜日12時45分26秒
The exact meaning of this header field depends on the implementation of the origin server and the nature of the original resource. For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update time stamp of the record. For virtual objects, it may be the last time the internal state changed.
このヘッダーフィールドの正確な意味は発生源サーバの実装とオリジナルのリソースの本質によります。 ファイルに関しては、まさしくファイルシステムが最後に時間を変更したということであるかもしれません。 それがダイナミックに含まれている部品がある実体のための、そうである、最新である、セット、コンポーネントが離れているので、最後に回を変更してください。 データベースゲートウェイに関しては、それは記録のアップデート時間スタンプであるかもしれません。 仮想オブジェクトに関しては、内部の状態が変化した最後の時であるかもしれません。
Fielding, et. al. Standards Track [Page 124] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[124ページ]RFC2068HTTP/1997年1月1.1日
An origin server MUST NOT send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date.
発生源サーバはサーバのメッセージ創作の時間より後半である最終更新日期日を送ってはいけません。 そのような場合では、サーバはその日付をメッセージ創作日付に取り替えなければなりません。そこで、リソースの最後の変更は将来、いくらかの時間を示すでしょう。
An origin server should obtain the Last-Modified value of the entity as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the entity's modification time, especially if the entity changes near the time that the response is generated.
発生源サーバはできるだけDateが応答の値であると生成する時間の近くで実体の最終更新日値を得るべきです。 これで、受取人は実体の変更時間の正確な査定をすることができます、特に実体が応答が発生していることの時間変化するなら。
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
可能であるときはいつも、HTTP/1.1サーバSHOULDは最終更新日を送ります。
14.30 Location
14.30 位置
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URL for automatic redirection to the resource. The field value consists of a single absolute URL.
Location応答ヘッダ分野は、要求の完成か新しいリソースの識別のためのRequest-URI以外の位置に受取人を向け直すのに使用されます。 201(作成される)の応答のために、Locationは要求で作成された新しいリソースのものです。 3xx応答のために、位置のSHOULDは自動リダイレクションのためのサーバの都合のよいURLをリソースに示します。 分野値はただ一つの絶対URLから成ります。
Location = "Location" ":" absoluteURI
「位置は「位置」と等しい」:、」 absoluteURI
An example is
例はそうです。
Location: http://www.w3.org/pub/WWW/People.html
位置: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.15) differs
from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache requirements
of some methods.
以下に注意してください。 Content-位置のヘッダーフィールド(セクション14.15)はContent-位置が要求に同封された実体の元の位置を特定するという点においてLocationと異なっています。 したがって、応答がLocationとContent-位置の両方のためのヘッダーフィールドを含むのは、可能です。 また、いくつかのメソッドのキャッシュ要件に関してセクション13.10を見てください。
14.31 Max-Forwards
14.31 前方へマックス
The Max-Forwards request-header field may be used with the TRACE method (section 14.31) to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain.
次の本国行きのサーバに要求を転送できるプロキシかゲートウェイの数を制限するTRACEメソッド(セクション14.31)で前方へマックス要求ヘッダーフィールドは使用されるかもしれません。クライアントが、中間のチェーンで失敗するか、または輪にしているように見える要求チェーンをたどるのを試みているとき、これは役に立つ場合があります。
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
「前方へマックスは「前方へマックス」と等しい」:、」 1*ケタ
Fielding, et. al. Standards Track [Page 125] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[125ページ]RFC2068HTTP/1997年1月1.1日
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.
前方へマックス値は回のこの要求メッセージが転送されるかもしれない残っている数を示す10進整数です。
Each proxy or gateway recipient of a TRACE request containing a Max- Forwards header field SHOULD check and update its value prior to forwarding the request. If the received value is zero (0), the recipient SHOULD NOT forward the request; instead, it SHOULD respond as the final recipient with a 200 (OK) response containing the received request message as the response entity-body (as described in section 9.8). If the received Max-Forwards value is greater than zero, then the forwarded message SHOULD contain an updated Max- Forwards field with a value decremented by one (1).
要求を転送する前に、マックスを含むTRACE要求の各プロキシかゲートウェイ受取人がSHOULDがチェックして、アップデートするヘッダーフィールドに値を送ります。 容認された値が(0)でないなら、受取人SHOULD NOTは要求を転送します。 代わりにそれ、200(OK)応答が応答実体本体として受信された要求メッセージを含んでいて、SHOULDは最終的な受取人として応じます(セクション9.8で説明されるように)。 容認された前方へマックス値がゼロ以上であるなら、転送されたメッセージSHOULDは値がある分野が1つ(1)減少させたアップデートされたマックスフォワードを含んでいます。
The Max-Forwards header field SHOULD be ignored for all other methods defined by this specification and for any extension methods for which it is not explicitly referred to as part of that method definition.
前方へマックスヘッダーはそのメソッド定義の一部としてこの仕様で定義された他のすべてのメソッドのために無視されて、それが明らかにそうでないどんな拡大メソッドについても言及されたSHOULDをさばきます。
14.32 Pragma
14.32 Pragma
The Pragma general-header field is used to include implementation- specific directives that may apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives.
Pragmaの一般的なヘッダーフィールドは、要求/応答チェーンに沿ったどんな受取人にも適用されるかもしれない実装の特定の指示を含むのに使用されます。 すべてのpragma指示がプロトコルの観点から任意の振舞いを指定します。 しかしながら、いくつかのシステムが、振舞いが指示と一致しているのを必要とするかもしれません。
Pragma = "Pragma" ":" 1#pragma-directive
「Pragmaは"Pragma"と等しい」:、」 1#pragma-指示
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
pragma-指示=「キャッシュがありません」| 拡大-pragma拡大-pragmaはトークンと等しいです。[「=」(トークン| 引用文字列)]
When the no-cache directive is present in a request message, an application SHOULD forward the request toward the origin server even if it has a cached copy of what is being requested. This pragma directive has the same semantics as the no-cache cache-directive (see section 14.9) and is defined here for backwards compatibility with HTTP/1.0. Clients SHOULD include both header fields when a no-cache request is sent to a server not known to be HTTP/1.1 compliant.
キャッシュがない指示が要求メッセージに存在しているとき、それに何に関するキャッシュされたコピーがあっても、SHOULDが発生源サーバに向かった要求を転送する申込み書は要求されています。 このpragma指示は、キャッシュがないキャッシュ指示(セクション14.9を見る)と同じ意味論を持って、HTTP/1.0との遅れている互換性のためにここで定義されます。 HTTP/1.1が対応であったなら知られないサーバにキャッシュ要求を全く送らないとき、クライアントSHOULDは両方のヘッダーフィールドを含んでいます。
Pragma directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific recipient; however, any pragma directive not relevant to a recipient SHOULD be ignored by that recipient.
プロキシかゲートウェイアプリケーションでPragma指示を通り抜けなければなりません、そのアプリケーションへのそれらの意味にかかわらず、指示が要求/応答チェーンに沿ったすべての受取人に適切であるかもしれないので。 特定の受取人にpragmaを指定するのは可能ではありません。 しかしながら、いずれも受取人SHOULDに関連していない指示をpragmaします。その受取人によって無視されます。
Fielding, et. al. Standards Track [Page 126] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[126ページ]RFC2068HTTP/1997年1月1.1日
HTTP/1.1 clients SHOULD NOT send the Pragma request-header. HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had sent "Cache-Control: no-cache". No new Pragma directives will be defined in HTTP.
HTTP/1.1クライアントSHOULD NOTはPragma要求ヘッダーを送ります。 HTTP/1.1がSHOULDの御馳走をキャッシュする、「Pragma:」 まるでクライアントが発信したかのように「キャッシュがありません」は「以下をキャッシュで制御します」。 「キャッシュしません」。 どんな新しいPragma指示もHTTPで定義されないでしょう。
14.33 Proxy-Authenticate
14.33はプロキシで認証します。
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI.
応答ヘッダ分野をProxy認証してください、407(プロキシAuthentication Required)応答の一部として含まなければなりません。 分野値は認証体系について簡単に述べる挑戦とこのRequest-URIに、プロキシに適切なパラメタから成ります。
Proxy-Authenticate = "Proxy-Authenticate" ":" challenge
「プロキシ認証、=が「プロキシで認証する」、」、:、」 挑戦
The HTTP access authentication process is described in section 11. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and SHOULD NOT be passed on to downstream clients. However, an intermediate proxy may need to obtain its own credentials by requesting them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate header field.
HTTPアクセス認証過程はセクション11で説明されます。 分野が現在の接続とSHOULD NOTだけに適用するヘッダーをProxy認証してください。WWW認証、川下クライアントに渡されてください。 しかしながら、中間的プロキシが、川下のクライアントからそれらを要求することによってそれ自身の資格証明書を得る必要があるかもしれない、ヘッダーフィールドをProxy認証してください。そのクライアントは、まるでプロキシが進めているかのようにいくつかの事情で見えるでしょう。
14.34 Proxy-Authorization
14.34 プロキシ承認
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy which requires authentication. The Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested.
Proxy-承認要求ヘッダーフィールドで、クライアント自身は、どれが認証を必要とするかをプロキシに特定できます(または、ユーザ)。 Proxy-承認分野価値は要求されているリソースのプロキシ、そして/または、分野にユーザエージェントの認証情報を含む資格証明書から成ります。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
「プロキシ承認=「プロキシ承認」」:、」 資格証明書
The HTTP access authentication process is described in section 11. Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed by the first outbound proxy that was expecting to receive credentials. A proxy MAY relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request.
HTTPアクセス認証過程はセクション11で説明されます。 Authorizationと異なって、Proxy-承認ヘッダーフィールドが認証使用を要求した次期外国行きのプロキシだけに適用される、分野をProxy認証してください。 複数のプロキシがチェーンに使用されるとき、Proxy-承認ヘッダーフィールドは第1代資格証明書を受けると予想していた外国行きのプロキシによって消費されます。 プロキシはそれがプロキシが協力して与えられた要求を認証するメカニズムであるならクライアント要求から次期プロキシまで資格証明書をリレーするかもしれません。
14.35 Public
14.35 公衆
The Public response-header field lists the set of methods supported by the server. The purpose of this field is strictly to inform the recipient of the capabilities of the server regarding unusual methods. The methods listed may or may not be applicable to the
Public応答ヘッダ分野はサーバによってサポートされたメソッドのセットを記載します。この分野の目的は一風変わった方法に関するサーバの能力について厳密に受取人に知らせることです。 記載されたメソッドは適切であるかもしれません。
Fielding, et. al. Standards Track [Page 127] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[127ページ]RFC2068HTTP/1997年1月1.1日
Request-URI; the Allow header field (section 14.7) MAY be used to indicate methods allowed for a particular URI.
要求URI。 Allowヘッダーフィールド(セクション14.7)は、メソッドが特定のURIを考慮したのを示すのに使用されるかもしれません。
Public = "Public" ":" 1#method
「公共の=「公衆」」:、」 1#メソッド
Example of use:
使用に関する例:
Public: OPTIONS, MGET, MHEAD, GET, HEAD
公衆: ヘッド、オプション(MGET、MHEAD)は得られます。
This header field applies only to the server directly connected to the client (i.e., the nearest neighbor in a chain of connections). If the response passes through a proxy, the proxy MUST either remove the Public header field or replace it with one applicable to its own capabilities.
このヘッダーフィールドは直接クライアント(すなわち、接続のチェーンで最も近い隣人)に接されたサーバだけに適用されます。 応答がプロキシを通り抜けるなら、プロキシは、それ自身の能力に適切な状態でPublicヘッダーフィールドを移さなければならないか、またはそれを1つに取り替えなければなりません。
14.36 Range
14.36 範囲
14.36.1 Byte Ranges
14.36.1 バイト範囲
Since all HTTP entities are represented in HTTP messages as sequences of bytes, the concept of a byte range is meaningful for any HTTP entity. (However, not all clients and servers need to support byte- range operations.)
すべてのHTTP実体がバイトの系列としてHTTPメッセージに表されるので、どんなHTTP実体にも、1つのバイト範囲の概念は重要です。 (しかしながら、すべてのクライアントとどんなサーバも、バイト範囲操作をサポートする必要がありません。)
Byte range specifications in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).
HTTPにおけるバイト範囲指定は実体本体(必ずメッセージ本体と同じであるというわけではない)のバイトの系列に適用されます。
A byte range operation may specify a single range of bytes, or a set of ranges within a single entity.
バイト範囲操作は単一体の中でただ一つの範囲のバイト、または1セットの範囲を指定するかもしれません。
ranges-specifier = byte-ranges-specifier
範囲特許説明書の作成書=バイト範囲特許説明書の作成書
byte-ranges-specifier = bytes-unit "=" byte-range-set
バイト範囲特許説明書の作成書=バイト-ユニット「=」バイト範囲セット
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
バイト範囲セット=1#(バイト範囲仕様| 接尾語バイト範囲仕様)
byte-range-spec = first-byte-pos "-" [last-byte-pos]
バイト範囲仕様は最初のバイトpos「-」と等しいです。[バイトposを持続しています]です。
first-byte-pos = 1*DIGIT
最初のバイトposは1*DIGITと等しいです。
last-byte-pos = 1*DIGIT
バイトposを持続している=1*DIGIT
The first-byte-pos value in a byte-range-spec gives the byte-offset of the first byte in a range. The last-byte-pos value gives the byte-offset of the last byte in the range; that is, the byte positions specified are inclusive. Byte offsets start at zero.
バイト範囲仕様の最初のバイトpos値は範囲での最初のバイトのバイトオフセットを与えます。 バイトposを持続している値は範囲での最後のバイトのバイトオフセットを与えます。 すなわち、指定されたバイト位置は包括的です。 バイトはゼロで始めを相殺します。
Fielding, et. al. Standards Track [Page 128] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[128ページ]RFC2068HTTP/1997年1月1.1日
If the last-byte-pos value is present, it must be greater than or equal to the first-byte-pos in that byte-range-spec, or the byte- range-spec is invalid. The recipient of an invalid byte-range-spec must ignore it.
バイトposを持続している値が存在しているなら、それは、より存在しているに違いありません。中のバイト範囲仕様、またはバイト範囲仕様がそうである最初のバイトpos病人。 無効のバイト範囲仕様の受取人はそれを無視しなければなりません。
If the last-byte-pos value is absent, or if the value is greater than or equal to the current length of the entity-body, last-byte-pos is taken to be equal to one less than the current length of the entity- body in bytes.
最後のバイトがposされているなら、値は欠けているか、またはposにバイトを持続している実体本体の現在長が値がそう以上なら欠けています。バイトで表現される実体本体の現在長よりそれほど1つと等しいのを取ります。
By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.
最後のバイトがposされたaクライアントの選択は実体のサイズを知らないで検索されたバイト数を制限できます。
suffix-byte-range-spec = "-" suffix-length
接尾語バイト範囲仕様は「-」接尾語長さと等しいです。
suffix-length = 1*DIGIT
接尾語長さは1*DIGITと等しいです。
A suffix-byte-range-spec is used to specify the suffix of the entity-body, of a length given by the suffix-length value. (That is, this form specifies the last N bytes of an entity-body.) If the entity is shorter than the specified suffix-length, the entire entity-body is used.
接尾語バイト範囲仕様は、実体本体、接尾語長さの値によって与えられた長さの接尾語を指定するのに使用されます。 (すなわち、このフォームは実体本体の最後のNバイトを指定します。) 実体が指定された接尾語長さより短いなら、全体の実体本体は使用されています。
Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):
バイト範囲特許説明書の作成書値(長さ10000の実体本体を仮定する)に関する例:
o The first 500 bytes (byte offsets 0-499, inclusive):
o 最初の500バイト(バイトは0-499で、包括的に相殺されます):
bytes=0-499
バイトは0-499と等しいです。
o The second 500 bytes (byte offsets 500-999, inclusive):
o 2番目の500バイト(バイトは500-999で、包括的に相殺されます):
bytes=500-999
バイトは500-999と等しいです。
o The final 500 bytes (byte offsets 9500-9999, inclusive):
o 最終的な500バイト(バイトは9500-9999で、包括的に相殺されます):
bytes=-500
バイト=-500
o Or
o または
bytes=9500-
バイト=9500、-
o The first and last bytes only (bytes 0 and 9999):
o 1番目と最後のバイト(0と9999のバイト)専用:
bytes=0-0,-1
バイトは0-0-1と等しいです。
Fielding, et. al. Standards Track [Page 129] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[129ページ]RFC2068HTTP/1997年1月1.1日
o Several legal but not canonical specifications of the second
500 bytes (byte offsets 500-999, inclusive):
o 2番目の500バイト(バイトは500-999で、包括的に相殺される)のいくつかの法的な、しかし、正準でない仕様:
bytes=500-600,601-999
バイトは500-600,601-999と等しいです。
bytes=500-700,601-999
バイトは500-700,601-999と等しいです。
14.36.2 Range Retrieval Requests
14.36.2 範囲検索要求
HTTP retrieval requests using conditional or unconditional GET methods may request one or more sub-ranges of the entity, instead of the entire entity, using the Range request header, which applies to the entity returned as the result of the request:
条件付きの、または、無条件のGETメソッドを使用するHTTP検索要求は実体の1つ以上のサブ範囲を要求するかもしれません、全体の実体の代わりに、要求の結果として返された実体に適用するRange要求ヘッダーを使用して:
Range = "Range" ":" ranges-specifier
「範囲=「範囲」」:、」 範囲特許説明書の作成書
A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches SHOULD support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.
サーバはRangeヘッダーを無視するかもしれません。 しかしながら、可能であるときに、HTTP/1.1発生源サーバと中間的キャッシュSHOULDサポートバイトは及びます、Rangeが部分的に失敗した転送からの効率的な回復をサポートして、大きい実体の効率的な部分的な検索をサポートするので。
If the server supports the Range header and the specified range or ranges are appropriate for the entity:
実体に、サーバがRangeヘッダーを支えるか、そして、指定された範囲か範囲が適切です:
o The presence of a Range header in an unconditional GET modifies
what is returned if the GET is otherwise successful. In other
words, the response carries a status code of 206 (Partial
Content) instead of 200 (OK).
o 無条件のGETでのRangeヘッダーの存在はそうでなければ、GETがうまくいくなら返されるものを変更します。 言い換えれば、応答は200(OK)の代わりに206(部分的なContent)のステータスコードを運びます。
o The presence of a Range header in a conditional GET (a request
using one or both of If-Modified-Since and If-None-Match, or
one or both of If-Unmodified-Since and If-Match) modifies what
is returned if the GET is otherwise successful and the condition
is true. It does not affect the 304 (Not Modified) response
returned if the conditional is false.
o 条件付きのGET(以来変更されていないIfとIf-マッチの1つを使用する要求、以来変更されたIfとなにも合わせないIfの両方、1または両方)でのRangeヘッダーの存在はそうでなければ、GETがうまくいっていて、状態が本当であるなら返されるものを変更します。 それは条件付きが誤っているなら返された304(Modifiedでない)応答に影響しません。
In some cases, it may be more appropriate to use the If-Range header (see section 14.27) in addition to the Range header.
いくつかの場合、Rangeヘッダーに加えたIf-範囲ヘッダー(セクション14.27を見る)を使用するのは、より適切であるかもしれません。
If a proxy that supports ranges receives a Range request, forwards the request to an inbound server, and receives an entire entity in reply, it SHOULD only return the requested range to its client. It SHOULD store the entire received response in its cache, if that is consistent with its cache allocation policies.
プロキシであるなら、範囲がRange要求を受け取って、本国行きのサーバに要求を転送して、全体の実体を受けるサポートが返答して、それがSHOULDであることは要求された範囲をクライアントに返すだけです。 それ、それがキャッシュ配分方針と一致しているなら、SHOULDはキャッシュにおける全体の容認された応答を保存します。
Fielding, et. al. Standards Track [Page 130] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[130ページ]RFC2068HTTP/1997年1月1.1日
14.37 Referer
14.37 Referer
The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.) The Referer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
クライアントはReferer[原文のまま]要求ヘッダーフィールドで指定できます、サーバの利益のために、Request-URIが得られたリソースのアドレス(URI)(ヘッダーフィールドがスペルミスされますが、「リファラー」。) Referer要求ヘッダーはサーバに関心、伐採、最適化されたキャッシュなどのためのリソースに逆リンクのリストを生成させます。 また、それは、時代遅れの、または、mistypedされたリンクがメインテナンスのためにたどられるのを許容します。 ユーザキーボードから入力されるようなそれ自身のURIを持っていないソースからRequest-URIを得たなら、Referer野原を送ってはいけません。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
「Refererは"Referer"と等しい」:、」 (absoluteURI| relativeURI)
Example:
例:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If the field value is a partial URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment.
分野値は部分的なURIであり、それはSHOULDです。Request-URIに比例して、解釈されます。 URIは断片を含んではいけません。
Note: Because the source of a link may be private information or
may reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From
information.
以下に注意してください。 リンクの情報筋が個人情報であるかもしれないかそうでなければ、個人的な情報源を明らかにするかもしれないので、ユーザが、Referer野原が送られるかどうかを選択できることが強く勧められます。 例えば、ブラウザクライアントはオープンに匿名で/をブラウズするためのトグルスイッチを持つことができました。(それは、それぞれRefererとFrom情報の発信を可能にするか、または無効にするでしょう)。
14.38 Retry-After
14.38 再試行します。
The Retry-After response-header field can be used with a 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.
どれくらい長い間サービスが要求しているクライアントにとって入手できないと予想されるかを示すのに503(サービスUnavailable)応答と共に後のRetry応答ヘッダ分野を使用できます。 この分野の値は、応答の時間の後のHTTP日付か整数秒数のどちらかであるかもしれません(小数における)。
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
「-後に=「再試行した後」を再試行してください」:、」 (HTTP日付|デルタ秒)
Two examples of its use are
使用に関する2つの例がそうです。
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
-後に再試行してください: グリニッジ標準時1999年12月31日金曜日23時59分59秒の再試行した後: 120
In the latter example, the delay is 2 minutes.
後者の例では、遅れは2分です。
Fielding, et. al. Standards Track [Page 131] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[131ページ]RFC2068HTTP/1997年1月1.1日
14.39 Server
14.39 サーバ
The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server応答ヘッダ分野は発生源サーバによって使用される、要求を扱うソフトウェアの情報を含んでいます。 分野は複数の製品トークン(セクション3.8)、サーバを特定するコメント、およびどんな重要な「副-製品」も含むことができます。 製品トークンはアプリケーションを特定するためのそれらの意味の順に記載されています。
Server = "Server" ":" 1*( product | comment )
「サーバ=「サーバ」」:、」 1*(製品| コメント)
Example:
例:
Server: CERN/3.0 libwww/2.17
サーバ: CERN/3.0libwww/2.17
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (as described in section 14.44).
プロキシを通して応答を進めているなら、プロキシアプリケーションはServer応答ヘッダを変更してはいけません。 代わりにそれ、SHOULDはVia分野を含んでいます(セクション14.44で説明されるように)。
Note: Revealing the specific software version of the server may
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementers are encouraged to make this field a configurable
option.
以下に注意してください。 サーバの特定のソフトウェアバージョンを明らかにすることによって、サーバマシンはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 サーバimplementersがこの分野を構成可能なオプションにするよう奨励されます。
14.40 Transfer-Encoding
14.40 転送コード化
The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the Content-Encoding in that the transfer coding is a property of the message, not of the entity.
Transferをコード化している一般的なヘッダーフィールドは、どんな(もしあれば)タイプの変換が安全に送付者と受取人の間にそれを移すためにメッセージ本体に適用されたかを示します。 これは転送コード化が実体ではなく、メッセージの特性であるという点においてContent-コード化と異なっています。
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-
coding
「「転送コード化転送をコード化する=」」:、」 1#転送コード化
Transfer codings are defined in section 3.6. An example is:
転送コーディングはセクション3.6で定義されます。 例は以下の通りです。
Transfer-Encoding: chunked
転送をコード化しています: chunkedしました。
Many older HTTP/1.0 applications do not understand the Transfer- Encoding header.
多くの、より古いHTTP/1.0のアプリケーションはTransferのコード化しているヘッダーを理解していません。
14.41 Upgrade
14.41 アップグレード
The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server
サーバが、プロトコルを切り換えるのが適切であることがわかるなら、Upgradeの一般的なヘッダーはそれがどんな追加通信プロトコルをサポートして、使用したがっているかをクライアントを指定させます。 サーバ
Fielding, et. al. Standards Track [Page 132] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[132ページ]RFC2068HTTP/1997年1月1.1日
MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
どのプロトコルが切り換えられているかを示すのに101(切り換えプロトコル)応答の中でUpgradeヘッダーフィールドを使用しなければなりません。
Upgrade = "Upgrade" ":" 1#product
「アップグレードは「アップグレード」と等しい」:、」 1#製品
For example,
例えば
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
アップグレード: HTTP/2.0、SHTTP/1.3、IRC/6.9、RTA/x11
The Upgrade header field is intended to provide a simple mechanism for transition from HTTP/1.1 to some other, incompatible protocol. It does so by allowing the client to advertise its desire to use another protocol, such as a later version of HTTP with a higher major version number, even though the current request has been made using HTTP/1.1. This eases the difficult transition between incompatible protocols by allowing the client to initiate a request in the more commonly supported protocol while indicating to the server that it would like to use a "better" protocol if available (where "better" is determined by the server, possibly according to the nature of the method and/or resource being requested).
UpgradeヘッダーフィールドがHTTP/1.1からの変遷のための簡単なメカニズムを提供することを意図する、ある他の両立しないプロトコル。 別のプロトコルを使用する願望はクライアントを許容することによって、そう広告を出します、より高いメジャーバージョン番号があるHTTPの後のバージョンのように、HTTP/1.1を使用することで現在の要求をしましたが。 利用可能であるなら(ことによると要求されているメソッド、そして/または、リソースの本質によると、「より良い」がサーバで決定するところ)「より良い」プロトコルを使用したがっているのをサーバに示している間、クライアントが一般的によりサポートしているプロトコルにおける要求を開始するのを許容することによって、これは両立しないプロトコルの間の難しい変遷を緩和します。
The Upgrade header field only applies to switching application-layer protocols upon the existing transport-layer connection. Upgrade cannot be used to insist on a protocol change; its acceptance and use by the server is optional. The capabilities and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen, although the first action after changing the protocol MUST be a response to the initial HTTP request containing the Upgrade header field.
Upgradeヘッダーフィールドは既存のトランスポート層接続のときに切り換え応用層プロトコルに適用されるだけです。 プロトコル変化を強要するのにアップグレードを使用できません。 サーバによるその承認と使用は任意です。 プロトコル変化の後の応用層コミュニケーションの能力と本質はプロトコルを変えた後の最初の動作がUpgradeヘッダーフィールドを含む初期のHTTP要求への応答であるに違いありませんが、選ばれた新しいプロトコルに完全に依存しています。
The Upgrade header field only applies to the immediate connection. Therefore, the upgrade keyword MUST be supplied within a Connection header field (section 14.10) whenever Upgrade is present in an HTTP/1.1 message.
Upgradeヘッダーフィールドは即座の接続に適用されるだけです。 したがって、UpgradeがHTTP/1.1メッセージに存在しているときはいつも、Connectionヘッダーフィールド(セクション14.10)の中でアップグレードキーワードを提供しなければなりません。
The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it is more appropriate to use a 301, 302, 303, or 305 redirection response.
異なった接続のときにスイッチをプロトコルに示すのにUpgradeヘッダーフィールドを使用できません。 そのために、301、302、303、または305リダイレクション応答を使用するのは、より適切です。
This specification only defines the protocol name "HTTP" for use by the family of Hypertext Transfer Protocols, as defined by the HTTP version rules of section 3.1 and future updates to this specification. Any token can be used as a protocol name; however, it will only be useful if both the client and server associate the name with the same protocol.
この仕様はハイパーテキスト転送プロトコルのファミリーによる使用のために「HTTP」というプロトコル名を定義するだけです、この仕様へのセクション3.1と将来のアップデートのHTTPバージョン規則で定義されるように。 プロトコル名としてどんなトークンも使用できます。 しかしながら、クライアントとサーバの両方が同じプロトコルの名前を関連づける場合にだけ、役に立ちます。
Fielding, et. al. Standards Track [Page 133] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[133ページ]RFC2068HTTP/1997年1月1.1日
14.42 User-Agent
14.42 ユーザエージェント
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-エージェント要求ヘッダーフィールドは要求を溯源するユーザエージェントの情報を含んでいます。 これは統計的な目的、プロトコル違反をたどること、および特定のユーザエージェント制限を避けるために応答を合わせることのためにユーザエージェントの自動化された認識のためのものです。 ユーザエージェントSHOULDは要求があるこの分野を含んでいます。 分野はユーザエージェントのかなりの部分を形成する複数の製品トークン(セクション3.8)、エージェントを特定するコメント、およびどんな「副-製品」も含むことができます。 コンベンションによって、製品トークンはアプリケーションを特定するためのそれらの意味の順に記載されています。
User-Agent = "User-Agent" ":" 1*( product | comment )
「ユーザエージェント=「ユーザエージェント」」:、」 1*(製品| コメント)
Example:
例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
ユーザエージェント: CERN-LineMode/2.15libwww/2.17b3
14.43 Vary
14.43は異なります。
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of
the response using server-driven negotiation (section 12). Field-
names listed in Vary headers are those of request-headers. The Vary
field value indicates either that the given set of header fields
encompass the dimensions over which the representation might vary, or
that the dimensions of variance are unspecified ("*") and thus may
vary over any aspect of future requests.
Vary応答ヘッダ分野はサーバによって使用されて、応答実体が応答の利用可能な表現からサーバ駆動の交渉(セクション12)を使用することで選択されたと合図します。 Varyヘッダーに記載された分野名は要求ヘッダーのものです。 Vary分野価値は変化の次元が与えられたセットのヘッダーフィールドが表現が異なるかもしれない寸法を包含するか、不特定の(「*」)であり、またはその結果、今後の要求のどんな局面についても異なるかもしれないのを示します。
Vary = "Vary" ":" ( "*" | 1#field-name )
「=「異なること」を変えてください」:、」 (「*」| 1#フィールド名)
An HTTP/1.1 server MUST include an appropriate Vary header field with any cachable response that is subject to server-driven negotiation. Doing so allows a cache to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that resource. A server SHOULD include an appropriate Vary header field with a non-cachable response that is subject to server-driven negotiation, since this might provide the user agent with useful information about the dimensions over which the response might vary.
HTTP/1.1サーバはどんなサーバ駆動の交渉を受けることがあるキャッシュ可能応答がある適切なVaryヘッダーフィールドも含まなければなりません。 そうするのは適切にそのリソースに関する今後の要求を解釈するためにキャッシュを許容して、そのリソースの交渉の存在に関してユーザエージェントに知らせます。 サーバSHOULDはサーバ駆動の交渉を受けることがある非キャッシュ可能応答がある適切なVaryヘッダーフィールドを含んでいます、これが応答が異なるかもしれない寸法に関する役に立つ情報をユーザエージェントに提供するかもしれないので。
The set of header fields named by the Vary field value is known as the "selecting" request-headers.
Vary分野価値によって指定されたヘッダーフィールドのセットは「選択」要求ヘッダーとして知られています。
When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the headers named in the cached Vary header
キャッシュがRequest-URIがVaryヘッダーを含む1つ以上のキャッシュエントリーを指定するその後の要求を受け取るとき、ヘッダーが皆、キャッシュでVaryをヘッダーと命名しなかったなら、キャッシュは、新しい要求への応答を構成するのにそのようなキャッシュエントリーを使用してはいけません。
Fielding, et. al. Standards Track [Page 134] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[134ページ]RFC2068HTTP/1997年1月1.1日
are present in the new request, and all of the stored selecting request-headers from the previous request match the corresponding headers in the new request.
プレゼントが新しい要求にあります、そして、前の要求から要求ヘッダーを選ぶ保存のすべてが新しい要求で対応するヘッダーに合っています。
The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear whitespace (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message- header fields with the same field name following the rules about message headers in section 4.2.
選択2からの要求ヘッダー要求が合うように定義される、選択2番目の要求ヘッダーがこれが対応するBNFによって許容されている場所で直線的な空白(LWS)を加えるか、または取り除くことによって要求する選択に変えることができる、そして/または、セクションでメッセージヘッダーの周りで約束を守る同じフィールド名に複数のメッセージヘッダーフィールドを結合する最初の要求における要求ヘッダー4.2だけです。
A Vary field value of "*" signals that unspecified parameters, possibly other than the contents of request-header fields (e.g., the network address of the client), play a role in the selection of the response representation. Subsequent requests on that resource can only be properly interpreted by the origin server, and thus a cache MUST forward a (possibly conditional) request even when it has a fresh response cached for the resource. See section 13.6 for use of the Vary header by caches.
「*」のVary分野価値は、ことによると要求ヘッダーフィールド(例えば、クライアントのネットワーク・アドレス)のコンテンツを除いて、不特定のパラメタが応答表現の選択における役割を果たすのを示します。 発生源サーバで適切にそのリソースに関するその後の要求を解釈できるだけです、そして、リソースのためにそれで新鮮な応答をキャッシュさえするとき、その結果、キャッシュは(ことによると条件付き)の要求を転送しなければなりません。 キャッシュでVaryヘッダーの使用に関してセクション13.6を見てください。
A Vary field value consisting of a list of field-names signals that the representation selected for the response is based on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. A cache MAY assume that the same selection will be made for future requests with the same values for the listed field names, for the duration of time in which the response is fresh.
応答のために選択された表現があるというフィールド名信号のリストから成るVary分野価値は、どれが最も適切な表現を選択する際に記載された要求ヘッダーフィールド値だけを考えるかを選択アルゴリズムに基礎づけました。 キャッシュは、今後の要求のために記載されたフィールド名のための同じ値で同じ選択をすると仮定するかもしれません、応答が新鮮である時間の持続時間のために。
The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names are case-insensitive.
与えられたフィールド名はこの仕様で定義された標準の要求ヘッダーフィールドのセットに制限されません。 フィールド名は大文字と小文字を区別しないです。
14.44 Via
を通して14.44。
The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.
ゲートウェイとプロキシは、応答のときにユーザエージェントと要求でのサーバと、発生源サーバとクライアントの間の中間的プロトコルと受取人を示すのにViaの一般的なヘッダーフィールドを使用しなければなりません。 それは、RFC822の「受け取られていている」分野に類似していて、追跡メッセージフォワードに使用されることを意図します、要求輪を避けて、要求/応答チェーンに沿ったすべての送付者のプロトコル能力を特定して。
Fielding, et. al. Standards Track [Page 135] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[135ページ]RFC2068HTTP/1997年1月1.1日
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
=を通して「「を通して」、」、:、」 1#(受け取られた受け取られていているプロトコル[コメント])
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
「受け取られていているプロトコル=、[」 /をプロトコルで命名してください、」、]、受け取られたトークンプロトコルプロトコルバージョンプロトコル名=バージョン=トークンは(ホスト[「:」 ポート])と等しいです。| 匿名匿名=トークン
The received-protocol indicates the protocol version of the message received by the server or client along each segment of the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded so that information about the protocol capabilities of upstream applications remains visible to all recipients.
受け取られていているプロトコルは、メッセージのプロトコルバージョンが要求/応答チェーンの各区分に沿ってサーバかクライアントのそばで受信されたのを示します。 メッセージを転送するとき、受け取られていているプロトコルバージョンをVia分野価値に追加するので、上流のアプリケーションのプロトコル能力の情報はすべての受取人にとって目に見えたままで残っています。
The protocol-name is optional if and only if it would be "HTTP". The received-by field is normally the host and optional port number of a recipient server or client that subsequently forwarded the message. However, if the real host is considered to be sensitive information, it MAY be replaced by a pseudonym. If the port is not given, it MAY be assumed to be the default port of the received-protocol.
プロトコル名が任意である、それである場合にだけ、「HTTP」はそうでしょう。 受け取って、通常、分野は、次にメッセージを転送した受取人サーバかクライアントのホストと任意のポートナンバーです。 しかしながら、機密情報であると本当のホストを考えるなら、それを匿名に取り替えるかもしれません。 ポートが与えられないなら、それは受け取られていているプロトコルのデフォルトポートであると思われるかもしれません。
Multiple Via field values represent each proxy or gateway that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications.
複数のVia分野値がメッセージを転送した各プロキシかゲートウェイの代理をします。 各受取人が情報を追加しなければならないので、推進アプリケーションの系列によると、結末は命令されます。
Comments MAY be used in the Via header field to identify the software of the recipient proxy or gateway, analogous to the User-Agent and Server header fields. However, all comments in the Via field are optional and MAY be removed by any recipient prior to forwarding the message.
コメントは受取人プロキシかゲートウェイのソフトウェアを特定するのにViaヘッダーフィールドに使用されるかもしれません、User-エージェントとServerヘッダーフィールドに類似しています。 しかしながら、Via分野でのすべてのコメントが、任意であり、メッセージを転送する前に、どんな受取人によっても取り除かれるかもしれません。
For example, a request message could be sent from an HTTP/1.0 user agent to an internal proxy code-named "fred", which uses HTTP/1.1 to forward the request to a public proxy at nowhere.com, which completes the request by forwarding it to the origin server at www.ics.uci.edu. The request received by www.ics.uci.edu would then have the following Via header field:
例えば、HTTP/1.0ユーザエージェントから内部の発生源サーバにそれを送ることによって要求をwww.ics.uci.eduに終了するnowhere.comの公共のプロキシに要求を転送するのにHTTP/1.1を使用する"fred"とコード名を付けられたプロキシに要求メッセージを送ることができました。 次に、www.ics.uci.eduによって受け取られた要求は以下のViaヘッダーフィールドを持っているでしょう:
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
以下を通って 1.0 fred、1.1nowhere.com(アパッチ/1.1)
Proxies and gateways used as a portal through a network firewall SHOULD NOT, by default, forward the names and ports of hosts within the firewall region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the received-by host of any host behind the firewall SHOULD be replaced by an appropriate pseudonym for that host.
プロキシとゲートウェイがデフォルトで入り口としてネットワークファイアウォールを通してSHOULD NOTを使用して、フォワードは、ファイアウォール領域の中のホストの名前とポートです。 この情報SHOULD、明らかに可能にされるなら、単に伝播されてください。 そうでなければ、可能にされて、受け取るのはファイアウォールの後ろでどんなホストにもSHOULDを接待します。そのホストのために適切な匿名に取り替えます。
Fielding, et. al. Standards Track [Page 136] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[136ページ]RFC2068HTTP/1997年1月1.1日
For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical received-protocol values into a single such entry. For example,
内部の構造、プロキシ5月のコンバインを隠すための強いプライバシー要件を持っている組織のために、同じ受け取られていているプロトコルによるViaヘッダーフィールド入力の命令された続きは単一のそのようなものにエントリーを評価します。 例えば
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
以下を通って 1.0 ricky、1.1ethel、1.1fred、1.0lucy
could be collapsed to
崩れることができました。
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
以下を通って 1.0 ricky、1.1mertz、1.0lucy
Applications SHOULD NOT combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced by pseudonyms. Applications MUST NOT combine entries which have different received-protocol values.
それらが同じ組織的なコントロールの下にない場合、アプリケーションSHOULD NOTは多回入国を結合します、そして、既にホストを匿名に取り替えました。アプリケーションは、異なった受け取られていているプロトコル値を持っているエントリーを結合してはいけません。
14.45 Warning
14.45 警告
The Warning response-header field is used to carry additional information about the status of a response which may not be reflected by the response status code. This information is typically, though not exclusively, used to warn about a possible lack of semantic transparency from caching operations.
Warning応答ヘッダ分野は、応答ステータスコードによって反映されないかもしれない応答の状態に関する追加情報を運ぶのに使用されます。 排他的ではありませんが、この情報は操作をキャッシュするので意味の透明性の可能な不足を警告するのにおいて通常使用されています。
Warning headers are sent with responses using:
以下を使用する応答と共に警告ヘッダーを送ります。
Warning = "Warning" ":" 1#warning-value
「警告は「警告」と等しい」:、」 1#警告値
warning-value = warn-code SP warn-agent SP warn-text
warn-code = 2DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
警告値が等しい、警告する、エージェントに警告しているSP SP、警告する、警告する、エージェントに警告している2DIGIT=([「:」 ポート]を接待する)と等しいです。| 匿名。 サーバ付加の名前か匿名。 デバッグにおける使用のためのWarningヘッダー、警告する、=引用文字列
A response may carry more than one Warning header.
応答は1個以上のWarningヘッダーを運ぶかもしれません。
The warn-text should be in a natural language and character set that is most likely to be intelligible to the human user receiving the response. This decision may be based on any available knowledge, such as the location of the cache or user, the Accept-Language field in a request, the Content-Language field in a response, etc. The default language is English and the default character set is ISO- 8859-1.
警告する、自然言語と文字集合において、それが応答を受ける人間のユーザにとって明瞭である最も傾向があるということであるべきです。 この決定はどんな利用可能な知識にも基づくかもしれません、キャッシュかユーザの位置などのように、要求におけるAccept-言語分野、応答などにおけるContent-言語分野 デフォルト言語はイギリスのです、そして、デフォルト文字集合はISO8859-1です。
If a character set other than ISO-8859-1 is used, it MUST be encoded in the warn-text using the method described in RFC 1522 [14].
ISO-8859-1以外の文字集合が使用されているなら、中でそれをコード化しなければならない、警告する、メソッドを使用すると、RFCでは、1522[14]は説明されました。
Fielding, et. al. Standards Track [Page 137] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[137ページ]RFC2068HTTP/1997年1月1.1日
Any server or cache may add Warning headers to a response. New Warning headers should be added after any existing Warning headers. A cache MUST NOT delete any Warning header that it received with a response. However, if a cache successfully validates a cache entry, it SHOULD remove any Warning headers previously attached to that entry except as specified for specific Warning codes. It MUST then add any Warning headers received in the validating response. In other words, Warning headers are those that would be attached to the most recent relevant response.
どんなサーバやキャッシュもWarningヘッダーを応答に加えるかもしれません。 どんな新しいWarning Warningヘッダーも既存の次々と加えられるべきです。 キャッシュはそれが応答で受けたどんなWarningヘッダーも削除してはいけません。 しかしながら、aであるなら、キャッシュは首尾よくキャッシュエントリーを有効にします、それ。SHOULDは特定のWarningコードに指定されるのを除いて、以前にそのエントリーに取り付けられたどんなWarningヘッダーも取り除きます。 そして、それは、どんなWarningヘッダーも有効にする応答で受信したと言い足さなければなりません。 言い換えれば、Warningヘッダーは最新の関連応答に付けられているものです。
When multiple Warning headers are attached to a response, the user agent SHOULD display as many of them as possible, in the order that they appear in the response. If it is not possible to display all of the warnings, the user agent should follow these heuristics:
複数のWarningヘッダーが応答に取り付けられるとき、ユーザエージェントSHOULDはできるだけ多くの彼らを表示します、彼らが応答で見えるオーダーで。 警告のすべてを表示するのが可能でないなら、ユーザエージェントはこれらの発見的教授法に従うべきです:
o Warnings that appear early in the response take priority over those
appearing later in the response.
o Warnings in the user's preferred character set take priority over
warnings in other character sets but with identical warn-codes and
warn-agents.
o 早く応答に現れる警告は後でのそれらの排臨の上で応答で優先します。ユーザの都合のよい文字集合におけるo Warningsが文字集合にもかかわらず、同じで警告より優先権を別に見て取る、警告する、そして、エージェントに警告します。
Systems that generate multiple Warning headers should order them with this user agent behavior in mind.
複数のWarningヘッダーを生成するシステムは念頭でこのユーザエージェントの振舞いで彼らを注文するはずです。
This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning.
これが現在定義にされるののリストである、警告する、aがお勧めであることでのそれぞれ、警告する、英語、および意味の記述で。
10 Response is stale MUST be included whenever the returned response is stale. A cache may add this warning to any response, but may never remove it until the response is known to be fresh.
10応答は聞き古したです。返された応答が聞き古したときはいつも、含めなければならなくなってください。 キャッシュは、どんな応答にもこの警告を加えますが、応答が新鮮であることが知られるまで、それを決して取り除かないかもしれません。
11 Revalidation failed MUST be included if a cache returns a stale response because an attempt to revalidate the response failed, due to an inability to reach the server. A cache may add this warning to any response, but may never remove it until the response is successfully revalidated.
応答が無能のため失敗したrevalidateへの試みがサーバに達するのでキャッシュが聞き古した応答を返すなら、失敗されたRevalidationを含まなければなりません。11 キャッシュは、どんな応答にもこの警告を加えますが、応答が首尾よく再有効にされるまで、それを決して取り除かないかもしれません。
12 Disconnected operation SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
キャッシュしばらく故意にネットワークの残りから切断されるなら含まれていて、12は、操作がSHOULDであると切断しました。
13 Heuristic expiration MUST be included if the cache heuristically chose a freshness lifetime greater than 24 hours and the response's age is greater than 24 hours.
13 キャッシュが新しさ24時間以上生涯を発見的に選んで、応答の時代が24時間以上であるなら発見的な満了を含まなければなりません。
Fielding, et. al. Standards Track [Page 138] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[138ページ]RFC2068HTTP/1997年1月1.1日
14 Transformation applied MUST be added by an intermediate cache or proxy if it applies any transformation changing the content-coding (as specified in the Content-Encoding header) or media-type (as specified in the Content-Type header) of the response, unless this Warning code already appears in the response. MUST NOT be deleted from a response even after revalidation.
何か応答の内容をコード化しているか(Contentをコード化しているヘッダーで指定されるように)、メディアタイプ(コンテントタイプヘッダーで指定されるように)を変える変換を適用するなら、中間的キャッシュかプロキシが適用された14変換を加えなければなりません、このWarningコードが応答に既に現れない場合。 再合法化の後の応答からさえ削除されてはいけません。
99 Miscellaneous warning The warning text may include arbitrary information to be presented to a human user, or logged. A system receiving this warning MUST NOT take any automated action.
99 テキストが人間のユーザに提示されるか、または登録されるために任意の情報を含むかもしれないと警告に警告するその他。 この警告を受け取るシステムは少しの自動化された行動も取ってはいけません。
14.46 WWW-Authenticate
14.46はWWW認証します。
The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
応答ヘッダ分野をWWW認証してください、401の(権限のない)の応答メッセージに含まなければなりません。 分野値はRequest-URIに適切な認証体系とパラメタについて簡単に述べる少なくとも1つの挑戦から成ります。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
「WWW認証、=が「WWW認証する」、」、:、」 1#挑戦
The HTTP access authentication process is described in section 11. User agents MUST take special care in parsing the WWW-Authenticate field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
HTTPアクセス認証過程はセクション11で説明されます。 1つ以上の挑戦を含んでいるか、またはより多くの人がヘッダーをWWW認証するなら挑戦のコンテンツが供給するのでそれ自体で野原を供給するなら、分野値をWWW認証してください。ユーザエージェントが構文解析で特別に注意を払わなければならない、認証パラメタのコンマで切り離されたリストを含んでください。
15 Security Considerations
15 セキュリティ問題
This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
このセクションはこのドキュメントによって説明されるようにHTTP/1.1におけるセキュリティ制限についてアプリケーション開発者、情報提供者、およびユーザに知らせることになっています。 議論はセキュリティ危険を減少させるためのいくつかの提案をしますが、明らかにされた問題に決定的なソリューションを含んでいません。
15.1 Authentication of Clients
15.1 クライアントの認証
The Basic authentication scheme is not a secure method of user authentication, nor does it in any way protect the entity, which is transmitted in clear text across the physical network used as the carrier. HTTP does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security or the addition of enhancements (such as schemes to use one-time passwords) to Basic authentication.
Basic認証体系はユーザー認証の安全なメソッドではありません、そして、それは何らかの方法で実体を保護しません。(それは、物理ネットワークの向こう側にキャリヤーとして使用されるクリアテキストで伝えられます)。 HTTPは増進(ワンタイムパスワードを使用する体系などの)のセキュリティか追加を増強するのに使われるのからBasic認証まで追加認証体系と暗号化メカニズムを防ぎません。
Fielding, et. al. Standards Track [Page 139] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[139ページ]RFC2068HTTP/1997年1月1.1日
The most serious flaw in Basic authentication is that it results in the essentially clear text transmission of the user's password over the physical network. It is this problem which Digest Authentication attempts to address.
Basic認証における最も多くの重大な欠陥は物理ネットワークの上でユーザのパスワードの本質的には明確なテキスト伝送をもたらすということです。 それは訴えるDigest Authenticationが、試みるこのその問題です。
Because Basic authentication involves the clear text transmission of passwords it SHOULD never be used (without enhancements) to protect sensitive or valuable information.
Basic認証がパスワードのクリアテキスト伝達にかかわる、それ、SHOULD、敏感であるか貴重な情報を保護するのに決して使用されないでください(増進なしで)。
A common use of Basic authentication is for identification purposes -- requiring the user to provide a user name and password as a means of identification, for example, for purposes of gathering accurate usage statistics on a server. When used in this way it is tempting to think that there is no danger in its use if illicit access to the protected documents is not a major concern. This is only correct if the server issues both user name and password to the users and in particular does not allow the user to choose his or her own password. The danger arises because naive users frequently reuse a single password to avoid the task of maintaining multiple passwords.
例えば、ユーザが識別の手段として正確な用法統計をサーバに集める目的にユーザ名とパスワードを提供するのが必要であることで、Basic認証の一般の使用は識別目的のためのものです。このように使用されると、それは使用中である危険が全く保護されたドキュメントへの不法なアクセスが主要な関心事でないならないと思うのに誘惑しています。 サーバが、ユーザ名とパスワードの両方をユーザに発行して、ユーザがその人の自己のパスワードを選ぶのを特に許容しない場合にだけ、これは正しいです。 ナイーブなユーザが複数のパスワードを維持するタスクを避けるために頻繁にただ一つのパスワードを再利用するので、危険は起こります。
If a server permits users to select their own passwords, then the threat is not only illicit access to documents on the server but also illicit access to the accounts of all users who have chosen to use their account password. If users are allowed to choose their own password that also means the server must maintain files containing the (presumably encrypted) passwords. Many of these may be the account passwords of users perhaps at distant sites. The owner or administrator of such a system could conceivably incur liability if this information is not maintained in a secure fashion.
サーバが、ユーザがそれら自身のパスワードを選択することを許可するなら、脅威はサーバのドキュメントへの不法なアクセスだけではなく、彼らのアカウントパスワードを使用するのを選んだすべてのユーザのアカウントへの不法なアクセスでもあります。 ユーザが選ぶことができるなら、また、サーバを意味するそれら自身のパスワードは(おそらく、暗号化されています)のパスワードを含むファイルを保守しなければなりません。 これらの多くが恐らく遠位部位のユーザのアカウントパスワードであるかもしれません。 この情報が安全なファッションで保守されないなら、そのようなシステムの所有者か管理者が多分責任を被るかもしれません。
Basic Authentication is also vulnerable to spoofing by counterfeit servers. If a user can be led to believe that he is connecting to a host containing information protected by basic authentication when in fact he is connecting to a hostile server or gateway then the attacker can request a password, store it for later use, and feign an error. This type of attack is not possible with Digest Authentication [32]. Server implementers SHOULD guard against the possibility of this sort of counterfeiting by gateways or CGI scripts. In particular it is very dangerous for a server to simply turn over a connection to a gateway since that gateway can then use the persistent connection mechanism to engage in multiple transactions with the client while impersonating the original server in a way that is not detectable by the client.
また、基本的なAuthenticationもにせのサーバでだますのに被害を受け易いです。 ユーザが、彼が事実上、彼が敵対的なサーバかゲートウェイに接続しているとき基本認証によって保護された情報を含むホストに接していると信じているように導くことができるなら、攻撃者は、パスワードを要求して、後の使用のためにそれを保存して、誤りのふりをすることができます。 このタイプの攻撃はDigest Authentication[32]で可能ではありません。 サーバimplementers SHOULDはゲートウェイかCGIスクリプトによるこの種類の偽物の可能性に用心します。 特に、次に、そのゲートウェイがクライアントが検出可能でない方法でオリジナルのサーバをまねている間、多数の取引にクライアントと共に従事するのにパーシステントコネクションメカニズムを使用できるので、サーバが単に接続をゲートウェイに引き渡すのは、非常に危険です。
15.2 Offering a Choice of Authentication Schemes
15.2 認証体系について好きなのを選んでよいということ。
An HTTP/1.1 server may return multiple challenges with a 401 (Authenticate) response, and each challenge may use a different
HTTP/1.1サーバが401(認証する)応答と共に複数の挑戦を返すかもしれなくて、各挑戦がaを使用するかもしれない、相違
Fielding, et. al. Standards Track [Page 140] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[140ページ]RFC2068HTTP/1997年1月1.1日
scheme. The order of the challenges returned to the user agent is in the order that the server would prefer they be chosen. The server should order its challenges with the "most secure" authentication scheme first. A user agent should choose as the challenge to be made to the user the first one that the user agent understands.
計画してください。 ユーザエージェントに返された挑戦の注文がサーバが好むオーダーにある、それら、選ばれてください。 サーバは最初に、「最も安全な」認証体系で挑戦を命令するべきです。 ユーザエージェントは、挑戦としてユーザに作られているのを選ぶべきです。ユーザエージェントが理解している最初のもの。
When the server offers choices of authentication schemes using the WWW-Authenticate header, the "security" of the authentication is only as malicious user could capture the set of challenges and try to authenticate him/herself using the weakest of the authentication schemes. Thus, the ordering serves more to protect the user's credentials than the server's information.
サーバがいつ認証の選択を提供するかが使用を計画する、ヘッダーをWWW認証してください、単に、悪意あるユーザーが最も弱い認証体系を使用することで挑戦のセットを得て、自己を認証しようとすることができたように認証の「セキュリティ」があります。 したがって、注文はユーザのものを保護するためにはサーバの情報より多くの資格証明書に役立ちます。
A possible man-in-the-middle (MITM) attack would be to add a weak authentication scheme to the set of choices, hoping that the client will use one that exposes the user's credentials (e.g. password). For this reason, the client should always use the strongest scheme that it understands from the choices accepted.
中央の可能な男性(MITM)攻撃は弱い認証体系を選択のセットに追加するだろうことです、クライアントがユーザの資格証明書が(例えば、パスワード)であると暴露するものを使用することを望んでいて。 この理由のために、クライアントはいつも受け入れられた選択から理解している中で最も強い体系を使用するべきです。
An even better MITM attack would be to remove all offered choices, and to insert a challenge that requests Basic authentication. For this reason, user agents that are concerned about this kind of attack could remember the strongest authentication scheme ever requested by a server and produce a warning message that requires user confirmation before using a weaker one. A particularly insidious way to mount such a MITM attack would be to offer a "free" proxy caching service to gullible users.
さらに良いMITM攻撃は、すべての提供された選択を取り除いて、Basic認証を要求する挑戦を挿入するだろうことです。 この理由で、この種類の攻撃に関して心配しているユーザエージェントは、今までサーバによって要求された中で最も強い認証体系を覚えていて、より弱いものを使用する前にユーザ確認を必要とする警告メッセージを生産できました。 そのようなMITM攻撃を仕掛ける特に油断のならない方法はだまされやすいユーザに対するサービスをキャッシュする「自由な」プロキシを提供するだろうことです。
15.3 Abuse of Server Log Information
15.3 サーバログ情報の乱用
A server is in the position to save personal data about a user's requests which may identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling may be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
サーバがそれらの興味深い読書パターンか対象を特定するかもしれないユーザの要求に関する個人的なデータを保存する立場にあります。 この情報は明確に現実に秘密です、そして、取り扱いはある一定の国で法で抑制されるかもしれません。 そのような材料がどんな発行された結果で身元保証可能な個人の許可なしでも分配されないのを確実にするのにデータを提供するのにHTTPプロトコルを使用している人々は責任があります。
15.4 Transfer of Sensitive Information
15.4 機密情報の転送
Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications SHOULD supply as much control over this information as possible to the provider of that information. Four header fields are worth special mention in this context: Server, Via, Referer and From.
どんなジェネリックデータ転送プロトコルのようにも、HTTPはわたっているデータの内容を規制できません、そして、どんな与えられた要求の文脈の中でもどんな特定の情報の感度も決定する少しの先験的なメソッドもありません。 したがって、アプリケーションSHOULDはこの情報のその情報のプロバイダーにできるだけ多くのコントロールを供給します。 4つのヘッダーフィールドが特記のこのような関係においては価値があります: そしてを通してサーバ、Referer。
Fielding, et. al. Standards Track [Page 141] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[141ページ]RFC2068HTTP/1997年1月1.1日
Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option.
サーバの特定のソフトウェアバージョンを明らかにすることによって、サーバマシンはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 Implementers SHOULDはServerヘッダーフィールドを構成可能なオプションにします。
Proxies which serve as a portal through a network firewall SHOULD take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, they SHOULD remove, or replace with sanitized versions, any Via fields generated behind the firewall.
ネットワークファイアウォールSHOULDを通した入り口としてのそれのサーブがファイアウォールの後ろでホストを特定するヘッダー情報の転送に関して特別な注意を払うプロキシ。 特にそれら、SHOULDはファイアウォールの後ろで生成されたどんなVia野原も、殺菌されたバージョンに移すか、または取り替えます。
The Referer field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer field may indicate a private document's URI whose publication would be inappropriate.
Referer分野で、読書パターンは、研究されて、描かれたリンクを逆にします。 それは非常に役に立つ場合がありますが、ユーザの詳細がRefererに含まれた情報と切り離されないなら、パワーを乱用できます。 個人情報を取り除くときさえ、Referer分野は公表が不適当である個人的なドキュメントのURIを示すかもしれません。
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it SHOULD NOT be transmitted without the user being able to disable, enable, and modify the contents of the field. The user MUST be able to set the contents of this field within a user preference or application defaults configuration.
情報はFrom分野はユーザのプライバシー利益のためかそれらのサイトの安全保障政策と衝突して、したがって、それと衝突するかもしれないのを送りました。SHOULD NOTが無効にするできるユーザなしで伝えられて、分野のコンテンツを可能にして、変更してください。 ユーザはユーザー選択の中にこの分野のコンテンツを設定できるか、アプリケーションデフォルトが構成であったならそうしなければなりません。
We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
もっとも、私たちが、するように提案する、必要でない、ユーザがFromとReferer情報の発信を可能にするか、または無効にするように、便利なトグルインタフェースを提供します。
15.5 Attacks Based On File and Path Names
15.5の攻撃がファイルとパス名を基礎づけました。
Implementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. If an HTTP server translates HTTP URIs directly into file system calls, the server MUST take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) MUST be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor bugs in such HTTP server implementations have turned into security risks.
実装、HTTP発生源サーバSHOULDでは、サーバアドミニストレータによって意図されたものだけであるというHTTP要求で返された書類を制限するように注意してください。 HTTPサーバが直接ファイルシステムコールにHTTP URIを翻訳するなら、サーバは、HTTPクライアントに提供されることを意図しなかったファイルに役立たないように特別に注意を払わなければなりません。 「例えば、UNIX、マイクロソフトWindows、および他のオペレーティングシステムが使用する、」 . . 」 現在のものより上でaディレクトリレベルを示す経路コンポーネントとして。 そのようなシステムの上では、別の方法でHTTPサーバでアクセスしやすいことを意図するものの外のリソースへのアクセスを許すなら、HTTPサーバはRequest-URIでどんなそのような構造物も禁じなければなりません。同様に、不適当な検索から参照のために内部的にだけサーバ(アクセス制御ファイルや、構成ファイルや、スクリプトコードなどの)に意図するファイルを保護しなければなりません、機密情報を含むかもしれないので。 経験は、そのようなHTTPサーバ実装における小さい方のバグがセキュリティリスクに変わったのを示しました。
Fielding, et. al. Standards Track [Page 142] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[142ページ]RFC2068HTTP/1997年1月1.1日
15.6 Personal Information
15.6 個人情報
HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementers be particularly careful in this area. History shows that errors in this area are often both serious security and/or privacy problems, and often generate highly adverse publicity for the implementer's company.
HTTPクライアントはしばしば多量の個人情報(例えば、ユーザの名前、位置、郵便の宛先、パスワード、暗号化キーなど)、およびSHOULDに関与しています。他のソースへのHTTPプロトコルでこの情報の意図的でない漏出を防ぐように非常に注意してください。 私たちはユーザがそのような情報の普及を制御するように便利なインタフェースを提供して、デザイナーとimplementersにこの領域で特に注意していることを非常に強く勧めます。 歴史は、この領域の誤りがしばしば重大なセキュリティ、そして/または、プライバシー問題の両方であり、implementerの会社のためにしばしば非常に不利な宣伝を生成するのを示します。
15.7 Privacy Issues Connected to Accept Headers
15.7 ヘッダーを受け入れるために接続されたプライバシー問題
Accept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved.
ユーザの要求ヘッダー缶の啓示情報をすべてのアクセスされたサーバに受け入れてください。 特にAccept-言語ヘッダーはユーザが個人的な自然があると考える情報を明らかにすることができます、特定の言語の理解がしばしば強く特定のエスニック・グループの会員資格に関連するので。 あらゆる要求で送られるAccept-言語ヘッダーのコンテンツを構成するためにオプションを提供するユーザエージェントがコンフィギュレーションプロセスにプライバシーの損失を意識しているユーザがかかわるメッセージを含ませるよう強く奨励されます。
An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether it should start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service.
プライバシーの損失を制限するアプローチがユーザエージェントがデフォルトでAccept-言語ヘッダーの発信を省略するだろうことであり、それが、それが何かサーバによって生成されたVary応答ヘッダ分野を探すことによってそれを検出するならAccept-言語ヘッダーをサーバに送り始めるべきであるかどうかユーザに尋ねるために、そのような発信はサービスの質を改良するかもしれません。
Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents should be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability should warn users about the loss of privacy which can be involved.
ユーザによってカスタム設計されていた状態で、詳しく説明してください。あらゆる要求、これらは特に、上質の値を含んで、比較的信頼できるとしてサーバで使用できるか、そして、および長命のユーザ識別子で送られたヘッダーフィールドを受け入れてください。 そのようなユーザ識別子は、コンテンツプロバイダーがクリック道の追跡をするのを許容して、コンテンツプロバイダーについて共同すると、交差しているサーバクリック道が合わせられるか、または個々のユーザの差出が形成されるのを許容するでしょう。 また、プロキシの後ろの多くのユーザに関して、ユーザエージェントを車で送るホストのネットワーク・アドレスが長命のユーザ識別子として機能することに注意してください。 ユーザエージェントがプロキシがプライバシーを高めるのに使用されるところに、提供するのにおいて保守的であるべき環境で、ヘッダー設定オプションをエンドユーザに受け入れてください。 プロキシが、極端として、プライバシーが測定するのをフィルターにかけることができた、リレーされた要求でヘッダーを受け入れてください。 ヘッダーconfigurabilityの高度合いを提供する汎用のユーザエージェントは、どれがかかわることができるかをプライバシーの損失に関するユーザに警告するべきです。
Fielding, et. al. Standards Track [Page 143] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[143ページ]RFC2068HTTP/1997年1月1.1日
15.8 DNS Spoofing
15.8 DNSスプーフィング
Clients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association.
HTTPを使用しているクライアントは、大いにDomain Name Serviceを当てにして、その結果、一般に、IPアドレスとDNS名の慎重な誤協会に基づくセキュリティー攻撃に傾向があります。 クライアントは、IP数/DNS名前協会の継続する正当性を仮定するのにおいて用心深い必要があります。
In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. These lookups should be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful.
特に、HTTPクライアントSHOULDはIP数/DNS名前協会の確認のために前のホスト名ルックアップの結果をキャッシュするよりむしろ彼らのネーム・リゾルバに頼ります。 多くのプラットホーム、既に適切であるときにキャッシュホストが局所的にルックアップと命名する缶、およびそれら、SHOULD、そうするには、構成されてください。 しかしながら、キャッシュされた情報が役に立ったままで残っているのがネームサーバによって報告されたTTL(時間To Live)情報でありそうになる場合にだけ、これらのルックアップはキャッシュされるべきです。
If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS.
HTTPクライアントが性能改良を達成するためにホスト名ルックアップの結果をキャッシュするなら、それらはDNSによって報告されたTTL情報を観測しなければなりません。
If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common, the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
以前にアクセスされたサーバのIPアドレスが変化するとき、HTTPクライアントがこの規則を守らないなら、彼らは偽造されるかもしれません。 ネットワークの番号を付け替えるのがますます一般的になると予想されるとき、この形式の攻撃の可能性は成長するでしょう。 その結果、この要件を観測すると、この潜在的セキュリティの脆弱性は減少します。
This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy.
この要件は、また、模写されたサーバのために同じDNS名を使用することでクライアントの負荷分散の振舞いを改良して、その戦略を使用するサイトにアクセスする際にユーザが失敗を経験するという見込みを減少させます。
15.9 Location Headers and Spoofing
15.9 位置のヘッダーとスプーフィング
If a single server supports multiple organizations that do not trust one another, then it must check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority.
ただ一つのサーバがお互いを信じない複数の組織をサポートするなら、それはそれらが権威を全く持っていないリソースを無効にするのを試みないのを確実にするために前述の組織のコントロールの下で生成される応答における、LocationとContent位置のヘッダーの値をチェックしなければなりません。
16 Acknowledgments
16の承認
This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and Internet mail message formats.
この仕様で、デヴィッド・H.クロッカーはRFC822のために増大しているBNFとジェネリック構造物の重い使用を定義します。 同様に、それはナザニエルBorensteinとネッド・フリードによってMIMEに提供された定義の多くを再利用します。 この仕様での彼らの包含が、HTTPとインターネット・メールメッセージ・フォーマットとの関係の上で過去の混乱を抑えるのを助けることを願っています。
Fielding, et. al. Standards Track [Page 144] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[144ページ]RFC2068HTTP/1997年1月1.1日
The HTTP protocol has evolved considerably over the past four years. It has benefited from a large and active developer community--the many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining early aspects of the protocol.
HTTPプロトコルは過去4年間かなり発展しています。 それは大きくて活動的な開発者社会(www-話のメーリングリストに参加した多くの人々)の利益を得ました、そして、一般に、HTTPとWWWの成功に最も責任感が強いその共同体です。 マーク・アンドリーセン、ロバート・カイラウ、ダニエル・W.コノリー、ボブ・デニー、ジョン・フランクス、ジャン・フランソワ・グルフ、フィリップ・M.ハラム-ベイカー、Hakon W.Lie、アリLuotonen、ロブMcCool、ルウMontulli、デーヴRaggett、トニーSanders、およびマークVanHeyningenはプロトコルの早めの局面を定義する際に彼らの取り組みのための特別な認識に値します。
This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already mentioned, the following individuals have contributed to this specification:
このドキュメントは大いにHTTP-WGに参加するすべてのもののコメントの利益を得ました。 既に言及されたものに加えて、以下の個人はこの仕様に貢献しました:
Gary Adams Albert Lunde
Harald Tveit Alvestrand John C. Mallery
Keith Ball Jean-Philippe Martin-Flatin
Brian Behlendorf Larry Masinter
Paul Burchard Mitra
Maurizio Codogno David Morris
Mike Cowlishaw Gavin Nicol
Roman Czyborra Bill Perry
Michael A. Dolan Jeffrey Perry
David J. Fiander Scott Powers
Alan Freier Owen Rees
Marc Hedlund Luigi Rizzo
Greg Herlihy David Robinson
Koen Holtman Marc Salomon
Alex Hopmann Rich Salz
Bob Jernigan Allan M. Schiffman
Shel Kaphan Jim Seidman
Rohit Khare Chuck Shotton
John Klensin Eric W. Sink
Martijn Koster Simon E. Spero
Alexei Kosut Richard N. Taylor
David M. Kristol Robert S. Thau
Daniel LaLiberte Bill (BearHeart) Weinman
Ben Laurie Francois Yergeau
Paul J. Leach Mary Ellen Zurko
Daniel DuBois
コドーニョデヴィッド・モリスマイク・カウリショウ・ギャヴィン・ニコルRomanのゲーリー・アダムス・アルバート・ルンデ・ハラルド・Tveit Alvestrandジョン・C.Malleryキース・Ballジャンフィリップ・マーチン-Flatinブライアン・Behlendorfラリー・Masinterポール・Burchardミトラ・ジェフリー・ペリーデヴィッド・J.FianderマウリジオCzyborra Bill PerryマイケルA.ドランスコットはアラン・フライア・オーエン・レースマーク・ヘドランド・ルーイジ・リゾー・グレッグ・Herlihyデイビッド・ロビンソン・クン・Holtmanマーク・ソロモン・アレックス・Hopmannリッシュ・ザルツ・ボブ・JerniganアランMを動かします; シフマン・シェル・Kaphanジム・シードマン・Rohit Khareチャック・Shottonジョン・Klensinエリック・W.Sinkマーティン・コスター・サイモン・E.スペロウアレクセイ・Kosutリチャード・N.テイラー・デヴィッド・M.クリストル・ロバート・S.トー・ダニエル・LaLiberteビル(BearHeart)・ワインマン・ベン・ローリー・フランソア・Yergeauポール・J.リーチ・メアリ・エレン・Zurkoダニエル・デュボワ
Much of the content and presentation of the caching design is due to suggestions and comments from individuals including: Shel Kaphan, Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
個人からの提案とコメントのために、あって、:キャッシュの内容とプレゼンテーションには、非常に、デザインがあります。 シェルKaphan、ポール・リーチ、クンHoltman、デヴィッドモリス、およびラリーMasinter。
Fielding, et. al. Standards Track [Page 145] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[145ページ]RFC2068HTTP/1997年1月1.1日
Most of the specification of ranges is based on work originally done by Ari Luotonen and John Franks, with additional input from Steve Zilles.
範囲の仕様の大部分は元々アリLuotonenとジョン・フランクスによって行われた仕事に基づいています、スティーブZillesからの追加入力で。
Thanks to the "cave men" of Palo Alto. You know who you are.
パロアルトの「洞窟男性」をありがとうございます。 あなたは、だれであるかを知っています。
Jim Gettys (the current editor of this document) wishes particularly to thank Roy Fielding, the previous editor of this document, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Alex Hopmann, and Larry Masinter for their help.
ジムGettys(このドキュメントの現在のエディタ)は特にロイFielding、このドキュメントの前のエディタに感謝したがっています、彼らの助けのためのジョンKlensin、ジェフ・ムガール人、ポール・リーチ、デーヴ・クリストル、クンHoltman、ジョン・フランクス、アレックスHopmann、およびラリーMasinterと共に。
17 References
17の参照箇所
[1] Alvestrand, H., "Tags for the identification of languages", RFC 1766, UNINETT, March 1995.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[1]、RFC1766、UNINETT、1995年3月。
[2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey, D., and B. Alberti. "The Internet Gopher Protocol: (a distributed document search and retrieval protocol)", RFC 1436, University of Minnesota, March 1993.
[2]Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、トーリー、D.、およびB.アルベルティ。 「インターネットゴーファープロトコル:」 (分配されたドキュメント検索と検索プロトコル)「RFC1436、ミネソタ大学、1993年3月」
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", RFC 1630, CERN, June 1994.
「[3] バーナーズ・リー、T.、「WWWの普遍的なリソース識別子」、WWWに使用されるNetworkの上のObjectsのNamesとAddressesのExpressionのためのA Unifying Syntax」、RFC1630、CERN(1994年6月)
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota, December 1994.
[4] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、CERN、ゼロックスPARC、ミネソタ大学、1994年12月。
[5] Berners-Lee, T., and D. Connolly, "HyperText Markup Language Specification - 2.0", RFC 1866, MIT/LCS, November 1995.
[5] バーナーズ・リー、T.、およびD.コノリー、「ハイパーテキストマークアップランゲージ仕様--2インチ、RFC1866、MIT/LCS、1995インチ年11月。
[6] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0.", RFC 1945 MIT/LCS, UC Irvine, May 1996.
[6]バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「ハイパーテキストはプロトコルを移します--HTTP/1.0」、RFC1945MIT/LCS、UCアーバイン5月1996番目
[7] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual, November 1996.
解放された[7]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は1つを分けます」。 「インターネットメッセージ本体の形式」、RFC2045、Innosoft、ファースト・バーチャル方式、1996年11月。
[8] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, IETF, October 1989.
[8] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とサポート」、STD3、RFC1123、IETF、10月1989日
[9] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.
[9] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
Fielding, et. al. Standards Track [Page 146] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[146ページ]RFC2068HTTP/1997年1月1.1日
[10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R., Sui, J., and M. Grinbaum. "WAIS Interface Protocol Prototype Functional Specification", (v1.5), Thinking Machines Corporation, April 1990.
[10]デイヴィス、F.、カーレ、B.、モリス、H.、礼拝堂、J.、シン、T.、ワング、R.、スイ、J.、およびM.Grinbaum。 「WAISのインタフェースのプロトコルのプロトタイプの機能的な仕様」、(v1.5)、考えは社、1990年4月を機械加工します。
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, UC Irvine, June 1995.
[11]フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、UCアーバイン1995年6月。
[12] Horton, M., and R. Adams. "Standard for interchange of USENET messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic Studies, December 1987.
[12] Seismic研究(1987年12月)のためのホートン、M.、およびR.アダムス「USENETメッセージの置き換えの規格」、RFC1036、AT&Tベル研究所、センター。
[13] Kantor, B., and P. Lapsley. "Network News Transfer Protocol." A Proposed Standard for the Stream-Based Transmission of News", RFC 977, UC San Diego, UC Berkeley, February 1986.
[13] カンター、B.、およびP.ラプスリー。 「ネットニュースはプロトコルを移します。」 RFC977、UCサンディエゴ、UCバークレー1986年2月の「ニュースのストリームベースの伝達の提案された標準。」
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, University of Tennessee, November 1996.
[14] ムーア、K.、「パートThreeをまねてください(マルチパーパスインターネットメールエクステンション)」 「非ASCIIテキストのためのメッセージヘッダー拡張子」、RFC2047、テネシー大学、1996年11月。
[15] Nebel, E., and L. Masinter. "Form-based File Upload in HTML", RFC 1867, Xerox Corporation, November 1995.
[15]Nebel、E.、およびL.Masinter。 「HTMLにおけるフォームベースのファイルアップロード」、RFC1867、ゼロックス社、1995年11月。
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/ISI, August 1982.
[16] ポステル、J.、「簡単なメール転送プロトコル」、STD10、RFC821、USC/ISI、1982年8月。
[17] Postel, J., "Media Type Registration Procedure", RFC 2048, USC/ISI, November 1996.
[17] ポステル、J.、「メディアは登録手順をタイプする」RFC2048、USC/ISI、1996年11月。
[18] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, USC/ISI, October 1985.
[18] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、USC/ISI、1985年10月。
[19] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, USC/ISI, October 1994.
[19] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、USC/ISI、1994年10月。
[20] Sollins, K., and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation, December 1994.
[20] Sollins、K.とL.Masinter、「一定のリソース名のための機能条件書」RFC1737、MIT/LCS、ゼロックス社、1994年12月。
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[21] 米国-ASCII。 コード化文字集合--7ビットの情報交換用米国標準コード。 標準のANSI X3.4-1986、ANSI、1986。
[22] ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
[22] ISO-8859。 世界規格--情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859-1:1987。 第2部: ローマ字No.2、ISO8859-2、1987。 パート3: ローマ字No.3、ISO8859-3、1988。 パート4: ローマ字No.4、ISO8859-4、1988。
Fielding, et. al. Standards Track [Page 147] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[147ページ]RFC2068HTTP/1997年1月1.1日
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
パート5: ラテン/キリル文字、ISO8859-5、1988。 パート6: ラテン/アラビア文字、ISO8859-6、1987。 パート7: ラテン/ギリシャ語アルファベット、ISO8859-7、1987。 パート8: ラテン語の、または、ヘブライのアルファベット、ISO8859-8、1988。 パート9: ローマ字No.5、ISO8859-9、1990。
[23] Meyers, J., and M. Rose "The Content-MD5 Header Field", RFC 1864, Carnegie Mellon, Dover Beach Consulting, October, 1995.
[23] メイヤーズ、J.、およびM.ローズ「内容-MD5ヘッダーフィールド」、RFC1864、カーネギー・メロン、ドーヴァーは1995年10月にコンサルティングを浜に引き上げます。
[24] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC 1900, IAB, February 1996.
[24] 大工、B.とY.Rekhter、「番号を付け替えるのは仕事を必要とである」RFC1900、IAB、1996年2月。
[25] Deutsch, P., "GZIP file format specification version 4.3." RFC 1952, Aladdin Enterprises, May 1996.
[25] ドイツ語、P.、「GZIPファイル形式仕様バージョン4.3。」 RFC1952(アラジンエンタープライズ)は1996がそうするかもしれません。
[26] Venkata N. Padmanabhan and Jeffrey C. Mogul. Improving HTTP Latency. Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conf. '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ HTTPLatency.html.
[26] Venkata N.Padmanabhanとジェフリー・C.ムガール人。 HTTP潜在を改良します。 コンピュータNetworksとISDN Systems、v。 28、ページ 25-35と、1995年12月。 Procの紙のわずかに改訂されたバージョン。 第2国際WWW Conf。 '94: モザイクとウェブ、 http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/ HTTPLatency.htmlで利用可能な1994年10月。
[27] Joe Touch, John Heidemann, and Katia Obraczka, "Analysis of HTTP Performance", <URL: http://www.isi.edu/lsam/ib/http-perf/>, USC/Information Sciences Institute, June 1996
[27] ジョーTouch、ジョンHeidemannとカチアObraczka、「HTTPパフォーマンスの分析」<URL: http://www.isi.edu/lsam/ib/http-perf/ >、科学が1996年6月に設けるUSC/情報
[28] Mills, D., "Network Time Protocol, Version 3, Specification, Implementation and Analysis", RFC 1305, University of Delaware, March 1992.
[28] 工場と、D.と、「ネットワーク時間プロトコル、バージョン3、仕様、実装、および分析」(RFC1305、デラウエア大学)は1992を行進させます。
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3." RFC 1951, Aladdin Enterprises, May 1996.
[29] ドイツ語、P.、「DEFLATE Compressed Data Format Specificationバージョン1.3。」 RFC1951(アラジンエンタープライズ)は1996がそうするかもしれません。
[30] Spero, S., "Analysis of HTTP Performance Problems" <URL:http://sunsite.unc.edu/mdma-release/http-prob.html>.
[30] 「HTTPパフォーマンス問題の分析」<URL: スペロウ、S.、 http://sunsite.unc.edu/mdma-release/http-prob.html >。
[31] Deutsch, P., and J-L. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, Aladdin Enterprises, Info-ZIP, May 1996.
[31] ドイツ語、P.、およびJ-L。 ゲイル、「ZLIB Compressed Data Format Specification、バージョン3.3インチ、RFC1950、アラジンエンタープライズ、Info-ZIP、1996インチ年5月。
[32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and L. Stewart, "An Extension to HTTP : Digest Access Authentication", RFC 2069, January 1997.
[32] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、リーチ、P.、Luotonen、A.、流し台、E.、およびL.スチュワート、「HTTPへの拡大:」 「ダイジェストアクセス認証」、RFC2069、1997年1月。
Fielding, et. al. Standards Track [Page 148] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[148ページ]RFC2068HTTP/1997年1月1.1日
18 Authors' Addresses
18人の作者のアドレス
Roy T. Fielding Department of Information and Computer Science University of California Irvine, CA 92717-3425, USA
情報の部をさばいているロイT.とカリフォルニア大学アーバイン、コンピュータサイエンスカリフォルニア92717-3425(米国)
Fax: +1 (714) 824-4056 EMail: fielding@ics.uci.edu
Fax: +1 (714) 824-4056 メールしてください: fielding@ics.uci.edu
Jim Gettys MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
正方形のケンブリッジ、ジムGettys MIT Laboratory for Computer Science545Technology MA 02139、米国
Fax: +1 (617) 258 8682 EMail: jg@w3.org
Fax: +1(617) 258 8682はメールされます: jg@w3.org
Jeffrey C. Mogul Western Research Laboratory Digital Equipment Corporation 250 University Avenue Palo Alto, California, 94305, USA
Avenueパロアルト、ジェフリー・C.の要人の西洋の研究所DEC250大学カリフォルニア 94305、米国
EMail: mogul@wrl.dec.com
メール: mogul@wrl.dec.com
Henrik Frystyk Nielsen W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
正方形のケンブリッジ、Henrik FrystykニールセンWWW協会MIT Laboratory for Computer Science545Technology MA 02139、米国
Fax: +1 (617) 258 8682 EMail: frystyk@w3.org
Fax: +1(617) 258 8682はメールされます: frystyk@w3.org
Tim Berners-Lee Director, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
正方形のケンブリッジ、MA 02139、WWW協会MITコンピュータサイエンス研究所545Technology米国のティム・バーナーズ・リー指導官
Fax: +1 (617) 258 8682 EMail: timbl@w3.org
Fax: +1(617) 258 8682はメールされます: timbl@w3.org
Fielding, et. al. Standards Track [Page 149] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[149ページ]RFC2068HTTP/1997年1月1.1日
19 Appendices
19個の付録
19.1 Internet Media Type message/http
19.1 インターネットメディアTypeメッセージ/http
In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http". The following is to be registered with IANA.
HTTP/1.1プロトコルを定義することに加えて、このドキュメントはインターネットメディアのためのタイプ「メッセージ/http」という仕様として機能します。 以下はIANAに登録されることになっています。
Media Type name: message
Media subtype name: http
Required parameters: none
Optional parameters: version, msgtype
メディアTypeは以下を命名します。 メッセージメディア「副-タイプ」名: http Requiredパラメタ: なにも、Optionalパラメタ: バージョン、msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.1"). If not present, the version can be
determined from the first line of the body.
バージョン: 同封のメッセージのHTTPバージョン番号、(例えば、「1.1インチ)」 プレゼントでないなら、バージョンはボディーの最初の系列から決定できます。
msgtype: The message type -- "request" or "response". If not
present, the type can be determined from the first
line of the body.
msgtype: 「要求」かタイプ--「応答」というメッセージ。 プレゼントでないなら、タイプはボディーの最初の系列から決定できます。
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
問題をコード化します: 「7ビット」、「8ビット」、または「バイナリー」だけ、が受入れられます。
Security considerations: none
セキュリティ問題: なし
19.2 Internet Media Type multipart/byteranges
19.2 インターネットのメディアのTypeの複合/byteranges
When an HTTP message includes the content of multiple ranges (for example, a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart MIME message. The multipart media type for this purpose is called "multipart/byteranges".
HTTPメッセージが複数の範囲の内容を含んでいるとき(例えば、複数の非の重なるのを求める要求への応答は及びます)、これらは複合MIMEメッセージとして伝えられます。 複合メディアタイプはこのために「複合/byteranges」と呼ばれます。
The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields. The parts are separated using a MIME boundary parameter.
複合/byterangesメディアタイプはそれぞれそれ自身のコンテントタイプとContent-範囲分野がある2つ以上の部品を入れます。 部品は、MIME境界パラメタを使用することで切り離されます。
Media Type name: multipart
Media subtype name: byteranges
Required parameters: boundary
Optional parameters: none
メディアTypeは以下を命名します。 複合メディア「副-タイプ」は以下を命名します。 byteranges Requiredパラメタ: 境界Optionalパラメタ: なし
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
問題をコード化します: 「7ビット」、「8ビット」、または「バイナリー」だけ、が受入れられます。
Security considerations: none
セキュリティ問題: なし
Fielding, et. al. Standards Track [Page 150] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[150ページ]RFC2068HTTP/1997年1月1.1日
For example:
例えば:
HTTP/1.1 206 Partial content Date: Wed, 15 Nov 1995 06:25:24 GMT Last-modified: Wed, 15 Nov 1995 04:58:08 GMT Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
HTTP/1.1 206Partial内容日付: グリニッジ標準時1995年11月15日水曜日6時25分24秒の最終更新日: グリニッジ標準時1995年11月15日水曜日4時58分8秒の文書内容: 複合/byteranges。 この_境界=ストリング_は分離します。
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
--この_ストリング_は文書内容を切り離します: pdf Contentアプリケーション/範囲: バイト500-999/8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
...最初の範囲… --この_ストリング_は文書内容を切り離します: pdf Contentアプリケーション/範囲: バイト7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
...第2範囲--THIS_STRING_SEPARATES--
19.3 Tolerant Applications
19.3 許容性があるアプリケーション
Although this document specifies the requirements for the generation of 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/1.1のメッセージの世代単位で要件を指定しますが、すべてのアプリケーションがどんなそれらの実装で正しくなるというわけではないでしょう。 したがって、私たちは、明白にそれらの逸脱を解釈できるときはいつも、操作上のアプリケーションは逸脱において許容性があることを勧めます。
Clients SHOULD be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they SHOULD accept any amount of SP or HT characters between fields, even though only a single SP is required.
クライアントSHOULD、Status-線とRequest-線を分析すると許容性があるサーバを分析する際に、許容性があってください。 特にそれら、SHOULDはどんな量のSPかHTキャラクタも分野の間に受け入れます、独身のSPだけが必要ですが。
The line terminator for 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.
メッセージヘッダーフィールドのための系列ターミネータは系列CRLFです。 しかしながら、私たちは、そのようなヘッダーを分析するとき、アプリケーションが独身のLFが系列ターミネータであると認めて、主なCRを無視することを勧めます。
The character set of an entity-body should be labeled as the lowest common denominator of the character codes used within that body, with the exception that no label is preferred over the labels US-ASCII or ISO-8859-1.
実体本体の文字集合がそのボディーの中で使用されたキャラクタコードの最小公分母としてラベルされるべきであり、例外で、そのラベルなしはラベルの米国-ASCIIかISO-8859-1より好まれます。
Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:
日付の構文解析とコード化に関する要件のための付則と日付encodingsの他の潜在的な問題は:
o HTTP/1.1 clients and caches 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 HTTP/1.1のクライアントとキャッシュが、将来50年以上であるように見えるRFC-850日付が事実上、過去にあると仮定するべきです(これは、「2000年」問題を解決するのを助けます)。
Fielding, et. al. Standards Track [Page 151] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[151ページ]RFC2068HTTP/1997年1月1.1日
o An HTTP/1.1 implementation 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 HTTP/1.1実装は、固有値より早いとして内部的に分析されたExpires期日を表すかもしれませんが、固有値より遅いとして内部的に分析されたExpires期日は表してはいけません。
o All expiration-related calculations must be done in GMT. The
local time zone MUST NOT influence the calculation or comparison
of an age or expiration time.
o すべての満了関連の計算は. グリニッジ標準時現地時間にして、ゾーンが時代か満了時間の計算か比較に影響を及ぼしてはいけないということであるに違いありません。
o If an HTTP header incorrectly carries a date value with a time
zone other than GMT, it must be converted into GMT using the most
conservative possible conversion.
o HTTPヘッダがグリニッジ標準時を除いた時間帯で不当に日付の値を運ぶなら、可能な限り保守的な変換を使用することでそれをグリニッジ標準時に変換しなければなりません。
19.4 Differences Between HTTP Entities and MIME Entities
19.4 HTTP実体とMIME実体の違い
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822) and the Multipurpose Internet Mail Extensions (MIME ) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, MIME [7] discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
HTTP/1.1はインターネットメール(RFC822)とマルチパーパスインターネットメールエクステンション(MIME)で実体が開いているバラエティーの表現と広げることができるメカニズムで伝わるように定義された構造物の多くを使用します。しかしながら、MIME[7]はメールについて議論します、そして、HTTPには、いくつかのMIMEで説明されたものと異なった特徴があります。 これらの違いは2進の接続の上の性能を最適化するために慎重に選ばれて、ニューメディアの使用における、よりすばらしい自由を許容するのは、日付の比較をより簡単にして、何人かの早めのHTTPサーバとクライアントの習慣を承認するためにタイプされます。
This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to strict MIME environments SHOULD be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments to HTTP also need to be aware of the differences because some conversions may be required.
この付録はHTTPがMIMEと異なっている特定の領域について説明します。 プロキシと厳しいMIME環境SHOULDへのゲートウェイは、これらの違いを知って、適切な変換を必要であるところに提供します。 また、プロキシとMIME環境からHTTPへのゲートウェイは、いくつかの変換が必要であるかもしれないので違いを知る必要があります。
19.4.1 Conversion to Canonical Form
19.4.1 標準形への変換
MIME requires that an Internet mail entity be converted to canonical form prior to being transferred. Section 3.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. MIME requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP.
MIMEは、インターネット・メール実体が移す前に標準形に変換されるのを必要とします。 この.1通のセクション3.7ドキュメントがHTTPの上に伝えられると「テキスト」メディアタイプの血液型亜型のために許容されたフォームについて説明します。 MIMEは、一種の「テキスト」がある内容がCRLFとしてラインブレイクを表すのが必要であり、ラインブレイク系列の外でCRかLFの使用を禁じます。 メッセージがHTTPの上に送られるとき、HTTPで、CRLF、むき出しのCR、およびむき出しのLFはテキスト内容の中にラインブレイクを示すことができます。
Where it is possible, a proxy or gateway from HTTP to a strict MIME environment SHOULD translate all line breaks within the text media types described in section 3.7.1 of this document to the MIME canonical form of CRLF. Note, however, that this may be complicated by the presence of a Content-Encoding and by the fact that HTTP
それがHTTPから厳しいMIME環境への可能であって、プロキシかゲートウェイであるところでは、SHOULDはこの.1通のセクション3.7ドキュメントでCRLFのMIME標準形に説明されたテキストメディアタイプの中ですべてのラインブレイクを翻訳します。 しかしながら、これがContent-コード化の存在と事実によるそのHTTPによって複雑にされるかもしれないことに注意してください。
Fielding, et. al. Standards Track [Page 152] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[152ページ]RFC2068HTTP/1997年1月1.1日
allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF, as is the case for some multi-byte character sets.
いくつかの多バイト文字セットのためにそうであるように八重奏13と10を使用しないいくつかの文字集合の使用がCRとLFを表すのを許容します。
19.4.2 Conversion of Date Formats
19.4.2 日付の形式の変換
HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to simplify the process of date comparison. Proxies and gateways from other protocols SHOULD ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
HTTP/1.1は、日付の比較のプロセスを簡素化するのに、制限されたセットの日付の形式(セクション3.3.1)を使用します。 他のプロトコルSHOULDからのプロキシとゲートウェイは、メッセージの現在のどんなDateヘッダーフィールドもHTTP/1.1の形式の1つに従うのを保証して、必要なら、日付を書き直します。
19.4.3 Introduction of Content-Encoding
19.4.3 内容をコード化していることの導入
MIME does not include any concept equivalent to HTTP/1.1's Content- Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols MUST either change the value of the Content-Type header field or decode the entity-body before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform an equivalent function as Content-Encoding. However, this parameter is not part of MIME.)
MIMEは、ヘッダーフィールドをコード化しながら、HTTP/1.1Contentに同等などんな概念も含んでいません。 以来、HTTPからMIME対応することのプロトコルへのメディアタイプ、プロキシ、およびゲートウェイの上の修飾語がコンテントタイプヘッダーフィールドの値を変えなければならないか、またはメッセージを転送する前に実体本体を解読しなければならないとき、これは行動します。 (「メールがメディア型引数を使用したインターネットへのコンテントタイプのいくつかの実験用アプリケーション」 ; コード化を満足させている変換=<>、」 Contentをコード化しているとして同等な機能を実行するために。 しかしながら、このパラメタはMIMEの一部ではありません。)
19.4.4 No Content-Transfer-Encoding
19.4.4 満足している転送コード化しないこと
HTTP does not use the Content-Transfer-Encoding (CTE) field of MIME.
Proxies and gateways from MIME-compliant protocols to HTTP MUST
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client.
HTTPはMIMEのContent転送コード化(CTE)分野を使用しません。 プロキシとMIME対応することのプロトコルからHTTPへのゲートウェイがどんな非のアイデンティティCTEも取り外さなければならない、(「引用されて印刷可能である」か「base64") HTTPクライアントに応答メッセージを提供する前のコード化」。
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway SHOULD label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
プロキシとHTTPからMIME対応することのプロトコルへのゲートウェイはそのプロトコルで安全輸送のための正しい形式にはメッセージがあるのを確実にして、コード化に原因となります。そこでは、「安全輸送」が使用されるプロトコルの制限で定義されます。 そうするならSHOULDが適切なContent転送コード化でデータをラベルするそのようなプロキシかゲートウェイが目的地プロトコルの上の安全輸送の見込みを改良するでしょう。
19.4.5 HTTP Header Fields in Multipart Body-Parts
19.4.5 複合身体部分のHTTPヘッダ分野
In MIME, most header fields in multipart body-parts are generally ignored unless the field name begins with "Content-". In HTTP/1.1, multipart body-parts may contain any HTTP header fields which are significant to the meaning of that part.
MIMEでは、フィールド名が「内容」で始まらない場合、一般に、複合身体部分のほとんどのヘッダーフィールドが無視されます。 HTTP/1.1では、複合身体部分はどんなその部分の意味に重要なHTTPヘッダ分野も含むかもしれません。
Fielding, et. al. Standards Track [Page 153] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[153ページ]RFC2068HTTP/1997年1月1.1日
19.4.6 Introduction of Transfer-Encoding
19.4.6 転送コード化の導入
HTTP/1.1 introduces the Transfer-Encoding header field (section 14.40). Proxies/gateways MUST remove any transfer coding prior to forwarding a message via a MIME-compliant protocol.
HTTP/1.1はTransferをコード化しているヘッダーフィールド(セクション14.40)を導入します。 MIME対応することのプロトコルでメッセージを転送する前に、プロキシ/ゲートウェイはどんな転送コード化も取り除かなければなりません。
A process for decoding the "chunked" transfer coding (section 3.6) can be represented in pseudo-code as:
以下として中間コードで"chunkedする"の転送コード化(セクション3.6)を解読するためのプロセスを表すことができます。
length := 0
read chunk-size, chunk-ext (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
長さ:=0、塊サイズ、(もしあれば)の塊-ext、およびCRLFが(塊サイズ>0)である間、読まれて、読書塊データとCRLFが塊サイズとCRLFが読まれた実体本体長さの:=塊長さ+サイズに塊データを追加する、実体ヘッダーがゆったり過ごす(実体ヘッダーは空になりません)読書が満足している長さで実体ヘッダーに読み込まれた既存のヘッダーフィールドへの実体ヘッダーを追加する、:=の長さのRemoveはTransfer-コード化から「chunkedしました」。
19.4.7 MIME-Version
19.4.7 MIMEバージョン
HTTP is not a MIME-compliant protocol (see appendix 19.4). However, HTTP/1.1 messages may include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full compliance with the MIME protocol. Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME environments.
HTTPはMIME対応することのプロトコル(付録19.4を見る)ではありません。 しかしながら、HTTP/1.1のメッセージが、MIMEプロトコルのどんなバージョンがメッセージを構成するのに使用されたかを示すためにただ一つのMIMEバージョン一般的なヘッダーフィールドを含むかもしれません。 MIMEバージョンヘッダーフィールドの使用は、メッセージがMIMEプロトコルに応えてあるのを示します。 プロキシ/ゲートウェイはHTTPがメッセージであると厳しいMIME環境にエクスポートするとき完全なコンプライアンス(可能であるところ)を確実にするのに原因となります。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
「MIMEバージョンは「MIMEバージョン」と等しい」:、」 「1*ケタ」、」 1*ケタ
MIME version "1.0" is the default for use in HTTP/1.1. However, HTTP/1.1 message parsing and semantics are defined by this document and not the MIME specification.
「1インチはHTTP/1.1における使用のためのデフォルトです」というMIMEバージョン。 しかしながら、HTTP/1.1のメッセージ構文解析と意味論はMIME仕様ではなく、このドキュメントによって定義されます。
19.5 Changes from HTTP/1.0
19.5 HTTP/1.0からの変化
This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.
このセクションはバージョンHTTP/1.0とHTTP/1.1の主要な違いをまとめます。
Fielding, et. al. Standards Track [Page 154] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[154ページ]RFC2068HTTP/1997年1月1.1日
19.5.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
Addresses
19.5.1 簡素化する変化、マルチ、家へ帰り、ウェブサーバー、IPアドレスを保存してください。
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要求ヘッダー(セクション14.23)がHTTP/1.1要求によって行方不明であるなら誤りを報告して、絶対URI(セクション5.1.2)を受け入れるという要件があります。
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アドレスとサーバの1〜1つの関係を仮定しました。 その要求が向けられたIPアドレス以外の要求の意図しているサーバを区別するためのどんな確立したメカニズムもありませんでした。 上に概説された変化はインターネットを許容して、かつてより年取ったHTTPクライアントはただ一つのIPアドレスからの複数のウェブサイトをサポートするためにもう一般的ではありません、大きい操作上のウェブサーバ(独身のホストへの多くのIPアドレスの配分は深刻な問題を作成した)を大いに簡素化して。また、インターネットは専用ドメイン名が根レベルHTTP URLで使用されるのを許容する唯一の目的のために割り当てられたIPアドレスを回復できるでしょう。 ウェブの成長率、および既に配布されたサーバの数を考えて、HTTP(既存のHTTP/1.0のアプリケーションにアップデートを含める)のすべての実装が正しくこれらの要件を実装するのは、非常に重要です:
o Both clients and servers MUST support the Host request-header.
o クライアントとサーバの両方がHost要求ヘッダーを支えなければなりません。
o Host request-headers are required in HTTP/1.1 requests.
o ホスト要求ヘッダーがHTTP/1.1の要求で必要です。
o Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
request does not include a Host request-header.
o HTTP/1.1要求がHost要求ヘッダーを含んでいないなら、サーバは400(悪いRequest)誤りを報告しなければなりません。
o Servers MUST accept absolute URIs.
o サーバは絶対URIを受け入れなければなりません。
Fielding, et. al. Standards Track [Page 155] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[155ページ]RFC2068HTTP/1997年1月1.1日
19.6 Additional Features
19.6 追加特徴
This appendix documents protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1 applications. Implementers should be aware of these features, but cannot rely upon their presence in, or interoperability with, other 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.
この付録は、ほとんどのHTTP/1.1のアプリケーションの向こう側にいくつかの既存のHTTP実装によって使用されるプロトコル要素を記録しますが、一貫して、正しく記録するというわけではありません。 中のそれらの存在、または相互運用性を当てにすることができないのを除いて、Implementersがこれらの特徴を知るべきである、他のHTTP/1.1のアプリケーション。 これらの或るものは提案された実験特徴について説明します、そして、或るものは現在ベースHTTP/1.1仕様で扱われた状態でそれを欠いているのが見つけられた実験的な展開がある特徴について説明します。
19.6.1 Additional Request Methods
19.6.1 追加要求メソッド
19.6.1.1 PATCH
19.6.1.1 パッチ
The PATCH method is similar to PUT except that the entity contains a list of differences between the original version of the resource identified by the Request-URI and the desired content of the resource after the PATCH action has been applied. The list of differences is in a format defined by the media type of the entity (e.g., "application/diff") and MUST include sufficient information to allow the server to recreate the changes necessary to convert the original version of the resource to the desired version.
PATCH動作が適用された後に実体がRequest-URIによって特定されたリソースのオリジナルバージョンとリソースの必要な内容の間に違いのリストを含んでいるのを除いて、PATCHメソッドはPUTと同様です。 違いのリストは、実体(例えば、「アプリケーション/デフ」)のメディアタイプによって定義された書式にはあって、サーバがリソースのオリジナルバージョンを必要なバージョンに変換するのに必要な変化を休養させるのを許容するために十分な情報を含まなければなりません。
If the request passes through a cache and the Request-URI identifies a currently cached entity, that entity MUST be removed from the cache. Responses to this method are not cachable.
要求がキャッシュを通り抜けて、Request-URIが現在キャッシュされた実体を特定するなら、キャッシュからその実体を取り除かなければなりません。 このメソッドへの応答はキャッシュ可能ではありません。
The actual method for determining how the patched resource is placed, and what happens to its predecessor, is defined entirely by the origin server. If the original version of the resource being patched included a Content-Version header field, the request entity MUST include a Derived-From header field corresponding to the value of the original Content-Version header field. Applications are encouraged to use these fields for constructing versioning relationships and resolving version conflicts.
パッチしているリソースがどのように置かれるかを決定するための実際のメソッド、および前任者に起こることは完全に発生源サーバによって定義されます。パッチされるリソースのオリジナルバージョンがContent-バージョンヘッダーフィールドを含んでいたなら、要求実体がaを含まなければならない、Derived、-、元のContent-バージョンヘッダーフィールドの値に対応するヘッダーフィールド。 アプリケーションが組み立てるのに関係をversioningして、バージョン闘争を解決しながらこれらの分野を使用するよう奨励されます。
PATCH requests must obey the message transmission requirements set out in section 8.2.
PATCH要求はセクション8.2を始められたメッセージトランスミッション要件に従わなければなりません。
Caches that implement PATCH should invalidate cached responses as defined in section 13.10 for PUT.
道具PATCHが無効にするはずであるキャッシュはPUTのためにセクション13.10で定義されるように応答をキャッシュしました。
19.6.1.2 LINK
19.6.1.2 リンク
The LINK method establishes one or more Link relationships between the existing resource identified by the Request-URI and other existing resources. The difference between LINK and other methods
LINKメソッドはRequest-URIによって特定された既存のリソースと他の既存のリソースとの1Linkの関係を確立します。 LINKと他のメソッドの違い
Fielding, et. al. Standards Track [Page 156] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[156ページ]RFC2068HTTP/1997年1月1.1日
allowing links to be established between resources is that the LINK method does not allow any message-body to be sent in the request and does not directly result in the creation of new resources.
リンクがリソースの間に設立されるのを許容するのが、LINKメソッドが、どんなメッセージ本体も要求で送られるのを許容しないということであり、直接新しいリソースの作成をもたらしません。
If the request passes through a cache and the Request-URI identifies a currently cached entity, that entity MUST be removed from the cache. Responses to this method are not cachable.
要求がキャッシュを通り抜けて、Request-URIが現在キャッシュされた実体を特定するなら、キャッシュからその実体を取り除かなければなりません。 このメソッドへの応答はキャッシュ可能ではありません。
Caches that implement LINK should invalidate cached responses as defined in section 13.10 for PUT.
道具LINKが無効にするはずであるキャッシュはPUTのためにセクション13.10で定義されるように応答をキャッシュしました。
19.6.1.3 UNLINK
19.6.1.3 離れてください。
The UNLINK method removes one or more Link relationships from the existing resource identified by the Request-URI. These relationships may have been established using the LINK method or by any other method supporting the Link header. The removal of a link to a resource does not imply that the resource ceases to exist or becomes inaccessible for future references.
UNLINKメソッドはRequest-URIによって特定された既存のリソースから1Linkの関係を取り除きます。 これらの関係は、LINKメソッドを使用するか、またはいかなる他のメソッドでもLinkヘッダーを支えながら、確立されたかもしれません。 リソースへのリンクの取り外しは、リソースが存在するのをやめるか、または後学に近づきがたくなるのを含意しません。
If the request passes through a cache and the Request-URI identifies a currently cached entity, that entity MUST be removed from the cache. Responses to this method are not cachable.
要求がキャッシュを通り抜けて、Request-URIが現在キャッシュされた実体を特定するなら、キャッシュからその実体を取り除かなければなりません。 このメソッドへの応答はキャッシュ可能ではありません。
Caches that implement UNLINK should invalidate cached responses as defined in section 13.10 for PUT.
道具UNLINKが無効にするはずであるキャッシュはPUTのためにセクション13.10で定義されるように応答をキャッシュしました。
19.6.2 Additional Header Field Definitions
19.6.2 追加ヘッダーフィールド定義
19.6.2.1 Alternates
19.6.2.1 補欠
The Alternates response-header field has been proposed as a means for the origin server to inform the client about other available representations of the requested resource, along with their distinguishing attributes, and thus providing a more reliable means for a user agent to perform subsequent selection of another representation which better fits the desires of its user (described as agent-driven negotiation in section 12).
Alternates応答ヘッダ分野は発生源サーバが要求されたリソースの他の利用可能な表現に関してクライアントに知らせる手段として提案されました、彼らが属性を区別して、その結果、ユーザエージェントがユーザ(セクション12でエージェント駆動の交渉として記述されている)の願望に合うほうがよい別の表現のその後の選択を実行するより信頼できる手段を提供すると共に。
Fielding, et. al. Standards Track [Page 157] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[157ページ]RFC2068HTTP/1997年1月1.1日
The Alternates header field is orthogonal to the Vary header field in that both may coexist in a message without affecting the interpretation of the response or the available representations. It is expected that Alternates will provide a significant improvement over the server-driven negotiation provided by the Vary field for those resources that vary over common dimensions like type and language.
両方がメッセージに応答の解釈か利用可能な表現に影響しないで共存するかもしれないので、AlternatesヘッダーフィールドはVaryヘッダーフィールドと直交しています。 AlternatesがVary分野によってタイプと言語のような一般的な寸法の上異なるそれらのリソースに提供されたサーバ駆動の交渉の上にかなりの改善を提供すると予想されます。
The Alternates header field will be defined in a future specification.
Alternatesヘッダーフィールドは将来の仕様に基づき定義されるでしょう。
19.6.2.2 Content-Version
19.6.2.2 満足しているバージョン
The Content-Version entity-header field defines the version tag associated with a rendition of an evolving entity. Together with the Derived-From field described in section 19.6.2.3, it allows a group of people to work simultaneously on the creation of a work as an iterative process. The field should be used to allow evolution of a particular work along a single path rather than derived works or renditions in different representations.
Content-バージョン実体ヘッダーフィールドは発展実体の表現に関連しているバージョンタグを定義します。 Derived、-、分野説明されたコネセクション19.6.2.3、それで、人々のグループは同時に、繰り返し作業として仕事の作成に取り組みます。 分野は、異なった表現における作品か表現を引き出すよりただ一つの経路に沿ってむしろ特定の仕事の発展を許容するのに使用されるべきです。
Content-Version = "Content-Version" ":" quoted-string
「満足しているバージョンは「満足しているバージョン」と等しい」:、」 引用文字列
Examples of the Content-Version field include:
Content-バージョン分野に関する例は:
Content-Version: "2.1.2"
Content-Version: "Fred 19950116-12:26:48"
Content-Version: "2.5a4-omega7"
満足しているバージョン: 「0.2インチの2.1の満足しているバージョン:」 「フレッドの19950116-12:26:48インチの内容バージョン:」 "2.5a4-omega7""
19.6.2.3 Derived-From
19.6.2.3、派生
The Derived-From entity-header field can be used to indicate the version tag of the resource from which the enclosed entity was derived before modifications were made by the sender. This field is used to help manage the process of merging successive changes to a resource, particularly when such changes are being made in parallel and from multiple sources.
Derived、-、変更が送付者によってされる前に同封の実体が引き出されたリソースのバージョンタグを示すのに実体ヘッダーフィールドを使用できます。 この分野はリソースへの連続した変化を合併するプロセスを管理するのを助けるのに使用されます、特にそのような変化が平行で作られていて複数のソースから来ているとき。
Derived-From = "Derived-From" ":" quoted-string
「=から派生する、「派生」、」、:、」 引用文字列
An example use of the field is:
分野の例の使用は以下の通りです。
Derived-From: "2.1.1"
派生しているFrom: "2.1.1"
The Derived-From field is required for PUT and PATCH requests if the entity being sent was previously retrieved from the same URI and a Content-Version header was included with the entity when it was last retrieved.
Derived、-、分野、PUTとPATCH要求のために、送られる実体が以前に、同じURIから検索されて、それが最後に検索されたときContent-バージョンヘッダーが実体で含まれたなら、必要です。
Fielding, et. al. Standards Track [Page 158] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[158ページ]RFC2068HTTP/1997年1月1.1日
19.6.2.4 Link
19.6.2.4 リンク
The Link entity-header field provides a means for describing a relationship between two resources, generally between the requested resource and some other resource. An entity MAY include multiple Link values. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths. The Link field is semantically equivalent to the <LINK> element in HTML.[5]
Link実体ヘッダーフィールドは2つのリソースの間の関係について説明するための手段を提供します、一般に要求されたリソースとある他のリソースの間で。 実体は複数のLink値を含むかもしれません。 metainformationレベルにおけるリンクは階層構造と通船路のような関係を通常示します。 Link分野はHTMLにおける<LINK>要素に意味的に同等です。[5]
Link = "Link" ":" #("<" URI ">" *( ";" link-param )
「リンク=「リンク」」:、」 #("<"ユリ">"*(「」、;、リンク-param)
link-param = ( ( "rel" "=" relationship )
| ( "rev" "=" relationship )
| ( "title" "=" quoted-string )
| ( "anchor" "=" <"> URI <"> )
| ( link-extension ) )
リンク-param=("rel"は関係と「等しい」)| (「回転」は関係と「等しい」)| (引用文字列と「等しい」という「タイトル」)|、(「アンカー」「=」<、「>ユリ<、「>) | (リンク拡大)」
link-extension = token [ "=" ( token | quoted-string ) ]
リンク拡大はトークンと等しいです。[「=」(トークン| 引用文字列)]
relationship = sgml-name
| ( <"> sgml-name *( SP sgml-name) <"> )
関係=sgml-名| (<、「>sgml-名前*(SP sgml-名前)<、「>)」
sgml-name = ALPHA *( ALPHA | DIGIT | "." | "-" )
sgml-名前=アルファー*「(アルファー| ケタ| 」 . 」 | 「-」)
Relationship values are case-insensitive and MAY be extended within the constraints of the sgml-name syntax. The title parameter MAY be used to label the destination of a link such that it can be used as identification within a human-readable menu. The anchor parameter MAY be used to indicate a source anchor other than the entire current resource, such as a fragment of this resource or a third resource.
関係値は、大文字と小文字を区別しなく、sgml-名前構文の規制の中で広げられるかもしれません。 タイトルパラメタは、識別として人間読み込み可能なメニューの中でそれを使用できるようにリンクの目的地をラベルするのに使用されるかもしれません。 アンカーパラメタは全体の現在のリソース以外のソースのアンカーを示すのに使用されるかもしれません、このリソースか3番目のリソースの断片のように。
Examples of usage include:
用法に関する例は:
Link: <http://www.cern.ch/TheBook/chapter2>; rel="Previous"
以下をリンクしてください。 <http://www.cern.ch/TheBook/chapter2>。 rel=「前です」。
Link: <mailto:timbl@w3.org>; rev="Made"; title="Tim Berners-Lee"
以下をリンクしてください。 <mailto: timbl@w3.org 、gt;、。 =が「作った」回転。 タイトルは「ティム・バーナーズ・リー」と等しいです。
The first example indicates that chapter2 is previous to this resource in a logical navigation path. The second indicates that the person responsible for making the resource available is identified by the given e-mail address.
最初の例は、chapter2が論理的な通船路のこのリソースに前であることを示します。 2番目は、リソースを利用可能にするのに責任がある人が与えられたEメールアドレスによって特定されるのを示します。
19.6.2.5 URI
19.6.2.5 ユリ
The URI header field has, in past versions of this specification, been used as a combination of the existing Location, Content- Location, and Vary header fields as well as the future Alternates
この仕様の過去のバージョンでは、URIヘッダーフィールドは既存のLocation、Content位置、および将来のAlternatesと同様にVaryヘッダーフィールドの組み合わせとして使用されました。
Fielding, et. al. Standards Track [Page 159] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[159ページ]RFC2068HTTP/1997年1月1.1日
field (above). Its primary purpose has been to include a list of additional URIs for the resource, including names and mirror locations. However, it has become clear that the combination of many different functions within this single field has been a barrier to consistently and correctly implementing any of those functions. Furthermore, we believe that the identification of names and mirror locations would be better performed via the Link header field. The URI header field is therefore deprecated in favor of those other fields.
(above)をさばいてください。 プライマリ目的は名前と鏡の位置を含むリソースのための追加URIのリストを含むことです。 しかしながら、このただ一つの分野の中の多くの異なった機能の組み合わせが一貫して、正しくそれらの機能のどれかを実装することへのバリアであることは明確になりました。 その上、私たちは、名前と鏡の位置の識別がLinkヘッダーフィールドで実行されるほうがよいと信じています。 したがって、URIヘッダーフィールドはそれらの他の分野を支持して推奨しないです。
URI-header = "URI" ":" 1#( "<" URI ">" )
「URIヘッダー=「URI」」:、」 1#("<"ユリ">")
19.7 Compatibility with Previous Versions
19.7 旧バージョンとの互換性
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, we would expect commercial HTTP/1.1 servers to:
それは、旧バージョンへのコンプライアンスを強制するためにプロトコル仕様の範囲を超えています。 しかしながら、HTTP/1.1は、旧バージョンをサポートするのを簡単にするように故意に設計されました。 この仕様を構成する時点でそれに注意する価値がある、私たちは以下のことと市販のHTTP/1.1のサーバは予想するでしょう。
o recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1
requests;
o HTTP/0.9、1.0、および1.1の要求としてRequest-線の形式を認識してください。
o understand any valid request in the format of HTTP/0.9, 1.0, or
1.1;
o HTTP/0.9、1.0、または1.1の形式であらゆる有効な要求を理解してください。
o respond appropriately with a message in the same major version used
by the client.
o メッセージがクライアントによって使用された同じ主要なバージョンにある状態で、適切に応じてください。
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 HTTP/1.0と1.1の応答としてStatus-線の形式を認識してください。
o understand any valid response in the format of HTTP/0.9, 1.0, or
1.1.
o 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 implementations implement the Keep-Alive version of persistent connections described in section 19.7.1.1.
HTTP/1.0のほとんどの実装において、各接続は、要求の前にクライアントによって確立されて、応答を送った後に、サーバによって閉店させられます。 いくつかの実装がセクション19.7.1で.1に説明されたパーシステントコネクションの生きているKeepバージョンを実装します。
Fielding, et. al. Standards Track [Page 160] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[160ページ]RFC2068HTTP/1997年1月1.1日
19.7.1 Compatibility with HTTP/1.0 Persistent Connections
19.7.1 HTTP/1.0のパーシステントコネクションとの互換性
Some clients and servers may wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 clients and servers. Persistent connections in HTTP/1.0 must be explicitly negotiated as they are not the default behavior. HTTP/1.0 experimental implementations of persistent connections are faulty, and the new facilities in HTTP/1.1 are designed to rectify these problems. The problem was that some existing 1.0 clients may be sending Keep-Alive to a proxy server that doesn't understand Connection, which would then erroneously forward it to the next inbound server, which would establish the Keep-Alive connection and result in a hung HTTP/1.0 proxy waiting for the close on the response. The result is that HTTP/1.0 clients must be prevented from using Keep-Alive when talking to proxies.
いくつかのクライアントとサーバがHTTP/1.0のクライアントとサーバのパーシステントコネクションの前のいくつかの実装と互換性がありたがっているかもしれません。 それらがデフォルトの振舞いでないので、明らかにHTTP/1.0におけるパーシステントコネクションを交渉しなければなりません。 パーシステントコネクションのHTTP/1.0の実験的な実装が不完全です、そして、HTTP/1.1における新しい設備は、これらの問題を調整するように設計されています。問題は何人かの既存の1.0人のクライアントが次に誤って応答のときに閉鎖を待つ掛かっているHTTP/1.0プロキシに生きているKeep接続と結果を確立するだろう次の本国行きのサーバにそれを送るだろうConnectionを理解していないプロキシサーバに生きているKeepを送るかもしれないということでした。 結果はプロキシと話すとき、生きているKeepを使用するのをHTTP/1.0人のクライアントを防がなければならないということです。
However, talking to proxies is the most important use of persistent connections, so that prohibition is clearly unacceptable. Therefore, we need some other mechanism for indicating a persistent connection is desired, which is safe to use even when talking to an old proxy that ignores Connection. Persistent connections are the default for HTTP/1.1 messages; we introduce a new keyword (Connection: close) for declaring non-persistence.
しかしながら、プロキシと話すのが、パーシステントコネクションの最も重要な使用であるので、禁止は明確に容認できません。 したがって、パーシステントコネクション(Connectionを無視する年取ったプロキシと話すときさえ、使用するために安全である)が望まれているのを示すのに私たちはある他のメカニズムを必要とします。 パーシステントコネクションはHTTP/1.1のメッセージのためのデフォルトです。 私たちは、非固執を宣言するために新しいキーワードを紹介します(接続: 閉じてください)。
The following describes the original HTTP/1.0 form of persistent connections.
以下は元のHTTP/1.0フォームのパーシステントコネクションを説明します。
When it connects to an origin server, an HTTP client MAY send the Keep-Alive connection-token in addition to the Persist connection- token:
発生源サーバに接続するとき、HTTPクライアントはPersist接続に加えた生きているKeep接続トークントークンを送るかもしれません:
Connection: Keep-Alive
接続: 生きている生活費
An HTTP/1.0 server would then respond with the Keep-Alive connection token and the client may proceed with an HTTP/1.0 (or Keep-Alive) persistent connection.
次に、HTTP/1.0サーバは生きているKeep接続トークンで反応するでしょう、そして、クライアントはHTTP/1.0(または、生きているKeep)パーシステントコネクションを続けるかもしれません。
An HTTP/1.1 server may also establish persistent connections with HTTP/1.0 clients upon receipt of a Keep-Alive connection token. However, a persistent connection with an HTTP/1.0 client cannot make use of the chunked transfer-coding, and therefore MUST use a Content-Length for marking the ending boundary of each message.
また、HTTP/1.1サーバは生きているKeep接続トークンを受け取り次第HTTP/1.0人のクライアントと共にパーシステントコネクションを確立するかもしれません。 しかしながら、HTTP/1.0クライアントがいるパーシステントコネクションは、chunked転送コード化を利用できないで、したがって、それぞれのメッセージの終わりの限界をマークするのにContent-長さを使用しなければなりません。
A client MUST NOT send the Keep-Alive connection token to a proxy server as HTTP/1.0 proxy servers do not obey the rules of HTTP/1.1 for parsing the Connection header field.
HTTP/1.0のプロキシサーバがConnectionヘッダーフィールドを分析するためにHTTP/1.1の規則に従わないとき、クライアントは生きているKeep接続トークンをプロキシサーバに送ってはいけません。
Fielding, et. al. Standards Track [Page 161] RFC 2068 HTTP/1.1 January 1997
etフィールディング、アル。 標準化過程[161ページ]RFC2068HTTP/1997年1月1.1日
19.7.1.1 The Keep-Alive Header
19.7.1.1 生きている生活費ヘッダー
When the Keep-Alive connection-token has been transmitted with a request or a response, a Keep-Alive header field MAY also be included. The Keep-Alive header field takes the following form:
また、生きているKeep接続トークンが要求か応答で伝えられたとき、生きているKeepヘッダーフィールドは含まれるかもしれません。 生きているKeepヘッダーフィールドは以下の形を取ります:
Keep-Alive-header = "Keep-Alive" ":" 0# keepalive-param
「ヘッダーを生かしている=「生きている生活費」」:、」 0#keepalive-param
keepalive-param = param-name "=" value
param-名前「=」keepalive-param=価値
The Keep-Alive header itself is optional, and is used only if a parameter is being sent. HTTP/1.1 does not define any parameters.
生きているKeepヘッダー自体は、任意であり、パラメタを送る場合にだけ、使用されています。 HTTP/1.1はどんなパラメタも定義しません。
If the Keep-Alive header is sent, the corresponding connection token MUST be transmitted. The Keep-Alive header MUST be ignored if received without the connection token.
生きているKeepヘッダーを送るなら、対応する接続トークンを伝えなければなりません。 接続トークンなしで受け取るなら、生きているKeepヘッダーを無視しなければなりません。
Fielding, et. al. Standards Track [Page 162]
etフィールディング、アル。 標準化過程[162ページ]
一覧
スポンサーリンク
