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ページ]

スポンサーリンク

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

action名にlistは使えない listを使う方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る