Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: 2068 J. Gettys
Category: Standards Track Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999
Network Working Group R. Fielding
Request for Comments: 2616 UC Irvine
Obsoletes: 2068 J. Gettys
Category: Standards Track Compaq/W3C
J. Mogul
Compaq
H. Frystyk
W3C/MIT
L. Masinter
Xerox
P. Leach
Microsoft
T. Berners-Lee
W3C/MIT
June 1999
Hypertext Transfer Protocol -- HTTP/1.1
超文本传输协议——HTTP/1.1
Status of this 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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers [47]. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
超文本传输协议（HTTP）是用于分布式、协作、超媒体信息系统的应用程序级协议。它是一种通用的、无状态的协议，通过扩展其请求方法、错误代码和标题，可用于超文本以外的许多任务，如名称服务器和分布式对象管理系统[47]。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", and is an update to RFC 2068 [33].
自1990年以来，万维网全球信息倡议一直在使用HTTP。本规范定义了称为“HTTP/1.1”的协议，是对RFC 2068[33]的更新。
Table of Contents
目录
1 Introduction ...................................................7
1.1 Purpose......................................................7
1.2 Requirements .................................................8
1.3 Terminology ..................................................8
1.4 Overall Operation ...........................................12
2 Notational Conventions and Generic Grammar ....................14
2.1 Augmented BNF ...............................................14
2.2 Basic Rules .................................................15
3 Protocol Parameters ...........................................17
3.1 HTTP Version ................................................17
3.2 Uniform Resource Identifiers ................................18
3.2.1 General Syntax ...........................................19
3.2.2 http URL .................................................19
3.2.3 URI Comparison ...........................................20
3.3 Date/Time Formats ...........................................20
3.3.1 Full Date ................................................20
3.3.2 Delta Seconds ............................................21
3.4 Character Sets ..............................................21
3.4.1 Missing Charset ..........................................22
3.5 Content Codings .............................................23
3.6 Transfer Codings ............................................24
3.6.1 Chunked Transfer Coding ..................................25
3.7 Media Types .................................................26
3.7.1 Canonicalization and Text Defaults .......................27
3.7.2 Multipart Types ..........................................27
3.8 Product Tokens ..............................................28
3.9 Quality Values ..............................................29
3.10 Language Tags ...............................................29
3.11 Entity Tags .................................................30
3.12 Range Units .................................................30
4 HTTP Message ..................................................31
4.1 Message Types ...............................................31
4.2 Message Headers .............................................31
4.3 Message Body ................................................32
4.4 Message Length ..............................................33
4.5 General Header Fields .......................................34
5 Request .......................................................35
5.1 Request-Line ................................................35
5.1.1 Method ...................................................36
5.1.2 Request-URI ..............................................36
5.2 The Resource Identified by a Request ........................38
5.3 Request Header Fields .......................................38
6 Response ......................................................39
6.1 Status-Line .................................................39
6.1.1 Status Code and Reason Phrase ............................39
6.2 Response Header Fields ......................................41
1 Introduction ...................................................7
1.1 Purpose......................................................7
1.2 Requirements .................................................8
1.3 Terminology ..................................................8
1.4 Overall Operation ...........................................12
2 Notational Conventions and Generic Grammar ....................14
2.1 Augmented BNF ...............................................14
2.2 Basic Rules .................................................15
3 Protocol Parameters ...........................................17
3.1 HTTP Version ................................................17
3.2 Uniform Resource Identifiers ................................18
3.2.1 General Syntax ...........................................19
3.2.2 http URL .................................................19
3.2.3 URI Comparison ...........................................20
3.3 Date/Time Formats ...........................................20
3.3.1 Full Date ................................................20
3.3.2 Delta Seconds ............................................21
3.4 Character Sets ..............................................21
3.4.1 Missing Charset ..........................................22
3.5 Content Codings .............................................23
3.6 Transfer Codings ............................................24
3.6.1 Chunked Transfer Coding ..................................25
3.7 Media Types .................................................26
3.7.1 Canonicalization and Text Defaults .......................27
3.7.2 Multipart Types ..........................................27
3.8 Product Tokens ..............................................28
3.9 Quality Values ..............................................29
3.10 Language Tags ...............................................29
3.11 Entity Tags .................................................30
3.12 Range Units .................................................30
4 HTTP Message ..................................................31
4.1 Message Types ...............................................31
4.2 Message Headers .............................................31
4.3 Message Body ................................................32
4.4 Message Length ..............................................33
4.5 General Header Fields .......................................34
5 Request .......................................................35
5.1 Request-Line ................................................35
5.1.1 Method ...................................................36
5.1.2 Request-URI ..............................................36
5.2 The Resource Identified by a Request ........................38
5.3 Request Header Fields .......................................38
6 Response ......................................................39
6.1 Status-Line .................................................39
6.1.1 Status Code and Reason Phrase ............................39
6.2 Response Header Fields ......................................41
7 Entity ........................................................42
7.1 Entity Header Fields ........................................42
7.2 Entity Body .................................................43
7.2.1 Type .....................................................43
7.2.2 Entity Length ............................................43
8 Connections ...................................................44
8.1 Persistent Connections ......................................44
8.1.1 Purpose ..................................................44
8.1.2 Overall Operation ........................................45
8.1.3 Proxy Servers ............................................46
8.1.4 Practical Considerations .................................46
8.2 Message Transmission Requirements ...........................47
8.2.1 Persistent Connections and Flow Control ..................47
8.2.2 Monitoring Connections for Error Status Messages .........48
8.2.3 Use of the 100 (Continue) Status .........................48
8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
9 Method Definitions ............................................51
9.1 Safe and Idempotent Methods .................................51
9.1.1 Safe Methods .............................................51
9.1.2 Idempotent Methods .......................................51
9.2 OPTIONS .....................................................52
9.3 GET .........................................................53
9.4 HEAD ........................................................54
9.5 POST ........................................................54
9.6 PUT .........................................................55
9.7 DELETE ......................................................56
9.8 TRACE .......................................................56
9.9 CONNECT .....................................................57
10 Status Code Definitions ......................................57
10.1 Informational 1xx ...........................................57
10.1.1 100 Continue .............................................58
10.1.2 101 Switching Protocols ..................................58
10.2 Successful 2xx ..............................................58
10.2.1 200 OK ...................................................58
10.2.2 201 Created ..............................................59
10.2.3 202 Accepted .............................................59
10.2.4 203 Non-Authoritative Information ........................59
10.2.5 204 No Content ...........................................60
10.2.6 205 Reset Content ........................................60
10.2.7 206 Partial Content ......................................60
10.3 Redirection 3xx .............................................61
10.3.1 300 Multiple Choices .....................................61
10.3.2 301 Moved Permanently ....................................62
10.3.3 302 Found ................................................62
10.3.4 303 See Other ............................................63
10.3.5 304 Not Modified .........................................63
10.3.6 305 Use Proxy ............................................64
10.3.7 306 (Unused) .............................................64
7 Entity ........................................................42
7.1 Entity Header Fields ........................................42
7.2 Entity Body .................................................43
7.2.1 Type .....................................................43
7.2.2 Entity Length ............................................43
8 Connections ...................................................44
8.1 Persistent Connections ......................................44
8.1.1 Purpose ..................................................44
8.1.2 Overall Operation ........................................45
8.1.3 Proxy Servers ............................................46
8.1.4 Practical Considerations .................................46
8.2 Message Transmission Requirements ...........................47
8.2.1 Persistent Connections and Flow Control ..................47
8.2.2 Monitoring Connections for Error Status Messages .........48
8.2.3 Use of the 100 (Continue) Status .........................48
8.2.4 Client Behavior if Server Prematurely Closes Connection ..50
9 Method Definitions ............................................51
9.1 Safe and Idempotent Methods .................................51
9.1.1 Safe Methods .............................................51
9.1.2 Idempotent Methods .......................................51
9.2 OPTIONS .....................................................52
9.3 GET .........................................................53
9.4 HEAD ........................................................54
9.5 POST ........................................................54
9.6 PUT .........................................................55
9.7 DELETE ......................................................56
9.8 TRACE .......................................................56
9.9 CONNECT .....................................................57
10 Status Code Definitions ......................................57
10.1 Informational 1xx ...........................................57
10.1.1 100 Continue .............................................58
10.1.2 101 Switching Protocols ..................................58
10.2 Successful 2xx ..............................................58
10.2.1 200 OK ...................................................58
10.2.2 201 Created ..............................................59
10.2.3 202 Accepted .............................................59
10.2.4 203 Non-Authoritative Information ........................59
10.2.5 204 No Content ...........................................60
10.2.6 205 Reset Content ........................................60
10.2.7 206 Partial Content ......................................60
10.3 Redirection 3xx .............................................61
10.3.1 300 Multiple Choices .....................................61
10.3.2 301 Moved Permanently ....................................62
10.3.3 302 Found ................................................62
10.3.4 303 See Other ............................................63
10.3.5 304 Not Modified .........................................63
10.3.6 305 Use Proxy ............................................64
10.3.7 306 (Unused) .............................................64
10.3.8 307 Temporary Redirect ...................................65
10.4 Client Error 4xx ............................................65
10.4.1 400 Bad Request .........................................65
10.4.2 401 Unauthorized ........................................66
10.4.3 402 Payment Required ....................................66
10.4.4 403 Forbidden ...........................................66
10.4.5 404 Not Found ...........................................66
10.4.6 405 Method Not Allowed ..................................66
10.4.7 406 Not Acceptable ......................................67
10.4.8 407 Proxy Authentication Required .......................67
10.4.9 408 Request Timeout .....................................67
10.4.10 409 Conflict ............................................67
10.4.11 410 Gone ................................................68
10.4.12 411 Length Required .....................................68
10.4.13 412 Precondition Failed .................................68
10.4.14 413 Request Entity Too Large ............................69
10.4.15 414 Request-URI Too Long ................................69
10.4.16 415 Unsupported Media Type ..............................69
10.4.17 416 Requested Range Not Satisfiable .....................69
10.4.18 417 Expectation Failed ..................................70
10.5 Server Error 5xx ............................................70
10.5.1 500 Internal Server Error ................................70
10.5.2 501 Not Implemented ......................................70
10.5.3 502 Bad Gateway ..........................................70
10.5.4 503 Service Unavailable ..................................70
10.5.5 504 Gateway Timeout ......................................71
10.5.6 505 HTTP Version Not Supported ...........................71
11 Access Authentication ........................................71
12 Content Negotiation ..........................................71
12.1 Server-driven Negotiation ...................................72
12.2 Agent-driven Negotiation ....................................73
12.3 Transparent Negotiation .....................................74
13 Caching in HTTP ..............................................74
13.1.1 Cache Correctness ........................................75
13.1.2 Warnings .................................................76
13.1.3 Cache-control Mechanisms .................................77
13.1.4 Explicit User Agent Warnings .............................78
13.1.5 Exceptions to the Rules and Warnings .....................78
13.1.6 Client-controlled Behavior ...............................79
13.2 Expiration Model ............................................79
13.2.1 Server-Specified Expiration ..............................79
13.2.2 Heuristic Expiration .....................................80
13.2.3 Age Calculations .........................................80
13.2.4 Expiration Calculations ..................................83
13.2.5 Disambiguating Expiration Values .........................84
13.2.6 Disambiguating Multiple Responses ........................84
13.3 Validation Model ............................................85
13.3.1 Last-Modified Dates ......................................86
10.3.8 307 Temporary Redirect ...................................65
10.4 Client Error 4xx ............................................65
10.4.1 400 Bad Request .........................................65
10.4.2 401 Unauthorized ........................................66
10.4.3 402 Payment Required ....................................66
10.4.4 403 Forbidden ...........................................66
10.4.5 404 Not Found ...........................................66
10.4.6 405 Method Not Allowed ..................................66
10.4.7 406 Not Acceptable ......................................67
10.4.8 407 Proxy Authentication Required .......................67
10.4.9 408 Request Timeout .....................................67
10.4.10 409 Conflict ............................................67
10.4.11 410 Gone ................................................68
10.4.12 411 Length Required .....................................68
10.4.13 412 Precondition Failed .................................68
10.4.14 413 Request Entity Too Large ............................69
10.4.15 414 Request-URI Too Long ................................69
10.4.16 415 Unsupported Media Type ..............................69
10.4.17 416 Requested Range Not Satisfiable .....................69
10.4.18 417 Expectation Failed ..................................70
10.5 Server Error 5xx ............................................70
10.5.1 500 Internal Server Error ................................70
10.5.2 501 Not Implemented ......................................70
10.5.3 502 Bad Gateway ..........................................70
10.5.4 503 Service Unavailable ..................................70
10.5.5 504 Gateway Timeout ......................................71
10.5.6 505 HTTP Version Not Supported ...........................71
11 Access Authentication ........................................71
12 Content Negotiation ..........................................71
12.1 Server-driven Negotiation ...................................72
12.2 Agent-driven Negotiation ....................................73
12.3 Transparent Negotiation .....................................74
13 Caching in HTTP ..............................................74
13.1.1 Cache Correctness ........................................75
13.1.2 Warnings .................................................76
13.1.3 Cache-control Mechanisms .................................77
13.1.4 Explicit User Agent Warnings .............................78
13.1.5 Exceptions to the Rules and Warnings .....................78
13.1.6 Client-controlled Behavior ...............................79
13.2 Expiration Model ............................................79
13.2.1 Server-Specified Expiration ..............................79
13.2.2 Heuristic Expiration .....................................80
13.2.3 Age Calculations .........................................80
13.2.4 Expiration Calculations ..................................83
13.2.5 Disambiguating Expiration Values .........................84
13.2.6 Disambiguating Multiple Responses ........................84
13.3 Validation Model ............................................85
13.3.1 Last-Modified Dates ......................................86
13.3.2 Entity Tag Cache Validators ..............................86
13.3.3 Weak and Strong Validators ...............................86
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
13.3.5 Non-validating Conditionals ..............................90
13.4 Response Cacheability .......................................91
13.5 Constructing Responses From Caches ..........................92
13.5.1 End-to-end and Hop-by-hop Headers ........................92
13.5.2 Non-modifiable Headers ...................................92
13.5.3 Combining Headers ........................................94
13.5.4 Combining Byte Ranges ....................................95
13.6 Caching Negotiated Responses ................................95
13.7 Shared and Non-Shared Caches ................................96
13.8 Errors or Incomplete Response Cache Behavior ................97
13.9 Side Effects of GET and HEAD ................................97
13.10 Invalidation After Updates or Deletions ...................97
13.11 Write-Through Mandatory ...................................98
13.12 Cache Replacement .........................................99
13.13 History Lists .............................................99
14 Header Field Definitions ....................................100
14.1 Accept .....................................................100
14.2 Accept-Charset .............................................102
14.3 Accept-Encoding ............................................102
14.4 Accept-Language ............................................104
14.5 Accept-Ranges ..............................................105
14.6 Age ........................................................106
14.7 Allow ......................................................106
14.8 Authorization ..............................................107
14.9 Cache-Control ..............................................108
14.9.1 What is Cacheable .......................................109
14.9.2 What May be Stored by Caches ............................110
14.9.3 Modifications of the Basic Expiration Mechanism .........111
14.9.4 Cache Revalidation and Reload Controls ..................113
14.9.5 No-Transform Directive ..................................115
14.9.6 Cache Control Extensions ................................116
14.10 Connection ...............................................117
14.11 Content-Encoding .........................................118
14.12 Content-Language .........................................118
14.13 Content-Length ...........................................119
14.14 Content-Location .........................................120
14.15 Content-MD5 ..............................................121
14.16 Content-Range ............................................122
14.17 Content-Type .............................................124
14.18 Date .....................................................124
14.18.1 Clockless Origin Server Operation ......................125
14.19 ETag .....................................................126
14.20 Expect ...................................................126
14.21 Expires ..................................................127
14.22 From .....................................................128
13.3.2 Entity Tag Cache Validators ..............................86
13.3.3 Weak and Strong Validators ...............................86
13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates.89
13.3.5 Non-validating Conditionals ..............................90
13.4 Response Cacheability .......................................91
13.5 Constructing Responses From Caches ..........................92
13.5.1 End-to-end and Hop-by-hop Headers ........................92
13.5.2 Non-modifiable Headers ...................................92
13.5.3 Combining Headers ........................................94
13.5.4 Combining Byte Ranges ....................................95
13.6 Caching Negotiated Responses ................................95
13.7 Shared and Non-Shared Caches ................................96
13.8 Errors or Incomplete Response Cache Behavior ................97
13.9 Side Effects of GET and HEAD ................................97
13.10 Invalidation After Updates or Deletions ...................97
13.11 Write-Through Mandatory ...................................98
13.12 Cache Replacement .........................................99
13.13 History Lists .............................................99
14 Header Field Definitions ....................................100
14.1 Accept .....................................................100
14.2 Accept-Charset .............................................102
14.3 Accept-Encoding ............................................102
14.4 Accept-Language ............................................104
14.5 Accept-Ranges ..............................................105
14.6 Age ........................................................106
14.7 Allow ......................................................106
14.8 Authorization ..............................................107
14.9 Cache-Control ..............................................108
14.9.1 What is Cacheable .......................................109
14.9.2 What May be Stored by Caches ............................110
14.9.3 Modifications of the Basic Expiration Mechanism .........111
14.9.4 Cache Revalidation and Reload Controls ..................113
14.9.5 No-Transform Directive ..................................115
14.9.6 Cache Control Extensions ................................116
14.10 Connection ...............................................117
14.11 Content-Encoding .........................................118
14.12 Content-Language .........................................118
14.13 Content-Length ...........................................119
14.14 Content-Location .........................................120
14.15 Content-MD5 ..............................................121
14.16 Content-Range ............................................122
14.17 Content-Type .............................................124
14.18 Date .....................................................124
14.18.1 Clockless Origin Server Operation ......................125
14.19 ETag .....................................................126
14.20 Expect ...................................................126
14.21 Expires ..................................................127
14.22 From .....................................................128
14.23 Host .....................................................128
14.24 If-Match .................................................129
14.25 If-Modified-Since ........................................130
14.26 If-None-Match ............................................132
14.27 If-Range .................................................133
14.28 If-Unmodified-Since ......................................134
14.29 Last-Modified ............................................134
14.30 Location .................................................135
14.31 Max-Forwards .............................................136
14.32 Pragma ...................................................136
14.33 Proxy-Authenticate .......................................137
14.34 Proxy-Authorization ......................................137
14.35 Range ....................................................138
14.35.1 Byte Ranges ...........................................138
14.35.2 Range Retrieval Requests ..............................139
14.36 Referer ..................................................140
14.37 Retry-After ..............................................141
14.38 Server ...................................................141
14.39 TE .......................................................142
14.40 Trailer ..................................................143
14.41 Transfer-Encoding..........................................143
14.42 Upgrade ..................................................144
14.43 User-Agent ...............................................145
14.44 Vary .....................................................145
14.45 Via ......................................................146
14.46 Warning ..................................................148
14.47 WWW-Authenticate .........................................150
15 Security Considerations .......................................150
15.1 Personal Information....................................151
15.1.1 Abuse of Server Log Information .........................151
15.1.2 Transfer of Sensitive Information .......................151
15.1.3 Encoding Sensitive Information in URI's .................152
15.1.4 Privacy Issues Connected to Accept Headers ..............152
15.2 Attacks Based On File and Path Names .......................153
15.3 DNS Spoofing ...............................................154
15.4 Location Headers and Spoofing ..............................154
15.5 Content-Disposition Issues .................................154
15.6 Authentication Credentials and Idle Clients ................155
15.7 Proxies and Caching ........................................155
15.7.1 Denial of Service Attacks on Proxies....................156
16 Acknowledgments .............................................156
17 References ..................................................158
18 Authors' Addresses ..........................................162
19 Appendices ..................................................164
19.1 Internet Media Type message/http and application/http ......164
19.2 Internet Media Type multipart/byteranges ...................165
19.3 Tolerant Applications ......................................166
19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
14.23 Host .....................................................128
14.24 If-Match .................................................129
14.25 If-Modified-Since ........................................130
14.26 If-None-Match ............................................132
14.27 If-Range .................................................133
14.28 If-Unmodified-Since ......................................134
14.29 Last-Modified ............................................134
14.30 Location .................................................135
14.31 Max-Forwards .............................................136
14.32 Pragma ...................................................136
14.33 Proxy-Authenticate .......................................137
14.34 Proxy-Authorization ......................................137
14.35 Range ....................................................138
14.35.1 Byte Ranges ...........................................138
14.35.2 Range Retrieval Requests ..............................139
14.36 Referer ..................................................140
14.37 Retry-After ..............................................141
14.38 Server ...................................................141
14.39 TE .......................................................142
14.40 Trailer ..................................................143
14.41 Transfer-Encoding..........................................143
14.42 Upgrade ..................................................144
14.43 User-Agent ...............................................145
14.44 Vary .....................................................145
14.45 Via ......................................................146
14.46 Warning ..................................................148
14.47 WWW-Authenticate .........................................150
15 Security Considerations .......................................150
15.1 Personal Information....................................151
15.1.1 Abuse of Server Log Information .........................151
15.1.2 Transfer of Sensitive Information .......................151
15.1.3 Encoding Sensitive Information in URI's .................152
15.1.4 Privacy Issues Connected to Accept Headers ..............152
15.2 Attacks Based On File and Path Names .......................153
15.3 DNS Spoofing ...............................................154
15.4 Location Headers and Spoofing ..............................154
15.5 Content-Disposition Issues .................................154
15.6 Authentication Credentials and Idle Clients ................155
15.7 Proxies and Caching ........................................155
15.7.1 Denial of Service Attacks on Proxies....................156
16 Acknowledgments .............................................156
17 References ..................................................158
18 Authors' Addresses ..........................................162
19 Appendices ..................................................164
19.1 Internet Media Type message/http and application/http ......164
19.2 Internet Media Type multipart/byteranges ...................165
19.3 Tolerant Applications ......................................166
19.4 Differences Between HTTP Entities and RFC 2045 Entities ....167
19.4.1 MIME-Version ............................................167
19.4.2 Conversion to Canonical Form ............................167
19.4.3 Conversion of Date Formats ..............................168
19.4.4 Introduction of Content-Encoding ........................168
19.4.5 No Content-Transfer-Encoding ............................168
19.4.6 Introduction of Transfer-Encoding .......................169
19.4.7 MHTML and Line Length Limitations .......................169
19.5 Additional Features ........................................169
19.5.1 Content-Disposition .....................................170
19.6 Compatibility with Previous Versions .......................170
19.6.1 Changes from HTTP/1.0 ...................................171
19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
19.6.3 Changes from RFC 2068 ...................................172
20 Index .......................................................175
21 Full Copyright Statement ....................................176
19.4.1 MIME-Version ............................................167
19.4.2 Conversion to Canonical Form ............................167
19.4.3 Conversion of Date Formats ..............................168
19.4.4 Introduction of Content-Encoding ........................168
19.4.5 No Content-Transfer-Encoding ............................168
19.4.6 Introduction of Transfer-Encoding .......................169
19.4.7 MHTML and Line Length Limitations .......................169
19.5 Additional Features ........................................169
19.5.1 Content-Disposition .....................................170
19.6 Compatibility with Previous Versions .......................170
19.6.1 Changes from HTTP/1.0 ...................................171
19.6.2 Compatibility with HTTP/1.0 Persistent Connections ......172
19.6.3 Changes from RFC 2068 ...................................172
20 Index .......................................................175
21 Full Copyright Statement ....................................176
1 Introduction
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, or virtual hosts. In addition, the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order for two communicating applications to determine each other's true capabilities.
超文本传输协议（HTTP）是用于分布式、协作、超媒体信息系统的应用程序级协议。自1990年以来，万维网全球信息倡议一直在使用HTTP。HTTP的第一个版本被称为HTTP/0.9，是一个用于在Internet上传输原始数据的简单协议。RFC 1945[6]定义的HTTP/1.0改进了协议，允许消息采用类似MIME的消息格式，其中包含有关传输数据的元信息和请求/响应语义的修饰符。但是，HTTP/1.0没有充分考虑分层代理、缓存、持久连接的需要或虚拟主机的影响。此外，称自己为“HTTP/1.0”的未完全实现的应用程序大量增加，这就需要更改协议版本，以便两个通信应用程序确定彼此的真正功能。
This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than HTTP/1.0 in order to ensure reliable implementation of its features.
本规范定义了称为“HTTP/1.1”的协议。该协议包含比HTTP/1.0更严格的要求，以确保其功能的可靠实现。
Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods and headers that indicate the purpose of a request [47]. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [3], as a location (URL) [4] or name (URN) [20], for indicating the resource to which a
实用信息系统需要比简单检索更多的功能，包括搜索、前端更新和注释。HTTP允许一组开放的方法和头，用于指示请求的目的[47]。它建立在统一资源标识符（URI）[3]提供的引用规则的基础上，作为一个位置（URL）[4]或名称（URN）[20]，用于指示资源所指向的位置
method is to be applied. Messages are passed in a format similar to that used by Internet mail [9] as defined by the Multipurpose Internet Mail Extensions (MIME) [7].
方法将被应用。消息的传递格式类似于多用途Internet邮件扩展（MIME）[7]定义的Internet邮件[9]所使用的格式。
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还用作用户代理和到其他Internet系统的代理/网关之间通信的通用协议，包括SMTP[16]、NNTP[13]、FTP[18]、Gopher[2]和WAIS[10]协议支持的协议。通过这种方式，HTTP允许基本超媒体访问来自不同应用程序的资源。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [34].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[34]中所述进行解释。
An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocols it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the MUST level requirements but not all the SHOULD level requirements for its protocols is said to be "conditionally compliant."
如果实现未能满足其实现的协议的一个或多个必需或必需级别要求，则该实现是不兼容的。满足其协议的所有必须或要求级别和所有应该级别要求的实现称为“无条件兼容”；满足其协议的所有必须级别要求但并非所有应级别要求的协议称为“有条件兼容”
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.
为通信目的在两个程序之间建立的传输层虚拟电路。
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.
请求HTTP请求消息，如第5节所定义。
response An HTTP response message, as defined in section 6.
响应HTTP响应消息，如第6节所定义。
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, and resolutions) or vary in other ways.
资源可以通过URI识别的网络数据对象或服务，如第3.2节所定义。资源可以有多种表示形式（例如多种语言、数据格式、大小和分辨率），也可以以其他方式提供。
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.
实体作为请求或响应的有效负载传输的信息。实体由实体标题字段形式的元信息和实体正文形式的内容组成，如第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节所述，响应中包含的实体将接受内容协商。可能存在与特定响应状态关联的多个表示。
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 `varriant'. Use of the term `variant' does not necessarily imply that the resource is subject to content negotiation.
变体资源在任何给定时刻可能有一个或多个与其关联的表示。这些表述中的每一种都被称为“变量”。使用“变体”一词并不一定意味着资源要接受内容协商。
client A program that establishes connections for the purpose of sending requests.
客户端为发送请求而建立连接的程序。
user agent The client which initiates a request. These are often browsers, editors, spiders (web-traversing robots), or other end user tools.
用户代理发起请求的客户端。这些工具通常是浏览器、编辑器、爬行器（web遍历机器人）或其他最终用户工具。
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.
服务器一种应用程序，它接受连接，以便通过发送回响应来服务请求。任何给定的程序都可以既是客户机又是服务器；我们对这些术语的使用仅指程序为特定连接执行的角色，而不是指程序的总体功能。同样，任何服务器都可以充当源服务器、代理、网关或隧道，根据每个请求的性质进行切换。
origin server The server on which a given resource resides or is to be created.
源服务器给定资源所在或将要创建的服务器。
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. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies.
代理一种中间程序，它既是服务器又是客户端，用于代表其他客户端发出请求。请求由内部提供服务，或者通过将请求传递到其他服务器（可能需要翻译）来提供服务。代理必须实现本规范的客户机和服务器要求。“透明代理”是指不修改超出代理身份验证和标识要求的请求或响应的代理。“非透明代理”是修改请求或响应以便向用户代理提供一些附加服务的代理，例如组注释服务、媒体类型转换、协议缩减或匿名过滤。除非明确说明了透明或非透明行为，否则HTTP代理要求适用于这两种类型的代理。
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.
网关作为其他服务器中介的服务器。与代理不同，网关接收请求就像它是请求资源的源服务器一样；请求客户端可能不知道它正在与网关通信。
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.
隧道中间程序，在两个连接之间充当盲中继。一旦激活，隧道就不会被视为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 cacheable 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.
缓存程序的本地响应消息存储以及控制其消息存储、检索和删除的子系统。缓存存储可缓存的响应，以减少未来等效请求的响应时间和网络带宽消耗。任何客户端或服务器都可能包含缓存，但缓存不能由充当隧道的服务器使用。
cacheable A response is cacheable if a cache is allowed to store a copy of the response message for use in answering subsequent requests. The rules for determining the cacheability of HTTP responses are defined in section 13. Even if a resource is cacheable, there may be additional constraints on whether a cache can use the cached copy for a particular request.
可缓存如果允许缓存存储响应消息的副本以用于应答后续请求，则响应是可缓存的。第13节定义了确定HTTP响应可缓存性的规则。即使资源是可缓存的，缓存是否可以将缓存副本用于特定请求也可能存在其他限制。
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.
第一手如果响应直接从源服务器（可能通过一个或多个代理）发出且没有不必要的延迟，则响应是第一手的。如果一个响应的有效性已经直接与源服务器进行了检查，那么它也是第一手的。
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.
显式过期时间源服务器打算在未经进一步验证的情况下不再由缓存返回实体的时间。
heuristic expiration time An expiration time assigned by a cache when no explicit expiration time is available.
启发式过期时间当没有明确的过期时间可用时，缓存分配的过期时间。
age The age of a response is the time since it was sent by, or successfully validated with, the origin server.
年龄响应的年龄是自原始服务器发送响应或使用原始服务器成功验证响应以来的时间。
freshness lifetime The length of time between the generation of a response and its expiration time.
freshness lifetime响应生成与过期之间的时间长度。
fresh A response is fresh if its age has not yet exceeded its freshness lifetime.
新鲜如果响应的年龄尚未超过其新鲜度寿命，则该响应是新鲜的。
stale A response is stale if its age has passed its freshness lifetime.
如果响应的时间已过其新鲜度生命周期，则该响应已过时。
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.
语义透明当缓存的使用既不影响请求客户端也不影响源服务器时，缓存就特定响应而言以“语义透明”的方式运行，只是为了提高性能。当缓存在语义上是透明的时，客户端接收到的响应（逐跳标头除外）与原始服务器直接处理其请求时接收到的响应完全相同。
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协议元素（例如，实体标记或上次修改的时间），用于确定缓存条目是否是实体的等效副本。
upstream/downstream Upstream and downstream describe the flow of a message: all messages flow from upstream to downstream.
上游/下游上游和下游描述消息流：所有消息从上游流向下游。
inbound/outbound Inbound and outbound refer to the request and response paths for messages: "inbound" means "traveling toward the origin server", and "outbound" means "traveling toward the user agent"
入站/出站入站和出站是指消息的请求和响应路径：“入站”表示“向源服务器移动”，“出站”表示“向用户代理移动”
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协议是一种请求/响应协议。客户端以请求方法、URI和协议版本的形式向服务器发送请求，然后通过与服务器的连接发送一条类似MIME的消息，其中包含请求修饰符、客户端信息和可能的正文内容。服务器以状态行响应，包括消息的协议版本和成功或错误代码，然后是一条类似MIME的消息，其中包含服务器信息、实体元信息和可能的实体正文内容。HTTP和MIME之间的关系如附录19.4所述。
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
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or 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.
当请求/响应链中存在一个或多个中介时，会出现更复杂的情况。中介有三种常见形式：代理、网关和隧道。代理是一个转发代理，接收绝对形式的URI请求，重写全部或部分消息，并将重新格式化的请求转发到URI标识的服务器。网关是一个接收代理，充当其他服务器上的一层，如果需要，将请求转换为底层服务器的协议。隧道充当两个连接之间的中继点，而不改变消息；当通信需要通过中介（如防火墙）时，即使中介无法理解消息的内容，也会使用隧道。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain will pass through four separate connections. This distinction is important because some HTTP communication options
上图显示了用户代理和源服务器之间的三个中介（A、B和C）。在整个链中传递的请求或响应消息将通过四个单独的连接。这种区别很重要，因为有些HTTP通信选项
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可能正在接收来自A以外的许多客户端的请求，和/或将请求转发到C以外的服务器。
Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response from O (via C) for a request which has not been cached by UA or A.
不充当隧道的任何通信方都可以使用内部缓存来处理请求。缓存的效果是，如果链上的一个参与者具有适用于该请求的缓存响应，则请求/响应链会缩短。下面举例说明了如果B对UA或a未缓存的请求具有来自O（通过C）的早期响应的缓存副本，则产生的链。
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
Not all responses are usefully cacheable, and some requests may contain modifiers which place special requirements on cache behavior. HTTP requirements for cache behavior and cacheable 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.
事实上，目前正在万维网上试验或部署各种各样的缓存和代理体系结构和配置。这些系统包括用于节省跨洋带宽的代理缓存的国家层次结构、广播或多播缓存项的系统、通过CD-ROM分发缓存数据子集的组织，等等。HTTP系统用于通过高带宽链路的公司内部网，以及通过具有低功率无线电链路和间歇性连接的PDA进行访问。HTTP/1.1的目标是支持已经部署的广泛多样的配置，同时引入协议结构，以满足那些构建需要高可靠性的web应用程序的人的需要，如果没有高可靠性，至少需要可靠的故障指示。
HTTP communication usually takes place over TCP/IP connections. The default port is TCP 80 [19], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used; 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连接进行。默认端口为TCP 80[19]，但也可以使用其他端口。这并不妨碍HTTP在Internet或其他网络上的任何其他协议之上实现。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中，一个连接可用于一个或多个请求/响应交换，尽管连接可能因各种原因而关闭（见第8.1节）。
2 Notational Conventions and Generic Grammar
2符号约定和一般语法
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]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
本文件中规定的所有机制均以散文和类似于RFC 822[9]所用的增广巴科斯-诺尔形式（BNF）进行了描述。为了理解这个规范，实现者需要熟悉这个符号。扩充BNF包括以下结构：
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. White space 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.
名称=定义规则的名称只是名称本身（没有任何封闭的“<”和“>”），并用相等的“=”字符与其定义分开。只有在连续行的缩进用于指示跨越多行的规则定义时，空格才有意义。某些基本规则是大写的，如SP、LWS、HT、CRLF、DIGIT、ALPHA等。如果有角括号，则在定义中使用角括号，以便于识别规则名称的使用。
"literal" Quotation marks surround literal text. Unless stated otherwise, the text is case-insensitive.
“文字”引号围绕文字。除非另有说明，否则文本不区分大小写。
rule1 | rule2 Elements separated by a bar ("|") are alternatives, e.g., "yes | no" will accept yes or no.
规则1 |规则2元素之间用条（“|”）分隔是可选的，例如，“是|否”将接受是或否。
(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".
（规则1规则2）括号内的元素被视为单个元素。因此，“（elem（foo | bar）elem）”允许令牌序列“elem foo elem”和“elem bar 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*2元素”允许一个或两个。
[rule] Square brackets enclose optional elements; "[foo bar]" is equivalent to "*1(foo bar)".
[规则]方括号内包含可选元素；“[foo-bar]”相当于“*1（foo-bar）”。
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特定于规则的重复：“<N>（元素）”相当于“<N>*<N>（元素）”；也就是说，正好<n>出现（元素）。因此，2DIGIT是一个2位数字，3ALPHA是一个由三个字母组成的字符串。
#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 white space (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 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.
#规则定义了一个构造“#”，类似于“*”，用于定义元素列表。完整形式为“<n>#<m>元素”，表示至少<n>且最多<m>元素，每个元素由一个或多个逗号（“，”）和可选的线性空白（LWS）分隔。这使得列表的通常形式非常容易；诸如（*LWS-element*（*LWS“，“*LWS-element））之类的规则可以显示为1#元素。无论在何处使用此构造，都允许使用空元素，但不影响当前元素的计数。也就是说，允许使用“（元素），（元素）”，但仅计为两个元素。因此，当至少需要一个元素时，必须至少存在一个非空元素。默认值为0和无穷大，因此“#元素”允许任何数字，包括零；“1#元素”至少需要一个；“1#2element”允许一个或两个。
; 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.
; 注释分号，在规则文本右侧留出一定距离，开始一条注释，该注释一直延续到行尾。这是一种简单的方法，可以在规范中同时包含有用的注释。
implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or
默示*LWS本规范描述的语法是基于单词的。除非另有说明，否则线性空白（LWS）可以包括在任意两个相邻单词（标记或带引号的字符串）之间，以及相邻单词和分隔符之间，而不改变字段的解释。至少一个分隔符（LWS和/或
separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token.
分隔符）必须存在于任意两个令牌之间（对于下面的“令牌”定义），因为它们将被解释为单个令牌。
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].
本规范中使用以下规则来描述基本的解析构造。US-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)>
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)>
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 header field values 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. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
如果延续行以空格或水平制表符开头，HTTP/1.1标头字段值可以折叠到多行。所有线性空白（包括折叠）与SP具有相同的语义。在解释字段值或向下游转发消息之前，收件人可以用单个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 2047 [14].
文本规则仅用于描述性字段内容和值，这些内容和值不打算由消息解析器解释。只有在根据RFC 2047[14]的规则进行编码时，*文本的字才能包含ISO-8859-1[22]以外的字符集中的字符。
TEXT = <any OCTET except CTLs,
but including LWS>
TEXT = <any OCTET except CTLs,
but including LWS>
A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT value.
在文本定义中，CRLF仅允许作为标题字段延续的一部分。预计在解释文本值之前，折叠LWS将替换为单个SP。
Hexadecimal numeric characters are used in several protocol elements.
在几个协议元素中使用十六进制数字字符。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
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 (as defined in section 3.6).
许多HTTP/1.1头字段值由LWS或特殊字符分隔的单词组成。这些特殊字符必须位于带引号的字符串中，以便在参数值中使用（如第3.6节所定义）。
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
token = 1*<any CHAR except CTLs or separators>
separators = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | 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 | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
comment = "(" *( ctext | quoted-pair | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
A string of text is parsed as a single word if it is quoted using double-quote marks.
如果使用双引号将文本字符串引用，则将其解析为单个单词。
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
quoted-string = ( <"> *(qdtext | quoted-pair ) <"> )
qdtext = <any TEXT except <">>
The backslash character ("\") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs.
反斜杠字符（\）只能在带引号的字符串和注释结构中用作单字符引用机制。
quoted-pair = "\" CHAR
quoted pair=“\”字符
3 Protocol Parameters
3协议参数
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. See RFC 2145 [36] for a fuller explanation.
HTTP使用“<major><minor>”编号方案来指示协议的版本。协议版本控制策略旨在允许发送方指示消息的格式及其理解进一步HTTP通信的能力，而不是通过该通信获得的功能。添加不影响通信行为或仅添加可扩展字段值的消息组件时，不会更改版本号。当对协议所做的更改添加的功能不改变一般消息解析算法，但可能会增加消息语义并暗示发送方的附加功能时，<minor>数字会增加。当协议内的消息格式发生更改时，<major>编号将增加。请参阅RFC 2145[36]以获得更全面的解释。
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-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
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。收件人必须忽略前导零，并且不得发送前导零。
An application that sends a request or response message that includes HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant with this specification. Applications that are at least conditionally compliant with this specification SHOULD use an HTTP-Version of "HTTP/1.1" in their messages, and MUST do so for any message that is not compatible with HTTP/1.0. For more details on when to send specific HTTP-Version values, see RFC 2145 [36].
发送包含HTTP版本“HTTP/1.1”的请求或响应消息的应用程序必须至少有条件地符合此规范。至少有条件地符合此规范的应用程序应该在其消息中使用HTTP版本的“HTTP/1.1”，并且对于任何与HTTP/1.0不兼容的消息都必须这样做。有关何时发送特定HTTP版本值的更多详细信息，请参阅RFC 2145[36]。
The HTTP version of an application is the highest HTTP version for which the application is at least conditionally compliant.
应用程序的HTTP版本是应用程序至少符合条件的最高HTTP版本。
Proxy and gateway applications need to 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 NOT 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, or respond with an error, or switch to tunnel behavior.
当以不同于应用程序的协议版本转发消息时，代理和网关应用程序需要小心。由于协议版本指示发送方的协议能力，因此代理/网关发送的消息的版本指示器不得大于其实际版本。如果收到更高版本的请求，则代理/网关必须降级请求版本，或以错误响应，或切换到隧道行为。
Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of RFC 2068[33], caching proxies MUST, gateways MAY, and tunnels MUST NOT upgrade the request to the highest version they support. The proxy/gateway's response to that request MUST be in the same major version as the request.
由于自RFC 2068[33]发布以来发现的HTTP/1.0代理的互操作性问题，缓存代理必须、网关可能、隧道不得将请求升级到其支持的最高版本。代理/网关对该请求的响应必须与该请求的主版本相同。
Note: Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved.
注意：HTTP版本之间的转换可能涉及修改相关版本所需或禁止的标题字段。
URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers [3], and finally the combination of Uniform Resource Locators (URL) [4] and Names (URN) [20]. 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有许多名称：WWW地址、通用文档标识符、通用资源标识符[3]，最后是统一资源定位器（URL）[4]和名称（URN）[20]的组合。就HTTP而言，统一资源标识符只是格式化的字符串，通过名称、位置或任何其他特征来标识资源。
URIs in HTTP can be represented in absolute form or relative to some known base URI [11], 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. For definitive information on URL syntax and semantics, see "Uniform Resource Identifiers (URI): Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs 1738 [4] and RFC 1808 [11]). This specification adopts the definitions of "URI-reference", "absoluteURI", "relativeURI", "port", "host","abs_path", "rel_path", and "authority" from that specification.
HTTP中的URI可以以绝对形式表示，也可以相对于某些已知的基本URI来表示[11]，这取决于它们的使用上下文。这两种形式的区别在于，绝对URI始终以方案名称开头，后跟冒号。有关URL语法和语义的详细信息，请参阅“统一资源标识符（URI）：通用语法和语义”，RFC 2396[42]（它取代了RFC 1738[4]和RFC 1808[11]）。本规范采用该规范中“URI引用”、“绝对URI”、“相对URI”、“端口”、“主机”、“abs_路径”、“rel_路径”和“权限”的定义。
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的长度没有任何先验限制。服务器必须能够处理它们所服务的任何资源的URI，并且如果它们提供可以生成此类URI的基于GET的表单，则应该能够处理长度无限的URI。如果URI超过服务器可以处理的长度，则服务器应返回414（请求URI过长）状态（参见第10.4.15节）。
Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.
注意：服务器在依赖超过255字节的URI长度时应该谨慎，因为一些旧的客户端或代理实现可能无法正确支持这些长度。
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的特定于方案的语法和语义。
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
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 (section 5.1.2). The use of IP addresses in URLs 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). If a proxy receives a host name which is not a fully qualified domain name, it MAY add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy MUST NOT change the host name.
如果端口为空或未给定，则假定端口80。语义是，标识的资源位于侦听该主机端口上TCP连接的服务器上，资源的请求URI为abs_path（第5.1.2节）。尽可能避免在URL中使用IP地址（见RFC 1900[24]）。如果URL中不存在abs_路径，则在用作资源的请求URI时，必须将其指定为“/”（第5.1.2节）。如果代理收到的主机名不是完全限定的域名，它可以将其域添加到收到的主机名中。如果代理收到完全限定的域名，则代理不得更改主机名。
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:
在比较两个URI以确定它们是否匹配时，客户端应使用整个URI的区分大小写的八位字节比较，但以下例外情况除外：
- A port that is empty or not given is equivalent to the default port for that URI-reference;
- 空的或未给定的端口相当于该URI引用的默认端口；
- Comparisons of host names MUST be case-insensitive;
- 主机名的比较必须不区分大小写；
- Comparisons of scheme names MUST be case-insensitive;
- 方案名称的比较必须不区分大小写；
- An empty abs_path is equivalent to an abs_path of "/".
- 空的abs\u路径相当于“/”的abs\u路径。
Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
“保留”和“不安全”集合中的字符（参见RFC 2396[42]）以外的字符与其“%”十六进制编码等效。
For example, the following three URIs are equivalent:
例如，以下三个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
HTTP applications have historically allowed three different formats for the representation of date/time stamps:
HTTP应用程序历史上允许使用三种不同的格式来表示日期/时间戳：
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
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
The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [8] (an update to RFC 822 [9]). 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. See section 19.3 for further information.
首选第一种格式作为互联网标准，表示RFC 1123[8]（对RFC 822[9]的更新）定义的固定长度子集。第二种格式常用，但基于过时的RFC 850[12]日期格式，并且缺少四位数年份。解析日期值的HTTP/1.1客户端和服务器必须接受所有三种格式（与HTTP/1.0兼容），尽管它们必须仅生成RFC 1123格式，以在头字段中表示HTTP日期值。更多信息请参见第19.3节。
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. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated Universal Time). 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-date is case sensitive and MUST NOT include additional LWS beyond that specifically included as SP in the grammar.
所有HTTP日期/时间戳必须以格林威治标准时间（GMT）表示，无例外。就HTTP而言，GMT完全等于UTC（协调世界时）。在前两种格式中，包括“GMT”作为时区的三个字母缩写，这表明了这一点，并且在阅读asctime格式时必须假定这一点。HTTP date区分大小写，除语法中明确作为SP包含的LW外，不得包含其他LW。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
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
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)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
HTTP-date = rfc1123-date | rfc850-date | asctime-date
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
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)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
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要求仅适用于它们在协议流中的使用。客户端和服务器不需要将这些格式用于用户演示、请求日志记录等。
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
delta-seconds = 1*DIGIT
HTTP uses the same definition of the term "character set" as that described for MIME:
HTTP使用与MIME相同的术语“字符集”定义：
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 encoding, 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.
本文件中使用的术语“字符集”是指一种与一个或多个表一起使用的方法，用于将八位字节序列转换为字符序列。注意，不需要在另一个方向上进行无条件转换，因为在给定的字符集中并非所有字符都可用，并且一个字符集可以提供多个八位字节序列来表示特定字符。此定义旨在允许各种字符编码，从简单的单表映射（如US-ASCII）到复杂的表切换方法（如使用ISO-2022技术的方法）。但是，与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共享同一个注册表，因此术语也必须共享。
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 = token
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 [19] 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允许将任意令牌用作字符集值，但在IANA字符集注册表[19]中具有预定义值的任何令牌必须表示该注册表定义的字符集。应用程序应将其字符集的使用限制为IANA注册表定义的字符集。
Implementors should be aware of IETF character set requirements [38] [41].
实施者应了解IETF字符集要求[38][41]。
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软件将不带字符集参数的内容类型标头错误地解释为“收件人应猜测”。即使字符集为ISO-8859-1，希望阻止此行为的发件人也可能会包含字符集参数，并且在知道不会混淆收件人时应这样做。
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
不幸的是，一些较旧的HTTP/1.0客户端没有正确处理显式字符集参数。HTTP/1.1收件人必须尊重发件人提供的字符集标签；那些提供了“猜测”字符集的用户代理必须使用
content-type field if they support that charset, rather than the recipient's preference, when initially displaying a document. See section 3.7.1.
内容类型字段，如果它们在最初显示文档时支持该字符集，而不是收件人的首选项。见第3.7.1节。
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
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.11) 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在接受编码（第14.3节）和内容编码（第14.11节）头字段中使用内容编码值。尽管该值描述了内容编码，但更重要的是它指示了删除编码所需的解码机制。
The Internet Assigned Numbers Authority (IANA) acts as a registry for content-coding value tokens. Initially, the registry contains the following tokens:
Internet分配号码管理局（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文件压缩程序“gzip”（GNU zip）产生的编码格式，如RFC 1952[25]所述。这种格式是带有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文件压缩程序“compress”生成的编码格式。这种格式是一种自适应Lempel-Ziv-Welch编码（LZW）。
Use of program names for the identification of encoding formats is not desirable and is 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.
使用程序名来识别编码格式是不可取的，不鼓励在将来进行编码。它们在这里的使用是历史实践的代表，不是很好的设计。为了与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]中描述的“deflate”压缩机制，对RFC 1950[31]中定义的“zlib”格式进行放气。
identity The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.
标识默认（标识）编码；不使用任何转换。此内容编码仅在接受编码标头中使用，不应在内容编码标头中使用。
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.
应注册新的内容编码值令牌；为了实现客户端和服务器之间的互操作性，实现新值所需的内容编码算法规范应公开提供，并足以独立实现，并符合本节中定义的内容编码目的。
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
transfer-extension = token *( ";" parameter )
transfer-coding = "chunked" | transfer-extension
transfer-extension = token *( ";" parameter )
Parameters are in the form of attribute/value pairs.
参数采用属性/值对的形式。
parameter = attribute "=" value attribute = token value = token | quoted-string
参数=属性“=”值属性=令牌值=令牌|带引号的字符串
All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (section 14.39) and in the Transfer-Encoding header field (section 14.41).
所有传输编码值都不区分大小写。HTTP/1.1在TE头字段（第14.39节）和传输编码头字段（第14.41节）中使用传输编码值。
Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer-coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message (section 4.4).
每当向消息正文应用传输编码时，传输编码集必须包括“分块”，除非通过关闭连接终止消息。使用“分块”传输编码时，它必须是应用于消息正文的最后一个传输编码。“分块”传输编码不得多次应用于消息正文。这些规则允许收件人确定邮件的传输长度（第4.4节）。
Transfer-codings are analogous to the Content-Transfer-Encoding values of MIME [7], 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[7]的内容传输编码值，旨在通过7位传输服务实现二进制数据的安全传输。但是，对于8位干净传输协议，安全传输有不同的重点。在HTTP中，消息体的唯一不安全特征是难以确定确切的正文长度（第7.2.2节），或者希望通过共享传输加密数据。
The Internet Assigned Numbers Authority (IANA) acts as a registry for transfer-coding value tokens. Initially, the registry contains the following tokens: "chunked" (section 3.6.1), "identity" (section 3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate" (section 3.5).
Internet分配号码管理局（IANA）充当传输编码值令牌的注册表。最初，注册表包含以下标记：“chunked”（第3.6.1节）、“identity”（第3.6.2节）、“gzip”（第3.5节）、“compress”（第3.5节）和“deflate”（第3.5节）。
New transfer-coding value tokens SHOULD be registered in the same way as new content-coding value tokens (section 3.5).
新的传输编码值令牌应以与新内容编码值令牌相同的方式注册（第3.5节）。
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.
如果服务器接收到一个实体体，但该实体体的传输编码不清楚，则该服务器应返回501（未实现），并关闭连接。服务器不得向HTTP/1.0客户端发送传输编码。
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 trailer 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-Body = *chunk
last-chunk
trailer
CRLF
Chunked-Body = *chunk
last-chunk
trailer
CRLF
chunk = chunk-size [ chunk-extension ] CRLF chunk-data CRLF chunk-size = 1*HEX last-chunk = 1*("0") [ chunk-extension ] CRLF
chunk=chunk size[chunk extension]CRLF chunk data CRLF chunk size=1*十六进制最后一个chunk=1*（“0”）[chunk extension]CRLF
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
chunk-ext-name = token
chunk-ext-val = token | quoted-string
chunk-data = chunk-size(OCTET)
trailer = *(entity-header CRLF)
The chunk-size field is a string of hex digits indicating the size of the chunk. The chunked encoding is ended by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
块大小字段是一个十六进制数字字符串，指示块的大小。分块编码由大小为零的任何分块结束，后跟尾段，尾段以空行结束。
The trailer allows the sender to include additional HTTP header fields at the end of the message. The Trailer header field can be used to indicate which header fields are included in a trailer (see section 14.40).
尾部允许发送方在消息末尾包含额外的HTTP头字段。拖车标题字段可用于指示拖车中包括哪些标题字段（见第14.40节）。
A server using chunked transfer-coding in a response MUST NOT use the trailer for any header fields unless at least one of the following is true:
在响应中使用分块传输编码的服务器不得将尾部用于任何标头字段，除非至少满足以下条件之一：
a)the request included a TE header field that indicates "trailers" is acceptable in the transfer-coding of the response, as described in section 14.39; or,
a） 请求包括一个TE报头字段，该字段指示响应的传输编码中可接受“拖车”，如第14.39节所述；或
b)the server is the origin server for the response, the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable to the origin server) without receiving this metadata. In other words, the origin server is willing to accept the possibility that the trailer fields might be silently discarded along the path to the client.
b） 服务器是响应的源服务器，尾部字段完全由可选元数据组成，收件人可以在不接收此元数据的情况下使用消息（以源服务器可接受的方式）。换句话说，源服务器愿意接受这样一种可能性，即拖车字段可能会沿着到客户机的路径被悄悄地丢弃。
This requirement prevents an interoperability failure when the message is being received by an HTTP/1.1 (or later) proxy and forwarded to an HTTP/1.0 recipient. It avoids a situation where compliance with the protocol would have necessitated a possibly infinite buffer on the proxy.
当HTTP/1.1（或更高版本）代理接收消息并将其转发给HTTP/1.0收件人时，此要求可防止互操作性故障。它避免了遵守协议可能需要在代理上使用无限缓冲区的情况。
An example process for decoding a Chunked-Body is presented in appendix 19.4.6.
附录19.4.6中给出了解码块体的示例过程。
All HTTP/1.1 applications MUST be able to receive and decode the "chunked" transfer-coding, and MUST ignore chunk-extension extensions they do not understand.
所有HTTP/1.1应用程序必须能够接收和解码“分块”传输编码，并且必须忽略它们不理解的分块扩展。
HTTP uses Internet Media Types [17] in the Content-Type (section 14.17) and Accept (section 14.1) header fields in order to provide open and extensible data typing and type negotiation.
HTTP在内容类型（第14.17节）和接受（第14.1节）头字段中使用Internet媒体类型[17]，以便提供开放和可扩展的数据类型和类型协商。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Parameters MAY follow the type/subtype in the form of attribute/value pairs (as defined in section 3.6).
参数可以以属性/值对的形式跟随类型/子类型（如第3.6节所定义）。
The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might 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. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.
类型、子类型和参数属性名称不区分大小写。参数值可能区分大小写，也可能不区分大小写，具体取决于参数名称的语义。线性空白（LWS）不能用于类型和子类型之间，也不能用于属性及其值之间。参数的存在或不存在对媒体类型的处理可能很重要，这取决于媒体类型注册表中的定义。
Note that 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 [19]). The media type registration process is outlined in RFC 1590 [17]. Use of non-registered media types is discouraged.
媒体类型值在互联网分配号码管理局（IANA[19]）注册。RFC 1590[17]中概述了媒体类型注册过程。不鼓励使用未注册的媒体类型。
Internet media types are registered with a canonical form. An entity-body transferred via HTTP messages MUST be represented in the appropriate canonical form prior to its transmission except for "text" types, as defined in the next paragraph.
Internet媒体类型以规范形式注册。通过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作为文本换行符。HTTP放宽了这一要求，并允许传输纯CR或LF单独表示换行符的文本媒体，前提是对整个实体一致地进行传输。HTTP应用程序必须接受CRLF、bare CR和bare LF作为通过HTTP接收的文本媒体中的换行符的代表。此外，如果文本在字符集中表示，并且不像某些多字节字符集那样，CR和LF分别使用八位字节13和10，HTTP允许使用该字符集定义的任何八位字节序列来表示换行符的CR和LF的等效值。关于换行符的这种灵活性仅适用于实体体中的文本媒体；在任何HTTP控制结构（例如头字段和多部分边界）中，不能用裸CR或LF替换CRLF。
If an entity-body is encoded with a content-coding, the underlying data MUST be in a form defined above prior to being encoded.
如果使用内容编码对实体体进行编码，则在编码之前，基础数据必须采用上面定义的格式。
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. See section 3.4.1 for compatibility problems.
“字符集”参数与某些媒体类型一起使用，以定义数据的字符集（第3.4节）。当发送方未提供显式字符集参数时，“文本”类型的媒体子类型被定义为在通过HTTP接收时具有默认字符集值“ISO-8859-1”。除“ISO-8859-1”或其子集以外的字符集中的数据必须使用适当的字符集值进行标记。有关兼容性问题，请参见第3.4.1节。
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 section 5.1.1 of RFC 2046
MIME提供了许多“多部分”类型——在单个消息体中封装一个或多个实体。如RFC 2046第5.1.1节所定义，所有多部分类型共享一个通用语法
[40], 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 RFC 2046, the epilogue of any multipart message MUST be empty; HTTP applications MUST NOT transmit the epilogue (even if the original multipart contains an epilogue). These restrictions exist in order to preserve the self-delimiting nature of a multipart message-body, wherein the "end" of the message-body is indicated by the ending multipart boundary.
[40]，并且必须包括边界参数作为介质类型值的一部分。消息正文本身是一个协议元素，因此必须仅使用CRLF来表示正文部分之间的换行符。与RFC 2046不同，任何多部分消息的尾声必须为空；HTTP应用程序不得传输尾声（即使原始多部分包含尾声）。存在这些限制是为了保持多部分消息体的自定界性质，其中消息体的“结束”由结束的多部分边界表示。
In general, HTTP treats a multipart message-body no differently than any other media type: strictly as payload. The one exception is the "multipart/byteranges" type (appendix 19.2) when it appears in a 206 (Partial Content) response, which will be interpreted by some HTTP caching mechanisms as described in sections 13.5.4 and 14.16. In all other cases, an HTTP user agent SHOULD follow the same or similar behavior as a MIME user agent would upon receipt of a multipart type. The MIME header fields within each body-part of a multipart message-body do not have any significance to HTTP beyond that defined by their MIME semantics.
一般来说，HTTP对待多部分消息体与任何其他媒体类型没有什么不同：严格地说是有效负载。一个例外是“multipart/byteranges”类型（附录19.2），当它出现在206（部分内容）响应中时，它将由第13.5.4和14.16节中描述的一些HTTP缓存机制来解释。在所有其他情况下，HTTP用户代理应遵循与MIME用户代理在收到多部分类型时相同或类似的行为。多部分消息正文的每个正文部分中的MIME头字段对HTTP的意义不超过其MIME语义定义的意义。
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用户代理应该遵循与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].
注：如RFC 1867[15]所述，“多部分/表格数据”类型已专门定义，用于携带适合通过请求后方法处理的表格数据。
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 white space. 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
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Server: Apache/0.8.4
Product tokens SHOULD be short and to the point. They MUST NOT be used for advertising or other non-essential information. 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).
产品代币应简明扼要。不得将其用于广告或其他非必要信息。尽管产品版本中可能出现任何标记字符，但该标记应仅用于版本标识符（即，同一产品的后续版本应仅在产品值的产品版本部分有所不同）。
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. If a parameter has a quality value of 0, then content with this parameter is `not acceptable' for the client. 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为最大值。如果参数的质量值为0，则此参数的内容对于客户端来说是“不可接受的”。HTTP/1.1应用程序在小数点后生成的数字不得超过三位。这些值的用户配置也应以这种方式进行限制。
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.
“质量值”用词不当，因为这些值仅代表所需质量的相对降低。
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在接受语言和内容语言字段中使用语言标记。
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]定义的相同。总之，语言标记由一个或多个部分组成：主语言标记和一系列可能为空的子标记：
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
White space 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
恩，恩美国，恩伦敦，我切诺基，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.)
其中任何两个字母的主标记是ISO-639语言缩写，任何两个字母的首字母子标记是ISO-3166国家代码。（上面最后三个标签不是已注册的标签；除了最后一个以外，所有标签都是将来可以注册的标签示例。）
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.19), If-Match (section 14.24), 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.
实体标记用于比较来自同一请求资源的两个或多个实体。HTTP/1.1在ETag（第14.19节）、If Match（第14.24节）、If None Match（第14.26节）和If Range（第14.27节）头字段中使用实体标记。第13.3.3节定义了如何将它们作为缓存验证器使用和比较。实体标记由不透明的带引号的字符串组成，可能以弱点指示符作为前缀。
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
entity-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
A "strong entity tag" MAY be shared by two entities of a resource only if they are equivalent by octet equality.
一个资源的两个实体只有在八位字节相等的情况下才能共享“强实体标记”。
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.
由“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. The use of the same entity tag value in conjunction with entities obtained by requests on different URIs does not imply the equivalence of those entities.
实体标记在与特定资源关联的所有实体的所有版本中必须是唯一的。给定的实体标记值可用于通过不同URI上的请求获得的实体。将相同的实体标记值与通过不同URI上的请求获得的实体结合使用并不意味着这些实体的等价性。
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.35) and Content-Range (section 14.16) header fields. An entity can be broken down into subranges according to various structural units.
HTTP/1.1允许客户端请求在响应中只包含响应实体的一部分（一个范围）。HTTP/1.1在范围（第14.35节）和内容范围（第14.16节）头字段中使用范围单位。实体可以根据不同的结构单元分解为子范围。
range-unit = bytes-unit | other-range-unit bytes-unit = "bytes" other-range-unit = token
范围单位=字节单位|其他范围单位bytes unit=“bytes”其他范围单位=令牌
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定义的唯一范围单位是“字节”。HTTP/1.1实现可能会忽略使用其他单位指定的范围。
HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges.
HTTP/1.1的设计允许实现不依赖于范围知识的应用程序。
4 HTTP Message
4 HTTP消息
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-message = Request | Response ; HTTP/1.1 messages
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, zero 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 possibly a message-body.
请求（第5节）和响应（第6节）消息使用RFC 822[9]的通用消息格式传输实体（消息的有效负载）。这两种类型的消息都由起始行、零个或多个标题字段（也称为“标题”）、指示标题字段结尾的空行（即CRLF前面没有任何内容的行）以及可能的消息正文组成。
generic-message = start-line *(message-header CRLF) CRLF [ message-body ] start-line = Request-Line | Status-Line
通用消息=起始行*（消息头CRLF）CRLF[消息正文]起始行=请求行|状态行
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.
出于健壮性的考虑，服务器应该忽略在预期请求行的位置接收到的任何空行。换句话说，如果服务器在消息开头读取协议流并首先接收到CRLF，则应忽略CRLF。
Certain buggy HTTP/1.0 client implementations generate 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客户端实现会在POST请求后生成额外的CRLF。为了重申BNF明确禁止的内容，HTTP/1.1客户端不得在请求之前或之后添加额外的CRLF。
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 ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything
HTTP标头字段，包括通用标头（第4.5节）、请求标头（第5.3节）、响应标头（第6.2节）和实体标头（第7.1节）字段，遵循RFC 822[9]第3.1节中给出的通用格式。每个标题字段由一个名称，后跟一个冒号（“：”）和字段值组成。字段名不区分大小写。字段值前面可以有任意数量的LW，但最好是单个SP。通过在每一额外行之前至少添加一个SP或HT，可以将标题字段扩展到多行。应用程序在生成HTTP构造时应该遵循“公共形式”，即已知或指示的形式，因为可能存在一些无法接受任何内容的实现
beyond the common forms.
超越普通形式。
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
message-header = field-name ":" [ field-value ]
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, separators, and quoted-string>
The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS MAY be removed without changing the semantics of the field value. Any LWS that occurs between field-content MAY be replaced with a single SP before interpreting the field value or forwarding the message downstream.
字段内容不包括字段值的第一个非空白字符之前或字段值的最后一个非空白字符之后出现的任何前导或尾随LWS：线性空白。在不改变字段值的语义的情况下，可以删除此类前导或尾随LW。在解释字段值或向下游转发消息之前，字段内容之间发生的任何LW都可以用单个SP替换。
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.
当且仅当消息头字段的整个字段值定义为逗号分隔列表[即#（值）]时，消息中可能存在具有相同字段名的多个消息头字段。必须能够将多个标题字段合并为一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。因此，具有相同字段名的标题字段的接收顺序对于组合字段值的解释非常重要，因此，在转发消息时，代理不得更改这些字段值的顺序。
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.41).
HTTP消息的消息体（如果有）用于承载与请求或响应关联的实体体。如传输编码标题字段（第14.41节）所示，仅当传输编码已应用时，消息正文与实体正文不同。
message-body = entity-body | <entity-body encoded as per Transfer-Encoding>
消息正文=实体正文|<按照传输编码编码的实体正文>
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 MAY be added or removed by any application along the request/response chain. (However, section 3.6 places restrictions on when certain transfer-codings may be used.)
实体，因此可以由请求/响应链上的任何应用程序添加或删除。（但是，第3.6节对何时可以使用某些转移编码进行了限制。）
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 MUST NOT be included in a request if the specification of the request method (section 5.1.1) does not allow sending an entity-body in requests. A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request.
通过在请求的消息头中包含内容长度或传输编码头字段来表示请求中存在消息体。如果请求方法规范（第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（未修改）响应不得包含消息正文。所有其他响应都包含一个消息体，尽管它的长度可能为零。
The transfer-length of a message is the length of the message-body as it appears in the message; that is, after any transfer-codings have been applied. When a message-body is included with a message, the transfer-length of that body is determined by one of the following (in order of precedence):
消息的传输长度是消息正文在消息中显示的长度；也就是说，在应用任何转移编码之后。当消息正文包含在消息中时，该正文的传输长度由以下内容之一决定（按优先顺序排列）：
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.任何“不得”包含消息正文的响应消息（如1x、204和304响应以及对头请求的任何响应）始终由头字段后的第一个空行终止，而不管消息中存在的实体头字段。
2.If a Transfer-Encoding header field (section 14.41) is present and has any value other than "identity", then the transfer-length is defined by use of the "chunked" transfer-coding (section 3.6), unless the message is terminated by closing the connection.
2.如果存在传输编码头字段（第14.41节），且该字段具有除“标识”以外的任何值，则通过使用“分块”传输编码（第3.6节）定义传输长度，除非通过关闭连接终止消息。
3.If a Content-Length header field (section 14.13) is present, its decimal value in OCTETs represents both the entity-length and the transfer-length. The Content-Length header field MUST NOT be sent if these two lengths are different (i.e., if a Transfer-Encoding
3.如果存在内容长度标题字段（第14.13节），则其十进制值（八位字节）表示实体长度和传输长度。如果这两个长度不同（即，如果传输编码不同），则不得发送内容长度标头字段
header field is present). If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.
标题字段不存在）。如果接收到的消息同时包含传输编码头字段和内容长度头字段，则必须忽略后者。
4.If the message uses the media type "multipart/byteranges", and the ransfer-length is not otherwise specified, then this self-elimiting media type defines the transfer-length. This media type UST NOT be used unless the sender knows that the recipient can arse it; the presence in a request of a Range header with ultiple byte-range specifiers from a 1.1 client implies that the lient can parse multipart/byteranges responses.
4.如果消息使用媒体类型“multipart/byteranges”，并且没有另外指定传输长度，则此自消除媒体类型定义传输长度。除非发件人知道收件人可以使用此媒体类型，否则不得使用此媒体类型；来自1.1客户端的带有多字节范围说明符的范围标头请求中的存在意味着客户端可以解析多部分/字节范围响应。
A range header might be forwarded by a 1.0 proxy that does not understand multipart/byteranges; in this case the server MUST delimit the message using methods defined in items 1,3 or 5 of this section.
范围标头可能由不理解多部分/byteranges的1.0代理转发；在这种情况下，服务器必须使用本节第1、3或5项中定义的方法对消息进行分隔。
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。如果请求包含消息正文且未给出内容长度，则服务器应在无法确定消息长度时以400（错误请求）响应，或在希望坚持接收有效内容长度时以411（所需长度）响应。
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应用程序都必须接受“分块”传输编码（第3.6节），从而允许在无法事先确定消息长度时将此机制用于消息。
Messages MUST NOT include both a Content-Length header field and a non-identity transfer-coding. If the message does include a non-identity transfer-coding, the Content-Length MUST be ignored.
消息不得同时包含内容长度标题字段和非身份传输编码。如果消息确实包含非身份传输编码，则必须忽略内容长度。
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.
在允许消息正文的消息中给定内容长度时，其字段值必须与消息正文中的八位字节数完全匹配。HTTP/1.1用户代理必须在收到并检测到无效长度时通知用户。
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.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
general-header = Cache-Control ; Section 14.9
| Connection ; Section 14.10
| Date ; Section 14.18
| Pragma ; Section 14.32
| Trailer ; Section 14.40
| Transfer-Encoding ; Section 14.41
| Upgrade ; Section 14.42
| Via ; Section 14.45
| Warning ; Section 14.46
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 ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
Request = Request-Line ; Section 5.1
*(( general-header ; Section 4.5
| request-header ; Section 5.3
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 4.3
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 is allowed except in the final CRLF sequence.
请求行以方法令牌开始，然后是请求URI和协议版本，最后是CRLF。元素由SP字符分隔。除最终CRLF序列外，不允许使用CR或LF。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
请求行=方法SP请求URI SP HTTP版本CRLF
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
Method令牌表示要对请求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
| "CONNECT" ; Section 9.9
| extension-method
extension-method = token
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
| "CONNECT" ; Section 9.9
| extension-method
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. An origin server SHOULD return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested resource, and 501 (Not Implemented) if the method is unrecognized or not implemented by the origin server. 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.
资源允许的方法列表可以在允许标头字段中指定（第14.7节）。响应的返回代码总是通知客户机当前是否允许在资源上使用某个方法，因为允许的方法集可以动态更改。如果源服务器知道该方法但请求的资源不允许该方法，则源服务器应返回状态代码405（不允许该方法）；如果源服务器无法识别或未实现该方法，则返回状态代码501（未实现）。GET和HEAD方法必须得到所有通用服务器的支持。所有其他方法都是可选的；但是，如果实现了上述方法，则必须使用第9节中指定的相同语义来实现它们。
The Request-URI is a Uniform Resource Identifier (section 3.2) and identifies the resource upon which to apply the request.
请求URI是一个统一的资源标识符（第3.2节），用于标识应用请求的资源。
Request-URI = "*" | absoluteURI | abs_path | authority
请求URI=“*”|绝对URI |绝对路径|权限
The four 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
请求URI的四个选项取决于请求的性质。星号“*”表示请求不适用于特定资源，而适用于服务器本身，并且仅当所使用的方法不一定适用于资源时才允许。一个例子是
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 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
当向代理发出请求时，需要绝对URI表单。请求代理从有效缓存转发请求或为其提供服务，并返回响应。请注意，代理可以将请求转发到另一个代理或直接转发到服务器
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:
由绝对URI指定。为了避免请求循环，代理必须能够识别其所有服务器名称，包括任何别名、本地变体和数字IP地址。一个示例请求行是：
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
GET 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版本中的所有请求中转换为absoluteURI，所有HTTP/1.1服务器都必须在请求中接受absoluteURI格式，即使HTTP/1.1客户端只在对代理的请求中生成它们。
The authority form is only used by the CONNECT method (section 9.9).
授权表格仅用于连接方法（第9.9节）。
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 (authority) 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:
请求URI最常见的形式是用于标识源服务器或网关上的资源。在这种情况下，必须将URI的绝对路径（见第3.2.1节，abs_路径）作为请求URI传输，并且必须在主机头字段中传输URI（授权）的网络位置。例如，希望直接从源服务器检索上述资源的客户端将创建到主机“www.w3.org”端口80的TCP连接，并发送以下行：
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
GET /pub/WWW/TheProject.html HTTP/1.1
Host: 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).
然后是请求的其余部分。请注意，绝对路径不能为空；如果原始URI中不存在，则必须将其指定为“/”（服务器根目录）。
The Request-URI is transmitted in the format specified in section 3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding [42], 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.
请求URI以第3.2.1节规定的格式传输。如果请求URI使用“%HEX-HEX”编码[42]进行编码，则源服务器必须解码请求URI以正确解释请求。服务器应使用适当的状态代码响应无效的请求URI。
A transparent proxy MUST NOT rewrite the "abs_path" part of the received Request-URI when forwarding it to the next inbound server, except as noted above to replace a null abs_path with "/".
透明代理在将接收到的请求URI转发到下一个入站服务器时，不得重写其“abs_路径”部分，除非如上所述将空abs_路径替换为“/”。
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 URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been known to rewrite the Request-URI.
注意：“不重写”规则防止当源服务器为保留目的不正确地使用非保留URI字符时，代理更改请求的含义。实现者应该知道，已经知道一些HTTP/1.1之前的代理重写了请求URI。
The exact resource identified by an Internet request is determined by examining both the Request-URI and the Host header field.
通过检查请求URI和主机头字段来确定由Internet请求标识的确切资源。
An origin server that does not allow resources to differ by the requested host MAY ignore the Host header field value when determining the resource identified by an HTTP/1.1 request. (But see section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
当确定HTTP/1.1请求标识的资源时，不允许资源因请求的主机而异的源服务器可能会忽略主机头字段值。（有关HTTP/1.1中主机支持的其他要求，请参见第19.6.1.1节。）
An origin server that does differentiate resources based on the host requested (sometimes referred to as virtual hosts or vanity host names) 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. 如果请求URI是绝对URI，则主机是请求URI的一部分。必须忽略请求中的任何主机标头字段值。
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. 如果请求URI不是绝对URI，并且请求包含主机头字段，则主机由主机头字段值确定。
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（错误请求）错误消息。
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.
缺少主机头字段的HTTP/1.0请求的接收者可能会尝试使用试探法（例如，检查URI路径以查找特定主机特有的内容），以确定请求的确切资源。
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 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
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
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
| Expect ; Section 14.20
| From ; Section 14.22
| Host ; Section 14.23
| If-Match ; Section 14.24
| If-Modified-Since ; 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.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
| If-Modified-Since ; 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.35
| Referer ; Section 14.36
| TE ; Section 14.39
| User-Agent ; Section 14.43
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 ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
Response = Status-Line ; Section 6.1
*(( general-header ; Section 4.5
| response-header ; Section 6.2
| entity-header ) CRLF) ; Section 7.1
CRLF
[ message-body ] ; Section 7.2
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.
响应消息的第一行是状态行，由协议版本、数字状态代码及其关联的文本短语组成，每个元素由SP字符分隔。除最终CRLF序列外，不允许使用CR或LF。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状态行=HTTP版本SP状态代码SP原因短语CRLF
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.
状态代码元素是试图理解和满足请求的3位整数结果代码。这些代码在第10节中有完整的定义。原因短语旨在对状态代码进行简短的文本描述。状态代码供自动机使用，原因短语供人类用户使用。客户端不需要检查或显示原因短语。
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:
状态代码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。第一个数字有5个值：
- 1xx: Informational - Request received, continuing process
- 1xx：信息性-收到请求，继续处理
- 2xx: Success - The action was successfully received, understood, and accepted
- 2xx：成功-成功接收、理解和接受行动
- 3xx: Redirection - Further action must be taken in order to complete the request
- 3xx：重定向-必须采取进一步的操作才能完成请求
- 4xx: Client Error - The request contains bad syntax or cannot be fulfilled
- 4xx:客户端错误-请求包含错误语法或无法实现
- 5xx: Server Error - The server failed to fulfill an apparently valid request
- 5xx:服务器错误-服务器未能完成明显有效的请求
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 recommendations -- they MAY be replaced by local equivalents without affecting the protocol.
下面给出了为HTTP/1.1定义的数字状态代码的各个值以及相应原因短语的示例集。这里列出的原因短语只是建议——它们可以被本地等价物替换，而不会影响协议。
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
Status-Code =
"100" ; Section 10.1.1: Continue
| "101" ; Section 10.1.2: Switching Protocols
| "200" ; Section 10.2.1: OK
| "201" ; Section 10.2.2: Created
| "202" ; Section 10.2.3: Accepted
| "203" ; Section 10.2.4: Non-Authoritative Information
| "204" ; Section 10.2.5: No Content
| "205" ; Section 10.2.6: Reset Content
| "206" ; Section 10.2.7: Partial Content
| "300" ; Section 10.3.1: Multiple Choices
| "301" ; Section 10.3.2: Moved Permanently
| "302" ; Section 10.3.3: Found
| "303" ; Section 10.3.4: See Other
| "304" ; Section 10.3.5: Not Modified
| "305" ; Section 10.3.6: Use Proxy
| "307" ; Section 10.3.8: Temporary Redirect
| "400" ; Section 10.4.1: Bad Request
| "401" ; Section 10.4.2: Unauthorized
| "402" ; Section 10.4.3: Payment Required
| "403" ; Section 10.4.4: Forbidden
| "404" ; Section 10.4.5: Not Found
| "405" ; Section 10.4.6: Method Not Allowed
| "406" ; Section 10.4.7: Not Acceptable
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
| "407" ; Section 10.4.8: Proxy Authentication Required
| "408" ; Section 10.4.9: Request Time-out
| "409" ; Section 10.4.10: Conflict
| "410" ; Section 10.4.11: Gone
| "411" ; Section 10.4.12: Length Required
| "412" ; Section 10.4.13: Precondition Failed
| "413" ; Section 10.4.14: Request Entity Too Large
| "414" ; Section 10.4.15: Request-URI Too Large
| "415" ; Section 10.4.16: Unsupported Media Type
| "416" ; Section 10.4.17: Requested range not satisfiable
| "417" ; Section 10.4.18: Expectation Failed
| "500" ; Section 10.5.1: Internal Server Error
| "501" ; Section 10.5.2: Not Implemented
| "502" ; Section 10.5.3: Bad Gateway
| "503" ; Section 10.5.4: Service Unavailable
| "504" ; Section 10.5.5: Gateway Time-out
| "505" ; Section 10.5.6: HTTP Version not supported
| extension-code
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
extension-code = 3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
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状态代码。在这种情况下，用户代理应向用户提供随响应返回的实体，因为该实体可能包括解释异常状态的人类可读信息。
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.
响应头字段允许服务器传递有关响应的附加信息，这些信息不能放在状态行中。这些头字段提供有关服务器的信息，以及关于进一步访问由请求URI标识的资源的信息。
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
response-header = Accept-Ranges ; Section 14.5
| Age ; Section 14.6
| ETag ; Section 14.19
| Location ; Section 14.30
| Proxy-Authenticate ; Section 14.33
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47
| Retry-After ; Section 14.37
| Server ; Section 14.38
| Vary ; Section 14.44
| WWW-Authenticate ; Section 14.47
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.
如果不受请求方法或响应状态代码的限制，请求和响应消息可以传输实体。实体由实体标题字段和实体正文组成，尽管有些响应将只包括实体标题。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
在本节中，发送方和接收方都指客户机或服务器，具体取决于谁发送和谁接收实体。
Entity-header fields define metainformation about the entity-body or, if no body is present, about the resource identified by the request. Some of this metainformation is OPTIONAL; some might be REQUIRED by portions of this specification.
实体头字段定义关于实体主体的元信息，或者，如果没有主体，则定义关于请求标识的资源的元信息。有些元信息是可选的；本规范的某些部分可能需要一些。
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
entity-header = Allow ; Section 14.7
| Content-Encoding ; Section 14.11
| Content-Language ; Section 14.12
| Content-Length ; Section 14.13
| Content-Location ; Section 14.14
| Content-MD5 ; Section 14.15
| Content-Range ; Section 14.16
| Content-Type ; Section 14.17
| Expires ; Section 14.21
| Last-Modified ; Section 14.29
| extension-header
extension-header = message-header
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 MUST be forwarded by transparent proxies.
扩展头机制允许在不更改协议的情况下定义其他实体头字段，但不能假定收件人可以识别这些字段。收件人应忽略无法识别的标头字段，并且必须由透明代理转发。
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
entity-body = *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 might have been applied to ensure safe and proper transfer of the message.
如第4.3节所述，只有当存在消息正文时，实体正文才会出现在消息中。实体体是通过解码可能已应用的任何传输编码从消息体获得的，以确保消息的安全和正确传输。
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 type和Content Encoding确定。这些定义了两层有序编码模型：
entity-body := Content-Encoding( Content-Type( data ) )
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.
内容类型指定基础数据的媒体类型。内容编码可用于指示应用于数据的任何附加内容编码，通常用于数据压缩，这是所请求资源的属性。没有默认编码。
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 URI used to identify the resource. If the media type remains unknown, the recipient SHOULD treat it as type "application/octet-stream".
任何包含实体主体的HTTP/1.1消息都应该包含一个内容类型头字段，该字段定义该主体的媒体类型。如果且仅当内容类型字段未给出媒体类型时，接收方可通过检查其内容和/或用于标识资源的URI的名称扩展来尝试猜测媒体类型。如果媒体类型未知，收件人应将其视为类型“应用程序/八位字节流”。
The entity-length of a message is the length of the message-body before any transfer-codings have been applied. Section 4.4 defines how the transfer-length of a message-body is determined.
消息的实体长度是应用任何传输编码之前消息正文的长度。第4.4节定义了如何确定消息正文的传输长度。
8 Connections
8连接
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 require a client to make multiple requests of the same server in a short amount of time. Analysis of these performance problems and results from a prototype implementation are available [26] [30]. Implementation experience and measurements of actual HTTP/1.1 (RFC 2068) implementations show good results [39]. Alternatives have also been explored, for example, T/TCP [27].
在持久连接之前，会建立一个单独的TCP连接来获取每个URL，这会增加HTTP服务器上的负载，并导致Internet上的拥塞。内联图像和其他相关数据的使用通常要求客户端在短时间内对同一服务器发出多个请求。这些性能问题的分析和原型实现的结果可供参考[26][30]。实际HTTP/1.1（RFC 2068）实现的实现经验和测量结果显示了良好的结果[39]。还探索了替代方案，例如T/TCP[27]。
Persistent HTTP connections have a number of advantages:
持久HTTP连接有许多优点：
- By opening and closing fewer TCP connections, CPU time is saved in routers and hosts (clients, servers, proxies, gateways, tunnels, or caches), and memory used for TCP protocol control blocks can be saved in hosts.
- 通过打开和关闭较少的TCP连接，路由器和主机（客户端、服务器、代理、网关、隧道或缓存）中节省了CPU时间，用于TCP协议控制块的内存可以保存在主机中。
- 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.
- HTTP请求和响应可以在连接上通过管道传输。管道允许客户端在不等待每个响应的情况下发出多个请求，从而使单个TCP连接的使用效率更高，所用时间更短。
- 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.
- 通过减少TCP打开导致的数据包数量，并允许TCP有足够的时间确定网络的拥塞状态，可以减少网络拥塞。
- Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.
- Latency on subsequent requests is reduced since there is no time spent in TCP's connection opening handshake.translate error, please retry
- 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.
- HTTP可以更加优雅地发展，因为可以报告错误而不必关闭TCP连接。使用HTTP未来版本的客户端可能会乐观地尝试新功能，但如果与旧服务器通信，请在报告错误后使用旧语义重试。
HTTP implementations SHOULD implement persistent connections.
HTTP实现应该实现持久连接。
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 SHOULD assume that the server will maintain a persistent connection, even after error responses from the server.
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 (section 14.10). Once a close has been signaled, the client MUST NOT send any more requests on that connection.
持久连接提供了一种机制，通过该机制，客户端和服务器可以发出关闭TCP连接的信号。该信令使用连接头字段（第14.10节）进行。一旦发出关闭信号，客户端就不能在该连接上再发送任何请求。
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服务器可能假设HTTP/1.1客户端打算维护持久连接，除非在请求中发送了包含连接令牌“close”的连接头。如果服务器选择在发送响应后立即关闭连接，则应发送一个包含连接令牌close的连接头。
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客户机可能希望连接保持打开状态，但会根据服务器的响应是否包含连接头以及连接令牌是否关闭来决定是否保持连接打开。如果客户机不想维护超过该请求的连接，它应该发送一个连接头，包括连接令牌close。
If either the client or the server sends the close token in the Connection header, that request becomes the last one for the 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.6.2 for more information on backward compatibility with HTTP/1.0 clients.
客户端和服务器不应假定为低于1.1的HTTP版本维护持久连接，除非显式地发出信号。有关与HTTP/1.0客户端向后兼容的更多信息，请参见第19.6.2节。
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节所述，为了保持持久性，连接上的所有消息必须具有自定义的消息长度（即，未通过关闭连接来定义的消息长度）。
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.
支持持久连接的客户机可以“管道化”其请求（即，在不等待每个响应的情况下发送多个请求）。服务器必须按照接收请求的相同顺序发送对这些请求的响应。
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.
如果第一次管道连接尝试失败，则在连接建立后立即采用持久连接和管道连接的客户端应准备重试其连接。如果客户机进行了这样的重试，则在知道连接是持久的之前，它不能进行管道传输。如果服务器在发送所有相应响应之前关闭了连接，则客户端还必须准备好重新发送其请求。
Clients SHOULD NOT pipeline requests using non-idempotent methods or non-idempotent sequences of methods (see section 9.1.2). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to send a non-idempotent request SHOULD wait to send that request until it has received the response status for the previous request.
客户端不应使用非幂等方法或非幂等方法序列来处理请求（参见第9.1.2节）。否则，过早终止传输连接可能会导致不确定的结果。希望发送非幂等请求的客户端应该等待发送该请求，直到它收到前一个请求的响应状态。
It is especially important that proxies correctly implement the properties of the Connection header field as specified in section 14.10.
按照第14.10节的规定，代理正确实现连接头字段的属性尤为重要。
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.
代理服务器必须分别向其客户端及其连接到的源服务器（或其他代理服务器）发出持久连接信号。每个持久连接仅适用于一个传输链路。
A proxy server MUST NOT establish a HTTP/1.1 persistent connection with an HTTP/1.0 client (but see RFC 2068 [33] for information and discussion of the problems with the Keep-Alive header implemented by many HTTP/1.0 clients).
代理服务器不得与HTTP/1.0客户端建立HTTP/1.1持久连接（但有关许多HTTP/1.0客户端实现的Keep-Alive标头问题的信息和讨论，请参阅RFC 2068[33]）。
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 (or existence) of this time-out for either the client or the server.
服务器通常会有一些超时值，超过该值，它们将不再保持非活动连接。代理服务器可能会使此值更高，因为客户端可能会通过同一服务器建立更多连接。持久连接的使用对客户端或服务器的此超时的长度（或存在性）没有任何要求。
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.
当客户端或服务器希望超时时，它应该在传输连接上发出一个优雅的关闭。客户机和服务器都应该不断监视传输的另一端，并根据需要做出响应。如果客户端或服务器未及时检测到另一方的关闭，则可能导致网络上不必要的资源消耗。
A client, server, or proxy MAY close the transport connection at any time. For example, a client might 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 sequence of requests without user interaction so long as the request sequence is idempotent (see section 9.1.2). Non-idempotent methods or sequences MUST NOT be automatically retried, although user agents MAY offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding of the application MAY substitute for user confirmation. The automatic retry SHOULD NOT be repeated if the second sequence of requests fails.
这意味着客户端、服务器和代理必须能够从异步关闭事件中恢复。只要请求序列是幂等的，客户端软件应重新打开传输连接并重新传输中止的请求序列，而无需用户交互（见第9.1.2节）。非幂等方法或序列不能自动重试，尽管用户代理可以为操作员提供重试请求的选择。通过对应用程序具有语义理解的用户代理软件进行确认可以替代用户确认。如果第二个请求序列失败，则不应重复自动重试。
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.
如果可能，服务器应始终对每个连接至少一个请求作出响应。服务器不应在发送响应的中间关闭连接，除非怀疑有网络或客户端故障。
Clients that use persistent connections SHOULD limit the number of simultaneous connections that they maintain to a given server. A single-user client SHOULD NOT maintain more than 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.
使用持久连接的客户端应该限制它们维护到给定服务器的同时连接的数量。单用户客户端与任何服务器或代理的连接不应超过2个。代理最多应使用2*N个到另一台服务器或代理的连接，其中N是同时活动的用户数。这些准则旨在提高HTTP响应时间并避免拥塞。
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.
HTTP/1.1服务器应该维护持久连接，并使用TCP的流控制机制来解决临时过载，而不是期望客户端重试而终止连接。后一种技术会加剧网络拥塞。
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 trailer 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.
发送消息体的HTTP/1.1（或更高版本）客户端在传输请求时应监视网络连接的错误状态。如果客户端看到错误状态，它应该立即停止传输正文。如果正文是使用“分块”编码发送的（第3.6节），则可以使用零长度的分块和空尾部来提前标记消息的结束。如果正文前面有Content-Length标头，则客户端必须关闭连接。
The purpose of the 100 (Continue) status (see section 10.1.1) is to allow a client that is sending a request message with a request body to determine if the origin server is willing to accept the request (based on the request headers) before the client sends the request body. In some cases, it might either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without looking at the body.
100（继续）状态的目的（参见第10.1.1节）是允许正在发送请求正文的请求消息的客户端在客户端发送请求正文之前确定源服务器是否愿意接受请求（基于请求标头）。在某些情况下，如果服务器在不查看正文的情况下拒绝消息，则客户端发送正文可能是不合适的，或者效率很低。
Requirements for HTTP/1.1 clients:
HTTP/1.1客户端的要求：
- If a client will wait for a 100 (Continue) response before sending the request body, it MUST send an Expect request-header field (section 14.20) with the "100-continue" expectation.
- 如果客户机将在发送请求正文之前等待100（继续）响应，则它必须发送带有“100 Continue”预期的Expect请求标头字段（第14.20节）。
- A client MUST NOT send an Expect request-header field (section 14.20) with the "100-continue" expectation if it does not intend to send a request body.
- 如果客户机不打算发送请求正文，则不得发送带有“100 continue”预期的Expect请求标头字段（第14.20节）。
Because of the presence of older implementations, the protocol allows ambiguous situations in which a client may send "Expect: 100- continue" without receiving either a 417 (Expectation Failed) status or a 100 (Continue) status. Therefore, when a client sends this header field to an origin server (possibly via a proxy) from which it has never seen a 100 (Continue) status, the client SHOULD NOT wait for an indefinite period before sending the request body.
由于存在较旧的实现，该协议允许在不接收417（预期失败）状态或100（继续）状态的情况下客户端发送“Expect:100-continue”的模糊情况。因此，当客户端将此头字段发送到从未见过100（继续）状态的源服务器（可能通过代理）时，客户端不应在发送请求正文之前无限期等待。
Requirements for HTTP/1.1 origin servers:
对HTTP/1.1源服务器的要求：
- Upon receiving a request which includes an Expect request-header field with the "100-continue" expectation, an origin server MUST either respond with 100 (Continue) status and continue to read from the input stream, or respond with a final status code. The origin server MUST NOT wait for the request body before sending the 100 (Continue) response. If it responds with a final status code, it MAY close the transport connection or it MAY continue
- 当接收到包含带有“100 continue”期望的Expect request header字段的请求时，源服务器必须以100（continue）状态响应并继续从输入流读取，或者以最终状态代码响应。在发送100（继续）响应之前，源服务器不能等待请求正文。如果它以最终状态代码响应，则可能会关闭传输连接或继续
to read and discard the rest of the request. It MUST NOT perform the requested method if it returns a final status code.
读取并放弃请求的其余部分。如果返回最终状态代码，则不能执行请求的方法。
- An origin server SHOULD NOT send a 100 (Continue) response if the request message does not include an Expect request-header field with the "100-continue" expectation, and MUST NOT send a 100 (Continue) response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility with RFC 2068, a server MAY send a 100 (Continue) status in response to an HTTP/1.1 PUT or POST request that does not include an Expect request-header field with the "100- continue" expectation. This exception, the purpose of which is to minimize any client processing delays associated with an undeclared wait for 100 (Continue) status, applies only to HTTP/1.1 requests, and not to requests with any other HTTP-version value.
- 如果请求消息不包含带有“100 Continue”预期的Expect请求标头字段，则源服务器不应发送100（Continue）响应，如果此类请求来自HTTP/1.0（或更早版本）客户端，则不得发送100（Continue）响应。此规则有一个例外：为了与RFC 2068兼容，服务器可以发送100（继续）状态以响应HTTP/1.1 PUT或POST请求，该请求不包括带有“100-继续”预期的Expect请求标头字段。此异常的目的是最小化与未声明的等待100（继续）状态相关的任何客户端处理延迟，它仅适用于HTTP/1.1请求，而不适用于具有任何其他HTTP版本值的请求。
- An origin server MAY omit a 100 (Continue) response if it has already received some or all of the request body for the corresponding request.
- 如果源服务器已经收到相应请求的部分或全部请求正文，则它可能会忽略100（Continue）响应。
- An origin server that sends a 100 (Continue) response MUST ultimately send a final status code, once the request body is received and processed, unless it terminates the transport connection prematurely.
- 发送100（Continue）响应的源服务器必须在接收和处理请求主体后最终发送最终状态代码，除非它提前终止传输连接。
- If an origin server receives a request that does not include an Expect request-header field with the "100-continue" expectation, the request includes a request body, and the server responds with a final status code before reading the entire request body from the transport connection, then the server SHOULD NOT close the transport connection until it has read the entire request, or until the client closes the connection. Otherwise, the client might not reliably receive the response message. However, this requirement is not be construed as preventing a server from defending itself against denial-of-service attacks, or from badly broken client implementations.
- 如果源服务器接收到的请求不包括带有“100 continue”期望值的Expect request header字段，则该请求包括请求正文，并且服务器在从传输连接读取整个请求正文之前会使用最终状态代码进行响应，然后，服务器在读取整个请求之前，或者在客户端关闭连接之前，不应关闭传输连接。否则，客户端可能无法可靠地接收响应消息。但是，此要求不能解释为阻止服务器防御拒绝服务攻击或严重破坏的客户端实现。
Requirements for HTTP/1.1 proxies:
HTTP/1.1代理的要求：
- If a proxy receives a request that includes an Expect request-header field with the "100-continue" expectation, and the proxy either knows that the next-hop server complies with HTTP/1.1 or higher, or does not know the HTTP version of the next-hop server, it MUST forward the request, including the Expect header field.
- 如果代理接收到一个请求，该请求包含一个带有“100 continue”期望值的Expect request header字段，并且代理知道下一跳服务器符合HTTP/1.1或更高版本，或者不知道下一跳服务器的HTTP版本，则它必须转发该请求，包括Expect header字段。
- If the proxy knows that the version of the next-hop server is HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST respond with a 417 (Expectation Failed) status.
- 如果代理知道下一个跃点服务器的版本是HTTP/1.0或更低，则它不能转发请求，并且必须以417（预期失败）状态响应。
- Proxies SHOULD maintain a cache recording the HTTP version numbers received from recently-referenced next-hop servers.
- 代理应该维护一个缓存，记录从最近引用的下一跳服务器接收到的HTTP版本号。
- A proxy MUST NOT forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include an Expect request-header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 1xx responses (see section 10.1).
- 如果请求消息是从HTTP/1.0（或更早版本）客户端接收到的，并且未包含带有“100 Continue”预期的Expect请求标头字段，则代理不得转发100（Continue）响应。该要求覆盖了转发1xx响应的一般规则（见第10.1节）。
If an HTTP/1.1 client sends a request which includes a request body, but which does not include an Expect request-header field with the "100-continue" expectation, and if the client is not directly connected to an HTTP/1.1 origin server, and if the client sees the connection close before receiving any status from the server, the client SHOULD retry the request. If the client does retry this request, it MAY use the following "binary exponential backoff" algorithm to be assured of obtaining a reliable response:
如果HTTP/1.1客户端发送的请求包含请求正文，但不包含带有“100 continue”期望值的Expect request header字段，并且如果客户端未直接连接到HTTP/1.1源服务器，并且如果客户端在从服务器接收任何状态之前看到连接已关闭，客户端应重试该请求。如果客户端确实重试此请求，则可以使用以下“二进制指数退避”算法来确保获得可靠响应：
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初始化为到服务器的估计往返时间（例如，基于建立连接所用的时间），或者如果往返时间不可用，则将变量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秒（以先到者为准）
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重复，直到请求被接受，收到错误响应，或者用户变得不耐烦并终止重试过程。
If at any point an error status is received, the client
如果在任何时候收到错误状态，则客户端
- SHOULD NOT continue and
- 不应继续和
- SHOULD close the connection if it has not completed sending the request message.
- 如果尚未完成发送请求消息，则应关闭连接。
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.
主机请求头字段（第14.23节）必须伴随所有HTTP/1.1请求。
Implementors 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 might take which may have an unexpected significance to themselves or others.
实施者应该意识到，软件在他们通过互联网进行的交互中代表了用户，并且应该小心地允许用户意识到他们可能采取的对他们自己或其他人可能具有意外意义的任何行动。
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to 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方法不应具有采取检索以外的操作的意义。这些方法应该被认为是“安全的”。这允许用户代理以一种特殊的方式表示其他方法，例如POST、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 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.
当然，不可能确保服务器不会因执行GET请求而产生副作用；事实上，一些动态资源认为这是一个特性。这里重要的区别是用户没有要求副作用，因此不能对其负责。
Methods can 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. Also, the methods OPTIONS and TRACE SHOULD NOT have side effects, and so are inherently idempotent.
方法还可以具有“幂等性”的属性，因为（除了错误或过期问题外）N>0个相同请求的副作用与单个请求相同。GET、HEAD、PUT和DELETE方法共享此属性。此外，方法选项和跟踪不应有副作用，因此本质上是幂等的。
However, it is possible that a sequence of several requests is non-idempotent, even if all of the methods executed in that sequence are idempotent. (A sequence is idempotent if a single execution of the entire sequence always yields a result that is not changed by a reexecution of all, or part, of that sequence.) For example, a sequence is non-idempotent if its result depends on a value that is later modified in the same sequence.
但是，一个包含多个请求的序列可能是非幂等的，即使在该序列中执行的所有方法都是幂等的。（如果整个序列的一次执行总是产生一个结果，而该结果不会因重新执行该序列的全部或部分而改变，则该序列是幂等的。）例如，如果序列的结果取决于随后在同一序列中修改的值，则该序列是非幂等的。
A sequence that never has side effects is idempotent, by definition (provided that no concurrent operations are being executed on the same set of resources).
根据定义，从不产生副作用的序列是幂等的（前提是没有在同一组资源上执行并发操作）。
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方法表示请求获取由请求URI标识的请求/响应链上可用的通信选项的信息。此方法允许客户端确定与资源或服务器功能相关的选项和/或需求，而无需执行资源操作或启动资源检索。
Responses to this method are not cacheable.
对此方法的响应不可缓存。
If the OPTIONS request includes an entity-body (as indicated by the presence of Content-Length or Transfer-Encoding), then the media type MUST be indicated by a Content-Type field. Although this specification does not define any use for such a body, future extensions to HTTP might use the OPTIONS body to make more detailed queries on the server. A server that does not support such an extension MAY discard the request body.
如果选项请求包括实体主体（如内容长度或传输编码所示），则媒体类型必须由内容类型字段指示。尽管此规范没有定义此类主体的任何用途，但HTTP的未来扩展可能会使用选项主体在服务器上进行更详细的查询。不支持这种扩展的服务器可能会丢弃请求正文。
If the Request-URI is an asterisk ("*"), the OPTIONS request is intended to apply to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 compliance (or lack thereof).
如果请求URI是星号（“*”），则选项请求一般应用于服务器，而不是特定的资源。由于服务器的通信选项通常取决于资源，“*”请求仅作为“ping”或“no op”类型的方法有用；它只允许客户端测试服务器的功能。例如，这可用于测试代理是否符合HTTP/1.1（或是否不符合）。
If the Request-URI is not an asterisk, the OPTIONS request applies only to the options that are available when communicating with that resource.
如果请求URI不是星号，则选项请求仅适用于与该资源通信时可用的选项。
A 200 response SHOULD include any header fields that indicate optional features implemented by the server and applicable to that resource (e.g., Allow), possibly including extensions not defined by this specification. The response body, if any, SHOULD also include information about the communication options. The format for such a
200响应应包括指示由服务器实现并适用于该资源的可选功能（例如，允许）的任何标题字段，可能包括本规范未定义的扩展。响应主体（如有）还应包括有关通信选项的信息。这类文件的格式
body is not defined by this specification, but might be defined by future extensions to HTTP. Content negotiation MAY be used to select the appropriate response format. If no response body is included, the response MUST include a Content-Length field with a field-value of "0".
正文不由本规范定义，但可能由HTTP的未来扩展定义。内容协商可用于选择适当的响应格式。如果未包含响应正文，则响应必须包含字段值为“0”的内容长度字段。
The Max-Forwards request-header field MAY be used to target a specific proxy in the request chain. When a proxy receives an OPTIONS request on an absoluteURI for which request forwarding is permitted, the proxy MUST check for a Max-Forwards field. If the Max-Forwards field-value is zero ("0"), the proxy MUST NOT forward the message; instead, the proxy SHOULD respond with its own communication options. If the Max-Forwards field-value is an integer greater than zero, the proxy MUST decrement the field-value when it forwards the request. If no Max-Forwards field is present in the request, then the forwarded request MUST NOT include a Max-Forwards field.
Max Forwards request header字段可用于针对请求链中的特定代理。当代理在允许请求转发的absoluteURI上接收到选项请求时，代理必须检查Max Forwards字段。如果“最大转发”字段值为零（“0”），则代理不得转发消息；相反，代理应该使用自己的通信选项进行响应。如果“最大转发”字段值是大于零的整数，则代理在转发请求时必须减小字段值。如果请求中不存在最大转发字段，则转发的请求不得包含最大转发字段。
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方法意味着检索由请求URI标识的任何信息（以实体的形式）。如果请求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.
如果请求消息包含if-Modified-Since、if-Unmodified-Since、if-Match、if-None-Match或if-Range头字段，则GET方法的语义将更改为“条件GET”。条件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.35. 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”。如第14.35节所述，部分GET要求仅转让实体的一部分。部分获取方法旨在通过允许完成部分检索的实体，而无需传输客户端已经持有的数据，从而减少不必要的网络使用。
The response to a GET request is cacheable if and only if it meets the requirements for HTTP caching described in section 13.
当且仅当GET请求满足第13节中描述的HTTP缓存要求时，GET请求的响应才是可缓存的。
See section 15.1.3 for security considerations when used for forms.
有关表格使用时的安全注意事项，请参见第15.1.3节。
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相同，只是服务器不能在响应中返回消息体。HTTP头中包含的响应HEAD请求的元信息应与响应GET请求发送的信息相同。此方法可用于获取请求隐含的实体的元信息，而无需传输实体体本身。此方法通常用于测试超文本链接的有效性、可访问性和最近的修改。
The response to a HEAD request MAY be cacheable 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.
对头部请求的响应可以是可缓存的，因为响应中包含的信息可用于从该资源更新先前缓存的实体。如果新字段值指示缓存的实体与当前实体不同（如Content Length、Content-MD5、ETag或Last Modified中的更改所示），则缓存必须将缓存项视为过时。
The POST method is used to request that the origin 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:
POST方法用于请求源服务器接受包含在请求中的实体，作为由请求行中的请求URI标识的资源的新从属。POST的设计允许采用统一的方法涵盖以下功能：
- Annotation of existing resources;
- 现有资源的注释；
- Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles;
- 向公告栏、新闻组、邮件列表或类似文章组发布消息；
- Providing a block of data, such as the result of submitting a form, to a data-handling process;
- 向数据处理过程提供数据块，例如提交表单的结果；
- Extending a database through an append operation.
- 通过追加操作扩展数据库。
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.
POST方法执行的实际功能由服务器决定，通常取决于请求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.
POST方法执行的操作可能不会产生可由URI标识的资源。在这种情况下，200（确定）或204（无内容）是适当的响应状态，这取决于响应是否包括描述结果的实体。
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).
如果已在源服务器上创建资源，则响应应为201（已创建），并包含一个描述请求状态并引用新资源的实体，以及一个位置标头（参见第14.30节）。
Responses to this method are not cacheable, 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 cacheable resource.
对此方法的响应不可缓存，除非响应包含适当的缓存控制或Expires标头字段。然而，303（参见其他）响应可用于指示用户代理检索可缓存资源。
POST requests MUST obey the message transmission requirements set out in section 8.2.
POST请求必须遵守第8.2节规定的信息传输要求。
See section 15.1.3 for security considerations.
安全注意事项见第15.1.3节。
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方法请求将封闭的实体存储在提供的请求URI下。如果请求URI引用的是一个已经存在的资源，则应将包含的实体视为驻留在源服务器上的实体的修改版本。如果请求URI不指向现有资源，并且该URI能够由请求用户代理定义为新资源，则源服务器可以使用该URI创建资源。如果创建了新资源，则源服务器必须通过201（已创建）响应通知用户代理。如果修改了现有资源，则应发送200（确定）或204（无内容）响应代码，以指示请求成功完成。如果无法使用请求URI创建或修改资源，则应给出反映问题性质的适当错误响应。实体的接收者不得忽略其不理解或未实现的任何内容-*（例如，内容范围）标题，在这种情况下，必须返回501（未实现）响应。
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 cacheable.
如果请求通过缓存，并且请求URI标识一个或多个当前缓存的实体，则这些条目应视为过时。对此方法的响应不可缓存。
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 might 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,
POST和PUT请求之间的根本区别体现在请求URI的不同含义上。POST请求中的URI标识将处理封闭实体的资源。该资源可能是一个数据接受进程、到其他协议的网关，或者是一个接受注释的单独实体。相反，PUT请求中的URI标识了请求所包含的实体——用户代理知道URI的用途，服务器不得尝试将请求应用于其他资源。如果服务器希望将请求应用于不同的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.
它必须发送301（永久移动）响应；然后，用户代理可以自行决定是否重定向请求。
A single resource MAY be identified by many different URIs. For example, an article might 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 might result in several other URIs being defined by the origin server.
单个资源可以由许多不同的URI标识。例如，一篇文章可能有一个用于标识“当前版本”的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节规定的信息传输要求。
Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request SHOULD be applied to the resource created or modified by the PUT.
除非为特定实体头另有规定，否则PUT请求中的实体头应应用于PUT创建或修改的资源。
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方法请求源服务器删除由请求URI标识的资源。此方法可能会被原始服务器上的人工干预（或其他方式）覆盖。即使从源服务器返回的状态代码指示操作已成功完成，也无法保证客户端已执行该操作。但是，除非在给出响应时，服务器打算删除资源或将其移动到无法访问的位置，否则不应指示成功。
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 action has been enacted but the response does not include an entity.
如果响应包括描述状态的实体，则成功响应应为200（正常）；如果行动尚未实施，则成功响应应为202（已接受）；如果行动已实施，但响应不包括实体，则成功响应应为204（无内容）。
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 cacheable.
如果请求通过缓存，并且请求URI标识一个或多个当前缓存的实体，则这些条目应视为过时。对此方法的响应不可缓存。
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
TRACE方法用于调用请求消息的远程应用层循环。请求的最终接收者应将收到的消息作为200（OK）响应的实体体反映回客户端。最终的收件人是
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.
原始服务器或在请求中接收最大转发值为零（0）的第一个代理或网关（参见第14.31节）。跟踪请求不得包含实体。
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.45) 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.
跟踪允许客户端查看在请求链的另一端接收到的内容，并将该数据用于测试或诊断信息。Via头字段（第14.45节）的值特别重要，因为它充当请求链的跟踪。使用Max Forwards标头字段允许客户端限制请求链的长度，这对于测试无限循环中转发消息的代理链非常有用。
If the request is valid, 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.
如果请求有效，响应应该在实体体中包含整个请求消息，内容类型为“message/http”。不得缓存对此方法的响应。
This specification reserves the method name CONNECT for use with a proxy that can dynamically switch to being a tunnel (e.g. SSL tunneling [44]).
本规范保留方法名称CONNECT，用于可动态切换为隧道的代理（例如SSL隧道[44]）。
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.
下面描述了每个状态代码，包括它可以遵循的方法的描述以及响应中所需的任何元信息。
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. There are no required headers for this class of status code. 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.
此类状态代码表示临时响应，仅由状态行和可选标题组成，并以空行终止。此类状态代码没有必需的标题。由于HTTP/1.0未定义任何1xx状态代码，服务器不得向HTTP/1.0客户端发送1xx响应，除非在实验条件下。
A client MUST be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a 100 (Continue) status message. Unexpected 1xx status responses MAY be ignored by a user agent.
在常规响应之前，客户必须准备好接受一个或多个1xx状态响应，即使客户不希望收到100（继续）状态消息。用户代理可能会忽略意外的1xx状态响应。
Proxies MUST forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself requested the generation of the 1xx response. (For example, if a
代理必须转发1xx响应，除非代理与其客户端之间的连接已关闭，或者除非代理本身请求生成1xx响应。（例如，如果
proxy adds a "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).)
代理在转发请求时会添加一个“Expect:100 continue”字段，这样就不需要转发相应的100（continue）响应。）
The client SHOULD 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. See section 8.2.3 for detailed discussion of the use and handling of this status code.
客户端应继续其请求。此临时响应用于通知客户端请求的初始部分已被接收，并且尚未被服务器拒绝。客户端应继续发送请求的其余部分，或者，如果请求已完成，则忽略此响应。服务器必须在请求完成后发送最终响应。有关此状态代码的使用和处理的详细讨论，请参见第8.2.3节。
The server understands and is willing to comply with the client's request, via the Upgrade message header field (section 14.42), 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 message header字段（第14.42节）遵守客户的请求，以更改此连接上使用的应用程序协议。服务器将在终止101响应的空行之后立即将协议切换到响应的Upgrade header字段定义的协议。
The protocol SHOULD be switched only 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 might be advantageous when delivering resources that use such features.
只有在有利的情况下才能切换协议。例如，切换到较新版本的HTTP比旧版本更为有利，而在交付使用此类功能的资源时，切换到实时同步协议可能更为有利。
This class of status code indicates that the client's request was successfully received, understood, and accepted.
此类状态代码表示已成功接收、理解和接受客户机的请求。
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;
获取响应中发送的请求资源对应的实体；
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
HEAD响应中发送请求资源对应的实体头字段，不带任何消息体；
POST an entity describing or containing the result of the action;
发布描述或包含行动结果的实体；
TRACE an entity containing the request message as received by the end server.
跟踪终端服务器接收到的包含请求消息的实体。
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 URI for the resource given by a Location header field. 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. 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引用，最具体的资源URI由Location头字段给出。响应应包括一个实体，其中包含资源特征和位置列表，用户或用户代理可从中选择最合适的一个。实体格式由内容类型标题字段中给定的媒体类型指定。源服务器必须在返回201状态代码之前创建资源。如果无法立即执行该操作，则服务器应改为使用202（已接受）响应。
A 201 response MAY contain an ETag response header field indicating the current value of the entity tag for the requested variant just created, see section 14.19.
201响应可能包含一个ETag响应头字段，指示刚刚创建的请求变量的实体标记的当前值，请参见第14.19节。
The request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might 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号答复故意不作承诺。它的目的是允许服务器接受其他进程的请求（可能是一个面向批处理的进程，每天只运行一次），而不需要用户代理与服务器的连接持续到进程完成为止。与此响应一起返回的实体应该包括请求当前状态的指示，以及指向状态监视器的指针，或者用户可以预期何时完成请求的一些估计。
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 might 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).
实体头中返回的元信息不是源服务器提供的最终集合，而是从本地或第三方副本收集的。呈现的集合可以是原始版本的子集或超集。例如，包含有关资源的本地注释信息可能会导致源服务器已知的元信息的超集。无需使用此响应代码，仅当响应为200（正常）时才适用。
The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.
服务器已完成请求，但不需要返回实体主体，并且可能希望返回更新的元信息。响应可能包括实体头形式的新的或更新的元信息，如果存在，则应与请求的变量相关联。
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent's active view.
如果客户端是用户代理，则不应更改导致发送请求的文档视图。此响应的主要目的是允许在不更改用户代理的活动文档视图的情况下输入操作，尽管任何新的或更新的元信息都应应用于当前用户代理的活动视图中的文档。
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
204响应不能包括消息体，因此总是由头字段后的第一个空行终止。
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.
服务器已完成请求，用户代理应重置导致发送请求的文档视图。此响应主要用于允许通过用户输入进行操作输入，然后清除输入的形式，以便用户可以轻松启动另一个输入操作。响应不得包含实体。
The server has fulfilled the partial GET request for the resource. The request MUST have included a Range header field (section 14.35) indicating the desired range, and MAY have included an If-Range header field (section 14.27) to make the request conditional.
服务器已完成资源的部分GET请求。请求必须包含一个范围标头字段（第14.35节），指示所需的范围，并且可能包含一个If范围标头字段（第14.27节），以使请求有条件。
The response MUST include the following header fields:
响应必须包括以下标题字段：
- Either a Content-Range header field (section 14.16) indicating the range included with this response, or a multipart/byteranges Content-Type including Content-Range fields for each part. If a Content-Length header field is present in the response, its value MUST match the actual number of OCTETs transmitted in the message-body.
- 内容范围标题字段（第14.16节）指示此响应包含的范围，或多部分/byteranges内容类型，包括每个部分的内容范围字段。如果响应中存在内容长度标头字段，则其值必须与消息正文中传输的实际八位字节数匹配。
- Date
- 日期
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- ETag和/或内容位置，如果报头是在对同一请求的200响应中发送的
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
- Expires、Cache Control和/或variew，如果字段值可能与之前针对同一变量的任何响应中发送的值不同
If the 206 response is the result of an If-Range request that used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. If the response is the result of an If-Range request that used a weak validator, the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers. Otherwise, the response MUST include all of the entity-headers that would have been returned with a 200 (OK) response to the same request.
如果206响应是使用强缓存验证器的If范围请求的结果（参见第13.3.3节），则响应不应包括其他实体头。如果响应是使用弱验证器的If范围请求的结果，则响应不得包括其他实体头；这可以防止缓存实体和更新的头之间的不一致。否则，响应必须包括所有实体头，这些实体头将与对同一请求的200（OK）响应一起返回。
A cache MUST NOT combine a 206 response with other previously cached content if the ETag or Last-Modified headers do not match exactly, see 13.5.4.
如果ETag或上次修改的标头不完全匹配，则缓存不得将206响应与以前缓存的其他内容相结合，请参见13.5.4。
A cache that does not support the Range and Content-Range headers MUST NOT cache 206 (Partial) responses.
不支持范围和内容范围标头的缓存不得缓存206（部分）响应。
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 client SHOULD detect infinite redirection loops, since such loops generate network traffic for each redirection.
此类状态代码表示用户代理需要采取进一步的操作以满足请求。当且仅当第二个请求中使用的方法是GET或HEAD时，所需的操作可由用户代理执行，而无需与用户交互。客户端应该检测无限重定向循环，因为这样的循环为每个重定向生成网络流量。
Note: previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that there might be clients that implement such a fixed limitation.
注意：本规范的早期版本建议最多进行五次重定向。内容开发人员应该知道，可能有一些客户端实现了这样一个固定的限制。
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.
请求的资源对应于一组表示中的任何一个，每个表示都有其自己的特定位置，并且正在提供代理驱动的协商信息（第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
除非是HEAD请求，否则响应应包括一个实体，其中包含资源特征和位置列表，用户或用户代理可以从中选择最合适的一个。实体格式由内容类型标题字段中给定的媒体类型指定。取决于
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.
在用户代理中，可以自动执行最适当选择的选择。然而，本规范并未定义此类自动选择的任何标准。
If the server has a preferred choice of representation, it SHOULD include the specific URI for that representation in the Location field; user agents MAY use the Location field value for automatic redirection. This response is cacheable unless indicated otherwise.
如果服务器有一个首选的表示选择，它应该在位置字段中包含该表示的特定URI；用户代理可以使用位置字段值进行自动重定向。除非另有说明，否则此响应是可缓存的。
The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to 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 cacheable unless indicated otherwise.
已为请求的资源分配了一个新的永久URI，将来对此资源的任何引用都应使用其中一个返回的URI。具有链接编辑功能的客户端应尽可能自动将对请求URI的引用重新链接到服务器返回的一个或多个新引用。除非另有说明，否则此响应是可缓存的。
The new permanent URI 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字段提供。除非请求方法是HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新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.
如果收到301状态代码以响应GET或HEAD以外的请求，则除非用户能够确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。
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状态代码后自动重定向POST请求时，一些现有HTTP/1.0用户代理会错误地将其更改为GET请求。
The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client SHOULD continue to use the Request-URI for future requests. This response is only cacheable if indicated by a Cache-Control or Expires header field.
请求的资源临时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用请求URI来处理将来的请求。只有在缓存控件或Expires标头字段指示时，此响应才可缓存。
The temporary URI 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字段提供。除非请求方法是HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新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.
如果302状态代码是响应GET或HEAD以外的请求而接收的，则除非用户能够确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。
Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
注意：RFC 1945和RFC 2068指定不允许客户端更改重定向请求的方法。然而，大多数现有的用户代理实现将302视为303响应，对位置字段值执行GET，而不考虑原始请求方法。已经为希望明确说明客户端预期会做出何种反应的服务器添加了状态代码303和307。
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 MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
对请求的响应可以在不同的URI下找到，并且应该使用该资源上的GET方法进行检索。此方法主要用于允许后激活脚本的输出将用户代理重定向到所选资源。新URI不是最初请求的资源的替代引用。不能缓存303响应，但对第二个（重定向）请求的响应可能是可缓存的。
The different URI 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).
响应中的Location字段应该给出不同的URI。除非请求方法是HEAD，否则响应的实体应该包含一个简短的超文本注释，并带有指向新URI的超链接。
Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303.
注意：许多HTTP/1.1之前的用户代理不了解303状态。当与这样的客户端的互操作性是一个问题时，可以改用302状态代码，因为大多数用户代理对302响应作出反应，如本文针对303所述。
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 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
如果客户端执行了条件GET请求，并且允许访问，但文档尚未修改，则服务器应使用此状态代码进行响应。304响应不能包含消息体，因此总是由头字段后的第一个空行终止。
The response MUST include the following header fields:
响应必须包括以下标题字段：
- Date, unless its omission is required by section 14.18.1
- 日期，除非第14.18.1节要求省略
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
如果无时钟源服务器遵守这些规则，并且代理和客户端将其自己的日期添加到未收到的任何响应中（如[RFC 2068]第14.19节所述），缓存将正常运行。
- ETag and/or Content-Location, if the header would have been sent in a 200 response to the same request
- ETag和/或内容位置，如果报头是在对同一请求的200响应中发送的
- Expires, Cache-Control, and/or Vary, if the field-value might differ from that sent in any previous response for the same variant
- Expires、Cache Control和/或variew，如果字段值可能与之前针对同一变量的任何响应中发送的值不同
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.
如果使用强缓存验证器（参见第13.3.3节），则响应不应包括其他实体头。否则（即，使用弱验证器的条件GET），响应不得包括其他实体头；这可以防止缓存实体和更新的头之间的不一致。
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 requested resource MUST be accessed through the proxy given by the Location field. The Location field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.
必须通过Location字段提供的代理访问请求的资源。Location字段提供代理的URI。收件人应通过代理重复此单个请求。305响应只能由源服务器生成。
Note: RFC 2068 was not clear that 305 was intended to redirect a single request, and to be generated by origin servers only. Not observing these limitations has significant security consequences.
注意：RFC 2068不清楚305是否用于重定向单个请求，并且仅由源服务器生成。不遵守这些限制会带来严重的安全后果。
The 306 status code was used in a previous version of the specification, is no longer used, and the code is reserved.
306状态代码已在先前版本的规范中使用，不再使用，代码保留。
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 cacheable if indicated by a Cache-Control or Expires header field.
请求的资源临时驻留在不同的URI下。由于重定向有时可能会被更改，因此客户端应该继续使用请求URI进行将来的请求。只有在缓存控件或Expires标头字段指示时，此响应才可缓存。
The temporary URI 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) , since many pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the note SHOULD contain the information necessary for a user to repeat the original request on the new URI.
临时URI应该由响应中的Location字段提供。除非请求方法是HEAD，否则响应的实体应该包含一个简短的超文本注释，其中包含指向新URI的超链接，因为许多HTTP/1.1之前的用户代理不了解307状态。因此，注释应该包含用户在新URI上重复原始请求所需的信息。
If the 307 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.
如果307状态代码是响应GET或HEAD以外的请求而接收的，则除非用户能够确认，否则用户代理不得自动重定向请求，因为这可能会改变发出请求的条件。
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请求外，服务器应包含一个实体，其中包含对错误情况的解释，以及错误是暂时的还是永久性的。这些状态代码适用于任何请求方法。用户代理应向用户显示任何包含的实体。
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 unacknowledged input buffers before they can be read and interpreted by the HTTP application.
如果客户机正在发送数据，则使用TCP的服务器实现应小心确保在服务器关闭输入连接之前，客户机确认收到包含响应的数据包。如果客户机在关闭后继续向服务器发送数据，服务器的TCP堆栈将向客户机发送重置数据包，这可能会在HTTP应用程序读取和解释客户机未确认的输入缓冲区之前擦除这些缓冲区。
The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.
由于语法错误，服务器无法理解该请求。未经修改，客户端不应重复请求。
The request requires user authentication. The response MUST include a WWW-Authenticate header field (section 14.47) 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 might include relevant diagnostic information. HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" [43].
请求需要用户身份验证。响应必须包括WWW Authenticate标头字段（第14.47节），其中包含适用于请求资源的质询。客户可以使用合适的授权标头字段重复请求（第14.8节）。如果请求已包括授权凭据，则401响应表示已拒绝这些凭据的授权。如果401响应包含与先前响应相同的质询，并且用户代理已至少尝试了一次身份验证，则应向用户呈现响应中给出的实体，因为该实体可能包括相关诊断信息。HTTP访问身份验证在“HTTP身份验证：基本和摘要访问身份验证”[43]中进行了解释。
This code is reserved for future use.
此代码保留供将来使用。
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. If the server does not wish to make this information available to the client, the status code 404 (Not Found) can be used instead.
服务器理解该请求，但拒绝满足该请求。授权没有帮助，请求不应重复。如果请求方法不是HEAD，并且服务器希望公开请求未得到满足的原因，那么它应该在实体中描述拒绝的原因。如果服务器不希望将此信息提供给客户端，则可以使用状态代码404（未找到）。
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. 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. 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.
服务器未找到任何与请求URI匹配的内容。没有说明该情况是暂时的还是永久的。如果服务器通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址，则应使用410（Gone）状态代码。当服务器不希望确切地揭示请求被拒绝的原因，或者当没有其他响应适用时，通常使用此状态代码。
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.
请求行中指定的方法不允许用于由请求URI标识的资源。响应必须包含一个Allow标头，其中包含请求资源的有效方法列表。
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.
根据请求中发送的accept标头，由请求标识的资源只能生成具有不可接受内容特征的响应实体。
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请求，否则响应应包括包含可用实体特征和位置列表的实体，用户或用户代理可从中选择最合适的实体。实体格式由内容类型标题字段中给定的媒体类型指定。根据用户代理的格式和能力，可以自动执行最合适的选择。然而，本规范并未定义此类自动选择的任何标准。
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.
注意：根据请求中发送的accept标头，允许HTTP/1.1服务器返回不可接受的响应。在某些情况下，这甚至可能比发送406响应更好。鼓励用户代理检查传入响应的标头，以确定其是否可接受。
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.
如果响应可能不可接受，则用户代理应暂时停止接收更多数据，并向用户查询有关进一步操作的决定。
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 "HTTP Authentication: Basic and Digest Access Authentication" [43].
此代码类似于401（未经授权），但表示客户端必须首先向代理进行身份验证。代理必须返回一个代理身份验证标头字段（第14.33节），其中包含适用于所请求资源的代理的质询。客户可以使用合适的代理授权标头字段重复请求（第14.34节）。HTTP访问身份验证在“HTTP身份验证：基本和摘要访问身份验证”[43]中进行了解释。
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.
客户端未在服务器准备等待的时间内生成请求。客户端可以在以后任何时候重复请求而不进行修改。
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 might not be possible and is not required.
用于用户识别冲突源的信息。理想情况下，响应实体将包括足够的信息，供用户或用户代理修复问题；然而，这可能是不可能的，也不是必须的。
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the entity being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the server might use the 409 response to indicate that it can't complete the request. In this case, the response entity would likely contain a list of the differences between the two versions in a format defined by the response Content-Type.
在响应PUT请求时最有可能发生冲突。例如，如果正在使用版本控制，并且正在放置的实体包含对资源的更改，这些更改与先前（第三方）请求所做的更改相冲突，则服务器可能会使用409响应来指示它无法完成请求。在这种情况下，响应实体可能会以响应内容类型定义的格式包含两个版本之间差异的列表。
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to 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 cacheable unless indicated otherwise.
请求的资源在服务器上不再可用，并且不知道转发地址。预计这种情况将被视为永久性的。具有链接编辑功能的客户端应在用户批准后删除对请求URI的引用。如果服务器不知道或无法确定该状况是否为永久性，则应使用状态代码404（未找到）。除非另有说明，否则此响应是可缓存的。
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响应主要用于通过通知接收者资源故意不可用以及服务器所有者希望删除指向该资源的远程链接来协助web维护任务。此类活动在有限的时间、促销服务和不再在服务器站点工作的个人资源中很常见。无需将所有永久不可用的资源标记为“已消失”，也无需将标记保留任何时间长度——这由服务器所有者自行决定。
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.
服务器拒绝接受没有定义内容长度的请求。如果客户端在请求消息中添加了包含消息正文长度的有效内容长度头字段，则客户端可能会重复该请求。
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.
在服务器上测试时，一个或多个请求标头字段中给定的前提条件被评估为false。此响应代码允许客户端对当前资源元信息（标头字段数据）设置前提条件，从而防止请求的方法应用于预期资源以外的资源。
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.
如果条件是临时的，则服务器应包含一个Retry After标头字段，以指示该条件是临时的，并且在客户端可以重试的时间之后。
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 URI "black hole" of redirection (e.g., a redirected URI 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.
服务器拒绝为请求提供服务，因为请求URI比服务器愿意解释的长度长。只有当客户端将POST请求错误地转换为具有长查询信息的GET请求时，当客户端陷入重定向的URI“黑洞”（例如，指向自身后缀的重定向URI前缀）时，才可能出现这种罕见的情况，或者，当服务器受到试图利用某些服务器中存在的安全漏洞（使用固定长度缓冲区读取或操作请求URI）的客户端的攻击时。
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.
服务器拒绝为请求提供服务，因为请求实体的格式不受请求方法的请求资源支持。
A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first-byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)
如果请求包含范围请求标头字段（第14.35节），且该字段中的范围说明符值均未与所选资源的当前范围重叠，且请求未包含if范围请求标头字段，则服务器应返回带有此状态代码的响应。（对于字节范围，这意味着所有字节范围规范值的第一个字节位置都大于所选资源的当前长度。）
When this status code is returned for a byte-range request, the response SHOULD include a Content-Range entity-header field specifying the current length of the selected resource (see section 14.16). This response MUST NOT use the multipart/byteranges content-type.
当为字节范围请求返回此状态代码时，响应应包括一个内容范围实体标题字段，指定所选资源的当前长度（参见第14.16节）。此响应不能使用multipart/byteranges内容类型。
The expectation given in an Expect request-header field (see section 14.20) could not be met by this server, or, if the server is a proxy, the server has unambiguous evidence that the request could not be met by the next-hop server.
此服务器无法满足Expect request header字段（参见第14.20节）中给出的期望，或者，如果服务器是代理，则服务器有明确证据表明下一跳服务器无法满足该请求。
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请求外，服务器应包含一个实体，其中包含对错误情况的解释，以及错误是暂时的还是永久性的。用户代理应向用户显示任何包含的实体。这些响应代码适用于任何请求方法。
The server encountered an unexpected condition which prevented it from fulfilling the request.
服务器遇到意外情况，无法满足请求。
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.
服务器不支持满足请求所需的功能。当服务器无法识别请求方法并且无法为任何资源支持该方法时，这是适当的响应。
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.
服务器在充当网关或代理时，从其在尝试完成请求时访问的上游服务器接收到无效响应。
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 After标头中指示。如果没有在之后重试，客户端应该像处理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状态代码的存在并不意味着服务器在过载时必须使用它。有些服务器可能希望简单地拒绝连接。
The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request.
服务器在充当网关或代理时，没有从URI（例如HTTP、FTP、LDAP）指定的上游服务器或它在尝试完成请求时需要访问的某些其他辅助服务器（例如DNS）收到及时响应。
Note: Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.
注意：实现者注意：已知一些部署的代理在DNS查找超时时返回400或500。
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节所述，除了此错误消息。响应应该包含一个实体，描述为什么不支持该版本以及该服务器支持哪些其他协议。
11 Access Authentication
11访问认证
HTTP provides several OPTIONAL challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to provide authentication information. The general framework for access authentication, and the specification of "basic" and "digest" authentication, are specified in "HTTP Authentication: Basic and Digest Access Authentication" [43]. This specification adopts the definitions of "challenge" and "credentials" from that specification.
HTTP提供了几种可选的质询-响应身份验证机制，服务器可以使用这些机制质询客户机请求，客户机可以使用这些机制提供身份验证信息。访问身份验证的一般框架以及“基本”和“摘要”身份验证的规范在“HTTP身份验证：基本和摘要访问身份验证”[43]中规定。本规范采用该规范中“质询”和“凭证”的定义。
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 when there are multiple representations available.
大多数HTTP响应都包含一个实体，其中包含供用户解释的信息。自然地，希望向用户提供与请求相对应的“最佳可用”实体。不幸的是，对于服务器和缓存，并不是所有用户都有相同的“最佳”首选项，也不是所有用户代理都能够同等地呈现所有实体类型。因此，HTTP提供了几种“内容协商”机制——当有多个表示可用时，为给定响应选择最佳表示的过程。
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.
HTTP中有两种可能的内容协商：服务器驱动的协商和代理驱动的协商。这两种协商是正交的，因此可以单独使用或组合使用。当缓存使用源服务器提供的代理驱动的协商信息以便为后续请求提供服务器驱动的协商时，会出现一种称为透明协商的组合方法。
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 Language、Accept Encoding等），这些字段描述其对此类响应的偏好。
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 the user's privacy.
2. 让用户代理在每个请求中描述其功能既可能效率非常低（因为只有一小部分响应具有多个表示），也可能侵犯用户的隐私。
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.43). 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节）、接受字符集（第14.2节）、接受编码（第14.3节）、接受语言（第14.4节）和用户代理（第14.43节）。但是，源服务器不限于这些维度，并且可以根据请求的任何方面改变响应，包括请求头字段之外或本规范未定义的扩展头字段内的信息。
The Vary header field can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation. See section 13.6 for use of the Vary header field by caches and section 14.44 for use of the Vary header field by servers.
Vary header字段可用于表示服务器用于选择受服务器驱动协商约束的表示的参数。请参阅第13.6节，了解通过缓存使用Vary header字段，以及第14.44节，了解通过服务器使用Vary header字段。
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 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.
使用代理驱动的协商，用户代理在从源服务器接收到初始响应后，为响应选择最佳表示。选择基于响应的可用表示的列表，该列表包含在初始响应的头字段或实体体中，每个表示由其自己的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.
当响应在常用维度（如类型、语言或编码）上发生变化时，当源服务器无法通过检查请求来确定用户代理的能力时，通常当使用公共缓存来分配服务器负载和减少网络使用时，代理驱动的协商是有利的。
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.
代理驱动的协商的缺点是需要第二个请求才能获得最佳的替代表示。第二个请求仅在使用缓存时有效。此外，本规范没有定义任何支持自动选择的机制，尽管它也没有阻止任何此类机制被开发为扩展并在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（多选）和406（不可接受）状态代码，用于在服务器不愿意或无法使用服务器驱动协商提供不同响应时启用代理驱动协商。
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.
透明协商的优点是，分配原本需要的源服务器协商工作，并且在缓存能够正确猜测正确响应时，消除代理驱动协商的第二个请求延迟。
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 that could be used within HTTP/1.1.
本规范没有定义任何透明协商机制，尽管它也没有阻止任何此类机制被开发为可在HTTP/1.1中使用的扩展。
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, headers, response codes, etc.
HTTP通常用于分布式信息系统，通过使用响应缓存可以提高性能。HTTP/1.1协议包含许多元素，旨在使缓存尽可能工作。由于这些元素与协议的其他方面密不可分，并且它们相互作用，因此将HTTP的基本缓存设计与方法、头、响应代码等的详细描述分开来描述是很有用的。
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,
性能、可用性和断开连接的操作要求我们能够放松语义透明的目标。HTTP/1.1协议允许源服务器、缓存、，
and clients to explicitly reduce transparency when necessary. However, because non-transparent operation may confuse non-expert users, and might be incompatible with certain server applications (such as those for ordering merchandise), the protocol requires that transparency be relaxed
以及客户在必要时明确降低透明度。然而，由于非透明操作可能会混淆非专家用户，并且可能与某些服务器应用程序（例如用于订购商品的应用程序）不兼容，因此协议要求放宽透明度
- only by an explicit protocol-level request when relaxed by client or origin server
- 当客户端或源服务器放松时，仅通过显式协议级请求
- only with an explicit warning to the end user when relaxed by cache or client
- 只有在缓存或客户端放松时才向最终用户发出明确警告
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 implementor might be faced with design decisions not explicitly discussed in this specification. If a decision might affect semantic transparency, the implementor ought to err on the side of maintaining transparency unless a careful and complete analysis shows significant benefits in breaking transparency.
注意：服务器、缓存或客户端实现者可能面临本规范中未明确讨论的设计决策。如果一个决策可能会影响语义透明度，那么实现者应该在保持透明度方面犯错误，除非仔细和完整的分析表明破坏透明度有显著的好处。
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. 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, origin 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节）；如果源服务器如此指定，则仅是源服务器的新鲜度要求。
If a stored response is not "fresh enough" by the most restrictive freshness requirement of both the client and the origin server, in carefully considered circumstances the cache MAY still return the response with the appropriate Warning header (see section 13.1.5 and 14.46), unless such a response is prohibited (e.g., by a "no-store" cache-directive, or by a "no-cache" cache-request-directive; see section 14.9).
如果客户机和源服务器的最严格的新鲜度要求使存储的响应“不够新鲜”，则在仔细考虑的情况下，缓存仍可能返回带有适当警告标头的响应（见第13.1.5和14.46节），除非禁止此类响应（例如，“无存储”缓存指令，或“无缓存”缓存请求指令；参见第14.9节）。
3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect), or error (4xx or 5xx) response message.
3. 这是一个适当的304（未修改）、305（代理重定向）或错误（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 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. A user agent that receives a stale response without a Warning MAY display a warning indication to the user.
如果缓存接收到通常会转发给请求客户端的响应（整个响应或304（未修改）响应），并且接收到的响应不再新鲜，则缓存应将其转发给请求客户端，而不添加新警告（但不删除任何现有警告头）。缓存不应该仅仅因为响应在传输过程中过时而尝试重新验证响应；这可能导致无限循环。在没有警告的情况下接收陈旧响应的用户代理可以向用户显示警告指示。
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 general-header. The Warning header and the currently defined warnings are described in section 14.46. The warning allows clients to take appropriate action.
每当缓存返回的响应既不是第一手的，也不是“足够新鲜”（在第13.1.1节条件2的意义上）时，它必须使用警告通用标题附加警告。第14.46节描述了警告标题和当前定义的警告。警告允许客户端采取适当的操作。
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 assigned three digit warn-codes. The first digit indicates whether the Warning MUST or MUST NOT be deleted from a stored cache entry after a successful revalidation:
警告被分配三位数字的警告代码。第一位数字指示在成功重新验证后是否必须从存储的缓存条目中删除警告：
1xx Warnings that describe the freshness or revalidation status of the response, and so MUST be deleted after a successful revalidation. 1XX warn-codes MAY be generated by a cache only when validating a cached entry. It MUST NOT be generated by clients.
描述响应新鲜度或重新验证状态的1xx警告，因此必须在成功重新验证后删除。只有在验证缓存条目时，缓存才能生成1XX警告代码。它不能由客户端生成。
2xx Warnings that describe some aspect of the entity body or entity headers that is not rectified by a revalidation (for example, a lossy compression of the entity bodies) and which MUST NOT be deleted after a successful revalidation.
2xx警告，描述实体正文或实体标题的某些方面，这些方面未通过重新验证纠正（例如，实体正文的有损压缩），并且在成功重新验证后不得删除。
See section 14.46 for the definitions of the codes themselves.
有关代码本身的定义，请参见第14.46节。
HTTP/1.0 caches will cache all Warnings in responses, without deleting the ones in the first category. Warnings in responses that are passed to HTTP/1.0 caches carry an extra warning-date field, which prevents a future HTTP/1.1 recipient from believing an erroneously cached Warning.
HTTP/1.0缓存将缓存响应中的所有警告，而不会删除第一类中的警告。传递给HTTP/1.0缓存的响应中的警告带有一个额外的警告日期字段，这可以防止将来的HTTP/1.1收件人相信错误缓存的警告。
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 might provide the same warning with texts in both English and Basque.
一个响应可能会附加多个警告（由源服务器或缓存附加），包括具有相同代码号的多个警告。例如，服务器可能会提供相同的警告，同时提供英语和巴斯克语文本。
When multiple warnings are attached to a response, it might 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没有指定严格的优先级规则来决定显示哪些警告以及以何种顺序显示，但建议使用一些启发式方法。
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 might need to provide explicit directives to the HTTP caches. We use the Cache-Control header for this purpose.
HTTP/1.1（服务器指定的过期时间和验证器）中的基本缓存机制是对缓存的隐式指令。在某些情况下，服务器或客户端可能需要向HTTP缓存提供显式指令。为此，我们使用缓存控制头。
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 is 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").
在某些情况下，缓存控制指令被明确指定为削弱语义透明度的近似值（例如，“max stale”或“public”）。
The cache-control directives are described in detail in section 14.9.
第14.9节详细描述了缓存控制指令。
Many user agents make it possible for users to override the basic caching mechanisms. For example, the user agent might 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 agent SHOULD NOT default to either non-transparent behavior, or behavior that results in abnormally ineffective caching, but MAY be explicitly configured to do so by an explicit action of the user.
许多用户代理使得用户可以覆盖基本的缓存机制。例如，用户代理可能允许用户指定从不验证缓存的实体（即使是显式过时的实体）。或者，用户代理可能会习惯性地向每个请求添加“Cache-Control:max-stale=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 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 indicate this state to the user (for example, by a display of a picture of currency in flames) so that the user does not inadvertently consume excess resources or suffer from excessive latency.
如果用户以会异常降低缓存有效性的方式覆盖缓存机制，则用户代理应持续向用户指示该状态（例如，通过显示火焰中的货币图片），以便用户不会无意中消耗过多资源或遭受过多延迟。
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 ought 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) enabling the client software to alert the user that there might be a potential problem.
在某些情况下，缓存的操作员可能会选择将其配置为即使在客户端未请求时也返回过时的响应。不应轻率地做出此决定，但出于可用性或性能的原因，可能有必要做出此决定，尤其是当缓存与源服务器连接不良时。每当缓存返回陈旧响应时，它必须将其标记为陈旧响应（使用警告标头），以使客户端软件能够提醒用户可能存在潜在问题。
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.
它还允许用户代理采取步骤获得第一手或新的响应。因此，如果客户端明确请求第一手或新的响应，则缓存不应返回过时响应，除非由于技术或策略原因无法遵守。
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 might 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.
虽然源服务器（在较小程度上，中间缓存对响应时间的贡献）是过期信息的主要来源，但在某些情况下，客户端可能需要控制缓存是否返回缓存响应而不验证响应的决定。客户机使用缓存控制头的多个指令执行此操作。
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 might violate the origin server's specified constraints on semantic transparency, but might be necessary to support disconnected operation, or high availability in the face of poor connectivity.
客户机还可以指定它将接受过时的响应，最多可接受一定数量的过时响应。这放松了对缓存的限制，因此可能会违反源服务器在语义透明性方面的指定限制，但对于支持断开连接的操作或在连接不良的情况下支持高可用性可能是必需的。
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 response without first contacting the server.
当缓存可以完全避免向源服务器发出请求时，HTTP缓存工作得最好。避免请求的主要机制是源服务器在将来提供一个明确的过期时间，这表明可以使用响应来满足后续请求。换句话说，缓存可以在不首先联系服务器的情况下返回新的响应。
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.
如果源服务器希望强制语义透明缓存验证每个请求，它可能会在过去指定一个明确的过期时间。这意味着响应总是过时的，因此缓存应该在将其用于后续请求之前对其进行验证。有关强制重新验证的更严格方式，请参见第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缓存（无论如何配置）来验证每个请求，则应使用“必须重新验证”缓存控制指令（参见第14.9节）。
Servers specify explicit expiration times using either the Expires header, or the max-age directive of the Cache-Control header.
服务器使用Expires标头或缓存控制标头的max age指令指定显式过期时间。
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 an explanation of the difference between caches and history mechanisms.
过期时间不能用于强制用户代理刷新其显示或重新加载资源；它的语义只适用于缓存机制，当启动对资源的新请求时，这种机制只需要检查资源的过期状态。有关缓存和历史机制之间差异的解释，请参见第13.13节。
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 might compromise semantic transparency, they ought to used cautiously, and we encourage origin servers to provide explicit expiration times as much as possible.
由于源服务器并不总是提供明确的过期时间，HTTP缓存通常分配启发式过期时间，使用使用其他标头值（如上次修改的时间）的算法来估计合理的过期时间。HTTP/1.1规范没有提供特定的算法，但对其结果施加了最坏情况约束。由于启发式过期时间可能会损害语义透明性，因此应谨慎使用，我们鼓励源服务器尽可能提供明确的过期时间。
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.
在本讨论中，我们使用术语“now”来表示“执行计算的主机上时钟的当前值”。使用HTTP的主机，尤其是运行源服务器和缓存的主机，应该使用NTP[28]或某些类似协议将其时钟同步到全局精确的时间标准。
HTTP/1.1 requires origin servers to send a Date header, if possible, with every response, giving the time at which the response was generated (see section 14.18). We use the term "date_value" to denote the value of the Date header, in a form appropriate for arithmetic operations.
HTTP/1.1要求源服务器在可能的情况下为每个响应发送一个日期头，给出生成响应的时间（见第14.18节）。我们使用术语“date_value”表示日期头的值，其形式适合于算术运算。
HTTP/1.1 uses the Age response-header to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's estimate of the amount of time since the response was generated or revalidated by the origin server.
HTTP/1.1使用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.
本质上，时间值是响应沿源服务器路径驻留在每个缓存中的时间加上响应沿网络路径传输的时间之和。
We use the term "age_value" to denote the value of the Age header, in a form appropriate for arithmetic operations.
我们使用术语“age_value”表示age头的值，其形式适合于算术运算。
A response's age can be calculated in two entirely independent ways:
响应的年龄可以通过两种完全独立的方式计算：
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. 现在减去date_值，如果本地时钟与源服务器的时钟同步良好。如果结果为负，则结果将替换为零。
2. age_value, if all of the caches along the response path implement HTTP/1.1.
2. 如果响应路径上的所有缓存都实现HTTP/1.1，则为age_值。
Given that we have two independent ways to compute the age of a response when it is received, we can combine these as
假设我们有两种独立的方法来计算收到响应时的响应时间，我们可以将它们组合为
corrected_received_age = max(now - date_value, age_value)
corrected_received_age = max(now - date_value, age_value)
and as long as we have either nearly synchronized clocks or all-HTTP/1.1 paths, one gets a reliable (conservative) result.
只要我们有几乎同步的时钟或所有HTTP/1.1路径，就可以得到可靠的（保守的）结果。
Because of network-imposed delays, some significant interval might pass between 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:
收到响应的时间。无论经历多少延迟，该算法都会导致保守行为。因此，我们计算：
corrected_initial_age = corrected_received_age + (now - request_time)
更正的\u初始\u年龄=更正的\u接收的\u年龄+（现在-请求\u时间）
where "request_time" is the time (according to the local clock) when the request that elicited this response was sent.
其中“request_time”是引发此响应的请求发送时的时间（根据本地时钟）。
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
*/
/*
* 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);
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;
apparent_age = max(0, response_time - date_value);
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;
The current_age of a cache entry is calculated by adding the amount of time (in seconds) since the cache entry was last validated by the origin server to the corrected_initial_age. When a response is generated from a cache entry, the cache MUST include a single Age header field in the response with a value equal to the cache entry's current_age.
通过将自原始服务器上次验证缓存项以来的时间量（以秒为单位）添加到更正的\u初始\u时间，计算缓存项的当前\u时间。从缓存项生成响应时，缓存必须在响应中包含一个年龄头字段，其值等于缓存项的当前年龄。
The presence of an Age header field in a response implies that a response is not first-hand. However, the converse is not true, since the lack of an Age header field in a response does not imply that the
响应中存在年龄标题字段意味着响应不是第一手的。然而，情况并非如此，因为响应中缺少年龄标头字段并不意味着
response is first-hand unless all caches along the request path are compliant with HTTP/1.1 (i.e., older HTTP caches did not implement the Age header field).
响应是第一手的，除非沿着请求路径的所有缓存都符合HTTP/1.1（即，较旧的HTTP缓存没有实现年龄头字段）。
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.9.3).
我们使用术语“expires\u value”来表示expires头的值。我们使用术语“max_age_value”表示响应中缓存控制头的“max age”指令所携带的秒数的适当值（参见第14.9.3节）。
The max-age directive takes priority over Expires, so if max-age is present in a response, the calculation is simply:
max-age指令优先于Expires，因此如果响应中存在max-age，则计算简单：
freshness_lifetime = max_age_value
freshness_lifetime = max_age_value
Otherwise, if Expires is present in the response, the calculation is:
否则，如果响应中存在Expires，则计算为：
freshness_lifetime = expires_value - date_value
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 none of Expires, Cache-Control: max-age, or Cache-Control: s-maxage (see section 14.9.3) appears in the response, and the response does not include other restrictions on caching, the cache MAY compute a freshness lifetime using a heuristic. The cache MUST attach Warning 113 to any response whose age is more than 24 hours if such warning has not already been added.
如果响应中未出现过期、缓存控制：最大年龄或缓存控制：s-maxage（见第14.9.3节）中的任何一个，并且响应不包括缓存的其他限制，则缓存可以使用启发式方法计算新鲜度生存期。如果尚未添加警告，则缓存必须将警告113附加到任何超过24小时的响应。
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%.
此外，如果响应确实有最后修改的时间，则启发式过期值不应超过自该时间起间隔的某个分数。该分数的典型设置可能为10%。
The calculation to determine if a response has expired is quite simple:
确定响应是否已过期的计算非常简单：
response_is_fresh = (freshness_lifetime > current_age)
response_is_fresh = (freshness_lifetime > current_age)
Because expiration values are assigned optimistically, it is possible for two caches to contain fresh values for the same resource that are different.
由于过期值是按优化方式分配的，因此两个缓存可能包含相同资源的不同新值。
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.
如果执行检索的客户端接收到对其自身缓存中已刷新的请求的非第一手响应，并且其现有缓存项中的日期标头比新响应上的日期新，则客户端可能会忽略该响应。如果是这样，它可能会使用“Cache Control:max age=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 might 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.
如果缓存对具有不同验证器的同一表示有两个新响应，则它必须使用具有较新日期标头的响应。出现这种情况可能是因为缓存正在汇集来自其他缓存的响应，或者是因为客户端请求重新加载或重新验证一个显然是新的缓存条目。
Because a client might 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 might 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.
由于客户端可能通过多个路径接收响应，因此某些响应流经一组缓存，而其他响应流经另一组缓存，因此客户端可能会以不同于源服务器发送响应的顺序接收响应。我们希望客户端使用最新生成的响应，即使旧的响应仍然很新鲜。
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. The Date values are ordered to a granularity of one second.
实体标记和过期值都不能对响应施加排序，因为后面的响应可能故意带有更早的过期时间。日期值按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
当客户端尝试重新验证缓存项，并且它收到的响应包含的日期头似乎比现有项的日期头旧时，客户端应无条件重复该请求，并包括
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.
如果日期值相等，则客户可以使用响应（或者，如果非常谨慎，可以请求新的响应）。如果过期时间重叠，服务器不能依赖于客户端能够在同一秒内生成的响应之间进行决定性选择。
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.
支持条件方法的关键协议特性与“缓存验证器”有关。当源服务器生成完整响应时，它会向其附加某种验证器，该验证器与缓存条目一起保存。当客户端（用户代理或代理缓存）对其具有缓存项的资源发出有条件请求时，它会在请求中包含关联的验证器。
The server then checks that validator against the current validator for the entity, and, if they match (see section 13.3.3), 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.
然后，服务器根据实体的当前验证器检查该验证器，如果它们匹配（请参见第13.3.3节），它将以特殊状态代码（通常为304（未修改））响应，并且没有实体主体。否则，它将返回完整响应（包括实体体）。因此，如果验证器匹配，我们将避免传输完整响应，如果验证器不匹配，我们将避免额外的往返。
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中，条件请求看起来与对相同资源的正常请求完全相同，只是它带有一个特殊的头（包括验证器），该头隐式地将方法（通常是GET）转换为条件请求。
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.
该协议包括缓存验证条件的积极意义和消极意义。也就是说，当且仅当验证器匹配或当且仅当没有验证器匹配时，可以请求执行方法。
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.
注意：缺少验证器的响应仍然可以缓存，并从缓存提供服务，直到过期，除非缓存控制指令明确禁止这样做。但是，如果缓存没有实体的验证器，则无法执行条件检索，这意味着它在过期后将无法刷新。
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.
最后修改的实体头字段值通常用作缓存验证器。简单地说，如果实体自上次修改值后未被修改，则认为缓存项有效。
The ETag response-header field value, an entity tag, provides for an "opaque" cache validator. This might 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 might arise from the use of modification dates.
ETag响应头字段值是一个实体标记，提供了一个“不透明”缓存验证器。在不方便存储修改日期、HTTP日期值的1秒解析不够、或者源服务器希望避免使用修改日期可能产生的某些矛盾的情况下，这可能允许更可靠的验证。
Entity Tags are described in section 3.11. The headers used with entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
第3.11节描述了实体标签。第14.19、14.24、14.26和14.44节描述了与实体标记一起使用的标题。
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."
由于源服务器和缓存都会比较两个验证器，以确定它们代表的是相同的还是不同的实体，因此人们通常认为，如果实体（实体主体或任何实体头）以任何方式发生更改，那么关联的验证器也会更改。如果这是真的，那么我们称这个验证器为“强验证器”
However, there might be cases when a server prefers to change the validator only on semantically significant changes, and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak 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.
实体标记通常是“强验证器”，但协议提供了一种将实体标记标记为“弱”的机制。人们可以将强验证器视为在实体的位发生更改时更改的验证器，而弱值在实体的含义发生更改时更改。或者，可以将强验证器视为特定实体标识符的一部分，而弱验证器是语义等价实体集合标识符的一部分。
Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
注意：强验证器的一个例子是一个整数，它在稳定存储中每次更改实体时都会递增。
An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.
一个实体的修改时间，如果用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.
对弱验证器的支持是可选的。然而，弱验证器允许更有效地缓存等价对象；例如，如果网站上的点击计数器每隔几天或几周更新一次，那么它可能已经足够好了，而这段时间内的任何值都可能“足够好”到相等。
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.
验证器的“使用”是指当客户端生成请求并将验证器包含在验证头字段中时，或者当服务器比较两个验证器时。
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 might end up with an internally inconsistent entity.
强验证器在任何上下文中都是可用的。弱验证器仅在不依赖于实体完全相等的上下文中可用。例如，任何一种都可用于完整实体的条件GET。但是，只有强验证器可用于子范围检索，因为否则客户端可能最终会得到一个内部不一致的实体。
Clients MAY issue simple (non-subrange) GET requests with either weak validators or strong validators. Clients MUST NOT use weak validators in other forms of request.
客户端可以使用弱验证器或强验证器发出简单（非子范围）GET请求。客户端不得在其他形式的请求中使用弱验证器。
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协议在验证器上定义的唯一功能是比较。根据比较上下文是否允许使用弱验证器，有两个验证器比较函数：
- The strong comparison function: in order to be considered equal, both validators MUST be identical in every way, and both MUST NOT be weak.
- 强比较函数：为了被认为是相等的，两个验证器在各个方面都必须是相同的，并且都不能是弱的。
- 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.
- 弱比较函数：为了被认为是相等的，两个验证器在各个方面都必须相同，但其中一个或两个都可以标记为“弱”，而不影响结果。
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:
当在请求中用作验证器时，上一次修改的时间隐式弱，除非可以使用以下规则推断它是强的：
- The validator is being compared by an origin server to the actual current validator for the entity and,
- 源服务器正在将验证程序与实体的实际当前验证程序进行比较，
- That origin server reliably knows that the associated entity did not change twice during the second covered by the presented validator.
- 该源服务器可靠地知道关联实体在所提供的验证器覆盖的第二个过程中没有两次更改。
or
或
- 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
- 验证程序将由客户端在If-Modified-Since或If-Unmodified-Since头中使用，因为客户端具有关联实体的缓存项，并且
- That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
- 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
- The presented Last-Modified time is at least 60 seconds before the Date value.
- 显示的上次修改时间至少比日期值早60秒。
or
或
- The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and
- 中间缓存正在将验证程序与存储在实体缓存项中的验证程序进行比较，以及
- That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
- 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
- The presented Last-Modified time is at least 60 seconds before the Date value.
- 显示的上次修改时间至少比日期值早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.
此方法依赖于这样一个事实：如果源服务器在同一秒钟内发送了两个不同的响应，但都具有相同的上次修改时间，则这些响应中至少有一个的日期值等于其上次修改的时间。任意的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.
如果客户机希望对其只有上次修改时间且没有不透明验证器的值执行子范围检索，则只有在上次修改时间在此处描述的意义上很强时，客户机才可以这样做。
A cache or origin server receiving a 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
这些规则允许HTTP/1.1缓存和客户端安全地对从HTTP/1.0获得的值执行子范围检索
servers.
服务器。
We adopt a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types ought to be used, and for what purposes.
对于源服务器、客户端和缓存，我们采用了一组规则和建议，以确定何时应该使用各种验证程序类型，以及用于什么目的。
HTTP/1.1 origin servers:
HTTP/1.1源服务器：
- SHOULD send an entity tag validator unless it is not feasible to generate one.
- 应发送实体标记验证程序，除非生成实体标记验证程序不可行。
- 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.
- 如果性能考虑支持使用弱实体标记，或者如果无法发送强实体标记，则可以发送弱实体标记而不是强实体标记。
- 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.
- 如果发送一个值是可行的，则应发送一个上次修改的值，除非在if-Modified-Since头中使用此日期可能导致语义透明度崩溃的风险会导致严重问题。
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.
为了合法，无论何时关联的实体值以任何方式发生更改，都必须更改强实体标记。弱实体标记应该在关联实体以语义上重要的方式更改时更改。
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 might persist for arbitrarily long periods, regardless of expiration times, so it might 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.
注意：为了提供语义透明的缓存，源服务器必须避免为两个不同的实体重用特定的强实体标记值，或为两个语义不同的实体重用特定的弱实体标记值。缓存项可能会持续任意长的时间，而不管过期时间如何，因此，期望缓存不会再次尝试使用在过去某个时间获得的验证器来验证项可能是不合适的。
HTTP/1.1 clients:
HTTP/1.1客户端：
- 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).
- 如果源服务器提供了实体标记，则必须在任何缓存条件请求中使用该实体标记（使用If-Match或If-None-Match）。
- 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).
- 如果源服务器只提供了上次修改的值，则应在非子范围缓存条件请求中使用该值（使用If-Modified-Since）。
- 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.
- 如果HTTP/1.0源服务器只提供了上次修改的值，则可以在子范围缓存条件请求中使用该值（使用If Unmodified Since:）。如果遇到困难，用户代理应该提供一种禁用此功能的方法。
- 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.
- 如果源服务器同时提供了实体标记和上次修改的值，则应该在缓存条件请求中使用这两个验证器。这使得HTTP/1.0和HTTP/1.1缓存都能做出适当的响应。
An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request.
HTTP/1.1源服务器在接收到包括最后修改日期（例如，在If Modified Since或If Unmodified Since标头字段中）和一个或多个实体标记（例如，在If Match、If None Match或If Range标头字段中）作为缓存验证器的有条件请求时，不得返回304（未修改）的响应状态除非这样做与请求中的所有条件头字段一致。
An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity tags as cache validators, MUST NOT return a locally cached response to the client unless that cached response is consistent with all of the conditional header fields in the request.
HTTP/1.1缓存代理在接收到包括最后修改日期和一个或多个实体标记作为缓存验证器的条件请求时，不得向客户端返回本地缓存响应，除非该缓存响应与请求中的所有条件头字段一致。
Note: 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系统将对其接收的验证器做出最保守的假设。
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系统使用最后修改的值作为验证器可能会导致严重问题，那么HTTP/1.1源服务器不应该提供验证器。
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.
实体标记背后的原理是，只有服务作者才能充分了解资源的语义，以选择适当的缓存验证机制，而任何比字节相等更复杂的验证器比较函数的规范都会引发一系列蠕虫。因此，任何其他头的比较（除了上次修改，以与HTTP/1.0兼容）都不会用于验证缓存项。
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 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.
除非受到缓存控制（第14.9节）指令的特别约束，否则缓存系统可能始终将成功响应（请参阅第13.8节）存储为缓存项，如果响应是新的，则可以在未经验证的情况下返回，并且可以在成功验证后返回。如果既没有缓存验证器，也没有与响应关联的显式过期时间，则我们不希望缓存响应，但某些缓存可能会违反此预期（例如，当网络连接很少或没有可用时）。客户机通常可以通过比较日期头和当前时间来检测这样的响应是否来自缓存。
Note: some HTTP/1.0 caches are known to violate this expectation without providing any Warning.
注意：一些HTTP/1.0缓存已知会违反此预期，而不提供任何警告。
However, in some cases it might be inappropriate for a cache to retain an entity, or to return it in response to a subsequent request. This might 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, are not to be cached regardless of other considerations.
但是，在某些情况下，缓存保留实体或返回实体以响应后续请求可能是不合适的。这可能是因为服务作者认为绝对语义透明是必要的，或者是出于安全或隐私考虑。因此，提供了某些缓存控制指令，以便服务器可以指示不缓存某些资源实体或其部分，而不考虑其他因素。
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节通常阻止共享缓存保存并返回对前一请求的响应（如果该请求包含授权标头）。
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的响应可由缓存存储并用于响应后续请求，但受到期机制的约束，除非缓存控制指令禁止缓存。但是，不支持范围和内容范围标头的缓存不得缓存206（部分内容）响应。
A response received with any other status code (e.g. status codes 302 and 307) 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", "s-maxage", "must-revalidate", "proxy-revalidate", "public" or "private" cache-control directive (section 14.9).
使用任何其他状态代码（例如状态代码302和307）接收的响应不得在对后续请求的答复中返回，除非存在明确允许它的缓存控制指令或其他标头。例如，这些包括以下内容：Expires标头（第14.21节）；“最大年龄”、“s-maxage”、“必须重新验证”、“代理重新验证”、“公共”或“私有”缓存控制指令（第14.9节）。
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 might have to combine parts of a new response with what is held in the cache entry.
HTTP缓存的目的是存储在响应请求时接收的信息，以用于响应未来的请求。在许多情况下，缓存只是将响应的适当部分返回给请求者。但是，如果缓存基于以前的响应保存缓存项，则可能必须将新响应的部分内容与缓存项中保存的内容结合起来。
For the purpose of defining the behavior of caches and non-caching proxies, we divide HTTP headers into two categories:
为了定义缓存和非缓存代理的行为，我们将HTTP头分为两类：
- End-to-end headers, which are 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 MUST be transmitted in any response formed from a cache entry.
- 端到端头，传输到请求或响应的最终接收者。响应中的端到端头必须作为缓存项的一部分存储，并且必须在由缓存项形成的任何响应中传输。
- Hop-by-hop headers, which are meaningful only for a single transport-level connection, and are not stored by caches or forwarded by proxies.
- 逐跳标头，仅对单个传输级别连接有意义，不通过缓存存储或代理转发。
The following HTTP/1.1 headers are hop-by-hop headers:
以下HTTP/1.1标头是逐跳标头：
- Connection - Keep-Alive - Proxy-Authenticate - Proxy-Authorization - TE - Trailers - Transfer-Encoding - Upgrade
- 连接-保持活动状态-代理身份验证-代理授权-TE-拖车-传输编码-升级
All other headers defined by HTTP/1.1 are end-to-end headers.
HTTP/1.1定义的所有其他头都是端到端头。
Other hop-by-hop headers MUST be listed in a Connection header, (section 14.10) to be introduced into HTTP/1.1 (or later).
其他逐跳标头必须列在连接标头（第14.10节）中，以引入HTTP/1.1（或更高版本）。
Some features of the HTTP/1.1 protocol, such as Digest Authentication, depend on the value of certain end-to-end headers. A transparent proxy SHOULD NOT modify an end-to-end header unless the definition of that header requires or specifically allows that.
HTTP/1.1协议的某些功能，例如摘要身份验证，取决于某些端到端头的值。透明代理不应修改端到端头，除非该头的定义要求或特别允许修改。
A transparent proxy MUST NOT modify any of the following fields in a request or response, and it MUST NOT add any of these fields if not already present:
透明代理不得修改请求或响应中的以下任何字段，如果这些字段尚未出现，则不得添加任何字段：
- Content-Location
- 内容位置
- Content-MD5
- Content-MD5
- ETag
- 埃塔格
- Last-Modified
- 最后修改
A transparent proxy MUST NOT modify any of the following fields in a response:
透明代理不得修改响应中的以下任何字段：
- Expires
- 到期
but it MAY add any of these fields if not already present. If an Expires header is added, it MUST be given a field-value identical to that of the Date header in that response.
但它可以添加这些字段中的任何一个（如果尚未存在）。如果添加了Expires标头，则必须为其指定与该响应中的日期标头相同的字段值。
A proxy MUST NOT modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request:
代理不得在包含no transform cache control指令的消息或任何请求中修改或添加以下任何字段：
- Content-Encoding
- 内容编码
- Content-Range
- 内容范围
- Content-Type
- 内容类型
A non-transparent proxy MAY modify or add these fields to a message that does not include no-transform, but if it does so, it MUST add a Warning 214 (Transformation applied) if one does not already appear in the message (see section 14.46).
不透明代理可以修改这些字段或将其添加到不包含任何转换的消息中，但如果这样做，则必须添加警告214（已应用转换），如果消息中尚未出现警告214（请参阅第14.46节）。
Warning: unnecessary modification of end-to-end headers might 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中引入更强大的身份验证机制，则对端到端头进行不必要的修改可能会导致身份验证失败。此类认证机制可能依赖于此处未列出的头字段的值。
The Content-Length field of a request or response is added or deleted according to the rules in section 4.4. A transparent proxy MUST preserve the entity-length (section 7.2.2) of the entity-body, although it MAY change the transfer-length (section 4.4).
根据第4.4节中的规则添加或删除请求或响应的内容长度字段。透明代理必须保留实体主体的实体长度（第7.2.2节），尽管它可能会更改传输长度（第4.4节）。
When a cache makes a validating request to a server, and the server provides a 304 (Not Modified) response or a 206 (Partial Content) response, the cache then constructs a response to send to the requesting client.
当缓存向服务器发出验证请求，并且服务器提供304（未修改）响应或206（部分内容）响应时，缓存随后构造响应以发送到请求客户端。
If the status code is 304 (Not Modified), the cache uses the entity-body stored in the cache entry as the entity-body of this outgoing response. If the status code is 206 (Partial Content) and the ETag or Last-Modified headers match exactly, the cache MAY combine the contents stored in the cache entry with the new contents received in the response and use the result as the entity-body of this outgoing response, (see 13.5.4).
如果状态代码为304（未修改），缓存将使用缓存条目中存储的实体体作为该传出响应的实体体。如果状态代码为206（部分内容），且ETag或Last Modified标头完全匹配，则缓存可将缓存条目中存储的内容与响应中接收到的新内容相结合，并将结果用作该传出响应的实体体（见13.5.4）。
The end-to-end headers stored in the cache entry are used for the constructed response, except that
缓存项中存储的端到端头用于构造响应，但以下情况除外：
- any stored Warning headers with warn-code 1xx (see section 14.46) MUST be deleted from the cache entry and the forwarded response.
- 必须从缓存条目和转发响应中删除任何存储的警告标题（警告代码1xx）（参见第14.46节）。
- any stored Warning headers with warn-code 2xx MUST be retained in the cache entry and the forwarded response.
- 任何存储的带有警告代码2xx的警告标头必须保留在缓存条目和转发的响应中。
- any end-to-end headers provided in the 304 or 206 response MUST replace the corresponding headers from the cache entry.
- 304或206响应中提供的任何端到端头都必须替换缓存项中的相应头。
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, except for Warning headers as described immediately above. If a header field-name in the incoming response matches more than one header in the cache entry, all such old headers MUST be replaced.
除非缓存决定删除缓存项，否则它还必须用传入响应中接收到的相应头替换存储在缓存项中的端到端头，上文所述的警告头除外。如果传入响应中的标头字段名称与缓存项中的多个标头匹配，则必须替换所有此类旧标头。
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 (except for stored Warning headers with warn-code 1xx, which are deleted even if not overridden).
换句话说，传入响应中接收到的端到端头集覆盖与缓存项一起存储的所有对应端到端头（存储的警告代码为1xx的警告头除外，即使未被覆盖也会被删除）。
Note: this rule allows an origin server to use a 304 (Not Modified) or a 206 (Partial Content) response to update any header associated with a previous response for the same entity or sub-ranges thereof, 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) or a 206 (Partial Content) response to entirely delete a header that it had provided with a previous response.
注意：此规则允许源服务器使用304（未修改）或206（部分内容）响应来更新与同一实体或其子范围的先前响应相关联的任何头，尽管这样做可能并不总是有意义或正确的。此规则不允许源服务器使用304（未修改）或206（部分内容）响应来完全删除其在先前响应中提供的头。
A response might 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 might have received several ranges of the same entity-body.
响应可能只传输实体体字节的子范围，这可能是因为请求包含一个或多个范围规范，或者是因为连接过早中断。在多次这样的传输之后，缓存可能已经接收到同一实体的多个范围。
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:
如果缓存具有存储的实体的非空子范围集，并且传入响应传输另一个子范围，则如果满足以下两个条件，则缓存可以将新子范围与现有子范围集组合：
- Both the incoming response and the cache entry have a cache validator.
- 传入响应和缓存项都有一个缓存验证器。
- The two cache validators match using the strong comparison function (see section 13.3.3).
- 两个缓存验证器使用强比较功能进行匹配（参见第13.3.3节）。
If either requirement is not met, 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.
如果未满足任一要求，缓存必须仅使用最近的部分响应（基于随每个响应一起传输的日期值，如果这些值相等或缺失，则使用传入响应），并且必须丢弃其他部分信息。
Use of server-driven content negotiation (section 12.1), 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. See section 14.44 for use of the Vary header field by servers.
服务器驱动的内容协商（第12.1节）的使用，如响应中的Vary header字段所示，改变了缓存可以将响应用于后续请求的条件和过程。请参阅第14.44节，了解服务器对“更改标头”字段的使用情况。
A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers.
服务器应使用Vary header字段通知缓存使用了哪些请求头字段来从受服务器驱动协商影响的可缓存响应的多个表示中进行选择。由Vary字段值命名的头字段集称为“selecting”请求头。
When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers present in the new request match the corresponding stored request-headers in the original request.
当缓存接收到后续请求时，其请求URI指定了一个或多个缓存条目，包括一个Vary头字段，除非新请求中存在的所有选择请求标头与原始请求中相应存储的请求标头匹配，否则缓存不得使用此类缓存项来构造对新请求的响应。
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
当且仅当第一个请求中的selecting请求头可以转换为第二个请求中的selecting请求头时，两个请求中的selecting请求头被定义为匹配
by adding or removing linear white space (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.
通过在相应BNF允许的位置添加或删除线性空白（LWS），和/或按照第4.2节中关于消息头的规则将多个消息头字段与相同字段名组合。
A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.
Vary header字段值“*”始终无法匹配，对该资源的后续请求只能由源服务器正确解释。
If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first 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 the entity to be used.
如果缓存项的selecting request header字段与新请求的selecting request header字段不匹配，则缓存不得使用缓存项来满足请求，除非它首先在条件请求中将新请求中继到源服务器，并且服务器响应304（未修改），包括指示要使用的实体的实体标记或内容位置。
If an entity tag was assigned to a cached 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 resource. 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 field 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 new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
如果实体标记被分配给缓存的表示，则转发的请求应该是有条件的，并将实体标记包含在资源所有缓存项的If None Match头字段中。这将向服务器传送缓存当前持有的一组实体，以便如果这些实体中的任何一个与请求的实体匹配，服务器可以在其304（未修改）响应中使用ETag头字段来告诉缓存哪个条目是合适的。如果新响应的实体标记与现有条目的实体标记匹配，则应使用新响应更新现有条目的标题字段，并且必须将结果返回给客户端。
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 field unless the request is for a range that would be fully satisfied by that entry.
如果任何现有缓存项仅包含关联实体的部分内容，则其实体标记不应包含在If None Match标头字段中，除非请求的范围将由该项完全满足。
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.
如果缓存接收到一个成功响应，其内容位置字段与同一请求-]URI的现有缓存项的内容位置字段匹配，其实体标记与现有项的实体标记不同，并且其日期比现有项的日期更晚，现有条目不应返回以响应将来的请求，而应从缓存中删除。
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.
本规范对共享缓存的操作施加了某些限制，以防止隐私丢失或访问控制失败。
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).
接收不完整响应（例如，数据字节数少于内容长度头中指定的字节数）的缓存可能会存储该响应。但是，缓存必须将其视为部分响应。部分响应可按第13.5.4节所述进行组合；结果可能是完整响应，也可能仍然是部分响应。缓存在未使用206（部分内容）状态代码明确标记的情况下，不得向客户端返回部分响应。缓存不能使用状态代码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, 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).
如果缓存在尝试重新验证条目时收到5xx响应，它可能会将此响应转发给请求的客户端，或者表现为服务器未能响应。在后一种情况下，它可能会返回以前接收到的响应，除非缓存条目包含“必须重新验证”缓存控制指令（参见第14.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和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 URIs 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.
我们注意到这条规则的一个例外：由于一些应用程序传统上使用带有查询URL的GET和HEAD（那些在rel_路径部分包含“？”的）来执行具有显著副作用的操作，除非服务器提供明确的过期时间，否则缓存不能将对此类URI的响应视为新响应。这特别意味着HTTP/1.0服务器对此类URI的响应不应从缓存中获取。相关信息见第9.1.1节。
The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource.
对源服务器上的资源执行的某些方法可能会导致一个或多个现有缓存项变为非透明无效。也就是说，尽管它们可能仍然是“新鲜的”，但它们并不能准确地反映源服务器将为该资源上的新请求返回什么。
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 might 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 will either remove all instances of that entity from its storage, or will mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request.
在本节中，短语“使实体无效”表示缓存将从其存储中删除该实体的所有实例，或将这些实例标记为“无效”，并需要强制重新验证，然后才能返回这些实例以响应后续请求。
Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are:
某些HTTP方法必须导致缓存使实体无效。这是请求URI或位置或内容位置头（如果存在）引用的实体。这些方法是：
- PUT
- 放
- DELETE
- 删去
- POST
- 邮递
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.
为了防止拒绝服务攻击，只有在主机部分与请求URI相同时，才能基于位置或内容位置标头中的URI执行失效。
A cache that passes through requests for methods it does not understand SHOULD invalidate any entities referred to by the Request-URI.
通过对其不理解的方法的请求的缓存应该使请求URI引用的任何实体无效。
All methods that might 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 proxy cache from sending a 100 (Continue) response before the inbound server has sent its final reply.
所有可能导致修改源服务器资源的方法都必须写入源服务器。这目前包括除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中不允许使用这种替代方法（称为“写回”或“复制回”缓存），因为很难提供一致的更新，并且在写回之前服务器、缓存或网络故障会导致问题。
If a new cacheable (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 the rules in section 13.5.3 apply.
如果在缓存相同资源的任何现有响应时，从资源接收到新的可缓存响应（请参见第14.9.2、13.2.5、13.2.6和13.8节），则缓存应使用新响应来响应当前请求。它可以将其插入缓存中，如果它满足所有其他要求，则可以使用它来响应以前可能导致返回旧响应的任何未来请求。如果将新响应插入缓存，则第13.5.3节中的规则适用。
Note: a new response that has an older Date header value than existing cached responses is not cacheable.
注意：不能缓存日期头值比现有缓存响应旧的新响应。
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.
用户代理通常具有历史记录机制，例如“后退”按钮和历史记录列表，可用于重新显示会话中先前检索到的实体。
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.
历史机制和缓存是不同的。尤其是历史机制不应该试图显示资源当前状态的语义透明视图。相反，历史机制旨在准确显示用户在检索资源时看到的内容。
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 is not to be construed to prohibit the history mechanism from telling the user that a view might 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头字段的语法和语义。对于实体标题字段，发送者和接收者都指客户端或服务器，具体取决于谁发送和谁接收实体。
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 request header字段可用于指定响应可接受的某些媒体类型。Accept标头可用于指示请求仅限于一小部分所需的类型，如请求内嵌图像的情况。
Accept = "Accept" ":" #( media-range [ accept-params ] )
Accept=“Accept”“：”#（媒体范围[接受参数]）
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
accept-extension = ";" token [ "=" ( token | quoted-string ) ]
media-range = ( "*/*"
| ( type "/" "*" )
| ( type "/" subtype )
) *( ";" parameter )
accept-params = ";" "q" "=" qvalue *( accept-extension )
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.
星号“*”字符用于将媒体类型分为不同的范围，“*/*”表示所有媒体类型，“type/*”表示该类型的所有子类型。介质范围可包括适用于该范围的介质类型参数。
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.
每个媒体范围后面可能有一个或多个accept参数，从“q”参数开始，用于指示相对质量因数。第一个“q”参数（如果有）将介质范围参数与接受参数分开。质量因素允许用户或用户代理使用0到1的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 are discouraged from registering any parameter named "q".
注意：使用“q”参数名称将介质类型参数与接受扩展参数分开是由于历史惯例。尽管这会阻止任何名为“q”的媒体类型参数与媒体范围一起使用，但考虑到IANA媒体类型注册表中缺少任何“q”参数，并且在Accept中很少使用任何媒体类型参数，这样的事件不太可能发生。不鼓励将来的媒体类型注册任何名为“q”的参数。
The example
榜样
Accept: audio/*; q=0.2, audio/basic
Accept: audio/*; q=0.2, audio/basic
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."
应解释为“我更喜欢音频/基本，但如果在质量降低80%后是最好的，请发送任何音频类型给我。”
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字段值可接受的响应，则服务器应发送406（不可接受）响应。
A more elaborate example is
一个更详细的例子是
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c
Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/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."
口头上，这将被解释为“text/html和text/x-c是首选媒体类型，但如果它们不存在，则发送text/x-dvi实体，如果不存在，则发送text/plain实体。”
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,
介质范围可以被更具体的介质范围或介质类型覆盖。如果给定类型适用多个媒体范围，则最特定的引用优先。例如
Accept: text/*, text/html, text/html;level=1, */*
Accept: text/*, text/html, text/html;level=1, */*
have the following precedence:
具有以下优先权：
1) text/html;level=1
2) text/html
3) text/*
4) */*
1) text/html;level=1
2) text/html
3) text/*
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
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=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
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
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
Note: A user agent might 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, this default set ought to be configurable by the user.
注意：用户代理可能会为某些媒体范围提供一组默认的质量值。但是，除非用户代理是无法与其他渲染代理交互的封闭系统，否则此默认设置应由用户配置。
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.
Accept Charset request header字段可用于指示响应可接受的字符集。此字段允许能够理解更全面或特殊用途字符集的客户端向能够在这些字符集中表示文档的服务器发送该功能的信号。
Accept-Charset = "Accept-Charset" ":"
1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
Accept-Charset = "Accept-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节描述了字符集值。每个字符集可以被赋予一个相关的质量值，该值表示用户对该字符集的偏好。默认值为q=1。例如
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, matches every character set (including ISO-8859-1) which is not mentioned elsewhere in the Accept-Charset field. If no "*" is present in an Accept-Charset field, then all character sets not explicitly mentioned get a quality value of 0, except for ISO-8859-1, which gets a quality value of 1 if not explicitly mentioned.
特殊值“*”如果存在于Accept字符集字段中，则与Accept字符集字段中未提及的每个字符集（包括ISO-8859-1）匹配。如果Accept字符集字段中不存在“*”，则所有未明确提及的字符集的质量值均为0，ISO-8859-1除外，ISO-8859-1的质量值为1（如果未明确提及）。
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字符集标头，则默认情况下任何字符集都是可接受的。如果存在Accept Charset标头，并且如果服务器无法发送根据Accept Charset标头可接受的响应，则服务器应发送带有406（不可接受）状态代码的错误响应，但也允许发送不可接受的响应。
The Accept-Encoding request-header field is similar to Accept, but restricts the content-codings (section 3.5) that are acceptable in the response.
Accept Encoding请求标头字段类似于Accept，但限制响应中可接受的内容编码（第3.5节）。
Accept-Encoding = "Accept-Encoding" ":"
接受编码=“接受编码”：
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
1#( codings [ ";" "q" "=" qvalue ] )
codings = ( content-coding | "*" )
Examples of its use are:
例如：
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:
服务器根据接受编码字段，使用以下规则测试内容编码是否可接受：
1. If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in section 3.9, a qvalue of 0 means "not acceptable.")
1. 如果内容编码是Accept Encoding（接受编码）字段中列出的内容编码之一，则它是可接受的，除非它附带Q值0。（如第3.9节所定义，Q值为0表示“不可接受”。）
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
2. 接受编码字段中的特殊“*”符号与头字段中未明确列出的任何可用内容编码匹配。
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
3. 如果可接受多个内容编码，则首选具有最高非零Q值的可接受内容编码。
4. The "identity" content-coding is always acceptable, unless specifically refused because the Accept-Encoding field includes "identity;q=0", or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
4. “标识”内容编码始终是可接受的，除非因为“接受编码”字段包含“标识；q=0”或因为该字段包含“*；q=0”而未明确包含“标识”内容编码而被拒绝。如果接受编码字段值为空，则仅接受“标识”编码。
If an Accept-Encoding field is present in a request, 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.
如果请求中存在接受编码字段，并且根据接受编码标头，服务器无法发送可接受的响应，则服务器应发送带有406（不可接受）状态代码的错误响应。
If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
如果请求中不存在接受编码字段，服务器可能会假定客户端将接受任何内容编码。在这种情况下，如果“标识”是可用的内容编码之一，那么服务器应该使用“标识”内容编码，除非它有其他信息表明不同的内容编码对客户端有意义。
Note: If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings commonly understood by HTTP/1.0 clients (i.e.,
注意：如果请求不包括接受编码字段，并且“标识”内容编码不可用，则HTTP/1.0客户端通常理解的内容编码（即。，
"gzip" and "compress") are preferred; some older clients improperly display messages sent with other content-codings. The server might also make this decision based on information about the particular user-agent or client.
首选“gzip”和“compress”）；一些旧客户端不正确地显示与其他内容编码一起发送的消息。服务器还可能根据有关特定用户代理或客户端的信息做出此决定。
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will not work and are not permitted with x-gzip or x-compress.
注意：大多数HTTP/1.0应用程序不识别或不遵守与内容编码相关的QValue。这意味着QValue将不起作用，并且不允许使用x-gzip或x-compress。
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. Language tags are defined in section 3.10.
Accept Language request header字段类似于Accept，但限制了作为请求响应首选的自然语言集。第3.10节定义了语言标记。
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
Accept-Language = "Accept-Language" ":"
1#( language-range [ ";" "q" "=" qvalue ] )
language-range = ( ( 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
Accept-Language: da, en-gb;q=0.8, en;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.
意思是：“我更喜欢丹麦语，但会接受英式英语和其他类型的英语。”如果语言范围与标记完全相等，或者如果它与标记的前缀完全相等，那么前缀后面的第一个标记字符是“-”，则该语言范围与语言标记匹配。特殊范围“*”如果存在于Accept Language字段中，则与Accept Language字段中任何其他范围都不匹配的每个标记相匹配。
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
Accept language字段分配给语言标记的语言质量因子是字段中与语言标记匹配的最长语言范围的质量值。如果字段中没有与标记匹配的语言范围，则指定的语言质量因子为0。如果请求中不存在Accept Language标头，则服务器
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 Language标头，则指定的质量因子大于0的所有语言都是可接受的。
It might 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 section 15.1.4.
在每个请求中发送包含用户完整语言偏好的Accept Language标头可能与用户的隐私期望相反。有关此问题的讨论，请参见第15.1.4节。
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 Language header字段。
Note: When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest in such a case to add "en" to get the best matching behavior.
注：当用户选择语言偏好时，我们提醒实施者用户不熟悉上述语言匹配的细节，并应提供适当的指导。例如，用户可能会假设在选择“en gb”时，如果没有英式英语，他们将收到任何类型的英语文档。在这种情况下，用户代理可能会建议添加“en”以获得最佳匹配行为。
The Accept-Ranges response-header field allows the server to indicate its acceptance of range requests for a resource:
Accept Ranges response header字段允许服务器指示其接受资源的范围请求：
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges = 1#range-unit | "none"
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. Range units are defined in section 3.12.
但不需要这样做。客户端可能会生成字节范围请求，而不会收到所涉及资源的此标头。范围单位在第3.12节中定义。
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.
建议客户不要尝试范围请求。
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 response header字段表示发件人对自原始服务器上生成响应（或其重新验证）以来的时间量的估计。如果缓存响应的时间未超过其新鲜度生存期，则该响应为“新鲜”。按照第13.2.3节的规定计算年龄值。
Age = "Age" ":" age-value age-value = delta-seconds
Age=“Age”“：“Age value Age value=增量秒
Age values are non-negative decimal integers, representing time in seconds.
年龄值是非负十进制整数，以秒为单位表示时间。
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). An HTTP/1.1 server that includes a cache MUST include an Age header field in every response generated from its own cache. Caches SHOULD use an arithmetic type of at least 31 bits of range.
如果缓存接收到的值大于其可以表示的最大正整数，或者如果其任何年龄计算溢出，则必须传输值为2147483648（2^31）的年龄标头。包含缓存的HTTP/1.1服务器必须在从其自身缓存生成的每个响应中包含年龄头字段。缓存应使用至少31位范围的算术类型。
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 entity header字段列出由请求URI标识的资源支持的方法集。此字段的用途严格来说是通知收件人与资源关联的有效方法。405（方法不允许）响应中必须存在允许标头字段。
Allow = "Allow" ":" #Method
Allow = "Allow" ":" #Method
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 header字段值给出的指示。实际允许的方法集由源服务器在每次请求时定义。
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头，给出实际支持的方法。
A proxy MUST NOT modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other means of communicating with the origin server.
代理即使不理解所有指定的方法，也不能修改Allow header字段，因为用户代理可能有其他与源服务器通信的方式。
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--does 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 = "Authorization" ":" credentials
Authorization=“Authorization”“：”凭据
HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).
HTTP访问身份验证在“HTTP身份验证：基本和摘要访问身份验证”[43]中进行了描述。如果对请求进行了身份验证并指定了域，则相同的凭据对于该域中的所有其他请求都应有效（假设身份验证方案本身不需要其他凭据，例如根据质询值或使用同步时钟而变化的凭据）。
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节）接收到包含授权字段的请求时，它不得将相应的响应作为对任何其他请求的答复返回，除非存在以下特定异常之一：
1. If the response includes the "s-maxage" cache-control directive, the cache MAY use that response in replying to a subsequent request. But (if the specified maximum age has passed) 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. (This is the defined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy MUST always revalidate it before re-using it.
1. 如果响应包括“s-maxage”缓存控制指令，则缓存可以使用该响应来响应后续请求。但是（如果已超过指定的最长期限），代理缓存必须首先使用新请求的请求头与源服务器重新验证它，以允许源服务器对新请求进行身份验证。（这是为s-maxage定义的行为。）如果响应包含“s-maxage=0”，则代理必须始终在重新使用它之前重新验证它。
2. If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, 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.
2. 如果响应包含“必须重新验证”缓存控制指令，则缓存可以在响应后续请求时使用该响应。但是，如果响应过时，所有缓存必须首先使用新请求的请求头与源服务器重新验证它，以允许源服务器对新请求进行身份验证。
3. If the response includes the "public" cache-control directive, it MAY be returned in reply to any subsequent request.
3. 如果响应包含“public”cache control指令，则可以返回该指令以响应任何后续请求。
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 is to be given in the response.
Cache Control general header字段用于指定请求/响应链上所有缓存机制必须遵守的指令。这些指令指定了旨在防止缓存对请求或响应产生不利干扰的行为。这些指令通常覆盖默认的缓存算法。缓存指令是单向的，因为请求中存在指令并不意味着响应中将给出相同的指令。
Note that HTTP/1.0 caches might not implement Cache-Control and might only implement Pragma: no-cache (see section 14.32).
请注意，HTTP/1.0缓存可能不会实现缓存控制，而可能只实现Pragma:no Cache（请参阅第14.32节）。
Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might 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
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive | cache-response-directive
缓存指令=缓存请求指令|缓存响应指令
cache-request-directive =
"no-cache" ; Section 14.9.1
| "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6
cache-request-directive =
"no-cache" ; Section 14.9.1
| "no-store" ; Section 14.9.2
| "max-age" "=" delta-seconds ; Section 14.9.3, 14.9.4
| "max-stale" [ "=" delta-seconds ] ; Section 14.9.3
| "min-fresh" "=" delta-seconds ; Section 14.9.3
| "no-transform" ; Section 14.9.5
| "only-if-cached" ; Section 14.9.4
| cache-extension ; Section 14.9.6
cache-response-directive =
"public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6
cache-response-directive =
"public" ; Section 14.9.1
| "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
| "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
| "no-store" ; Section 14.9.2
| "no-transform" ; Section 14.9.5
| "must-revalidate" ; Section 14.9.4
| "proxy-revalidate" ; Section 14.9.4
| "max-age" "=" delta-seconds ; Section 14.9.3
| "s-maxage" "=" delta-seconds ; Section 14.9.3
| cache-extension ; Section 14.9.6
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 might apply these directives to header fields not defined in HTTP/1.1.
当一个指令没有任何1#field name参数时，该指令将应用于整个请求或响应。当此类指令与1#field name参数一起出现时，它仅适用于命名字段，而不适用于请求或响应的其余部分。该机制支持可扩展性；HTTP协议未来版本的实现可能会将这些指令应用于HTTP/1.1中未定义的头字段。
The cache-control directives can be broken down into these general categories:
缓存控制指令可分为以下一般类别：
- Restrictions on what are cacheable; these may only be imposed by the origin server.
- 对可缓存内容的限制；这些只能由源服务器强制执行。
- Restrictions on what may be stored by a cache; these may be imposed by either the origin server or the user agent.
- 对缓存可存储内容的限制；这些可能由源服务器或用户代理强加。
- Modifications of the basic expiration mechanism; these may be imposed by either the origin server or the user agent.
- 修改基本过期机制；这些可能由源服务器或用户代理强加。
- Controls over cache revalidation and reload; these may only be imposed by a user agent.
- 控制缓存重新验证和重新加载；这些只能由用户代理实施。
- Control over transformation of entities.
- 对实体转换的控制。
- Extensions to the caching system.
- 缓存系统的扩展。
By default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. Section 13.4 summarizes these defaults for cacheability. The following Cache-Control response directives allow an origin server to override the default cacheability of a response:
默认情况下，如果请求方法、请求头字段和响应状态的要求指示响应可缓存，则响应可缓存。第13.4节总结了可缓存性的默认设置。以下缓存控制响应指令允许源服务器覆盖响应的默认缓存能力：
public Indicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non-shared cache. (See also Authorization, section 14.8, for additional details.)
public表示响应可以由任何缓存缓存，即使它通常不可缓存或只能在非共享缓存中缓存。（更多详细信息，请参见第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
private表示响应消息的全部或部分是针对单个用户的，不能由共享缓存缓存。这允许源服务器声明
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.
响应仅针对一个用户，不是对其他用户请求的有效响应。私有（非共享）缓存可以缓存响应。
Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.
注意：这个单词private的用法仅控制响应的缓存位置，不能确保消息内容的隐私。
no-cache If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.
no cache如果no cache指令未指定字段名，则在未与源服务器成功重新验证的情况下，缓存不得使用响应来满足后续请求。这允许源服务器甚至通过已配置为向客户端请求返回过时响应的缓存来阻止缓存。
If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.
如果no cache指令指定了一个或多个字段名，则缓存可以使用响应来满足后续请求，但需遵守缓存的任何其他限制。但是，如果未与源服务器成功重新验证，则不得在对后续请求的响应中发送指定的字段名。这允许源服务器防止在响应中重复使用某些头字段，同时仍允许缓存响应的其余部分。
Note: Most HTTP/1.0 caches will not recognize or obey this directive.
注意：大多数HTTP/1.0缓存不会识别或遵守此指令。
no-store 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.
无存储无存储指令的目的是防止敏感信息（例如，备份磁带上）的意外释放或保留。no store指令适用于整个消息，可以在响应或请求中发送。如果在请求中发送，缓存不得存储此请求或其任何响应的任何部分。如果在响应中发送，缓存不得存储此响应或引发响应的请求的任何部分。此指令适用于非共享和共享缓存。在此上下文中，“不得存储”意味着缓存不得有意将信息存储在非易失性存储器中，并且必须尽最大努力在转发信息后尽快将其从易失性存储器中删除。
Even when this directive is associated with a response, users might 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.
即使此指令与响应关联，用户也可能在缓存系统之外显式存储此类响应（例如，使用“另存为”对话框）。历史缓冲区可将此类响应存储为其正常操作的一部分。
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 might 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 might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.
本指令的目的是满足某些用户和服务作者的规定要求，这些用户和服务作者担心通过意外访问缓存数据结构意外释放信息。虽然在某些情况下，本指令的使用可能会改善隐私，但我们警告，它在任何方面都不是确保隐私的可靠或充分的机制。特别是，恶意或受损缓存可能无法识别或遵守此指令，并且通信网络可能容易被窃听。
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. When the max-age cache-control directive is present in a cached response, the response is stale if its current age is greater than the age value given (in seconds) at the time of a new request for that resource. The max-age directive on a response implies that the response is cacheable (i.e., "public") unless some other, more restrictive cache directive is also present.
实体的过期时间可由源服务器使用Expires标头指定（参见第14.21节）。或者，可以在响应中使用max age指令指定。当缓存响应中存在max age cache control指令时，如果响应的当前期限大于新请求该资源时给定的期限值（以秒为单位），则该响应将过时。响应上的max-age指令意味着响应是可缓存的（即“public”），除非还存在其他限制性更强的缓存指令。
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 might be useful if certain HTTP/1.0 caches improperly calculate ages or expiration times, perhaps due to desynchronized clocks.
如果响应同时包含Expires标头和max age指令，则max age指令将覆盖Expires标头，即使Expires标头的限制性更强。此规则允许源服务器为给定响应向HTTP/1.1（或更高版本）缓存提供比HTTP/1.0缓存更长的过期时间。如果某些HTTP/1.0缓存不正确地计算时间或过期时间（可能是由于时钟不同步），这可能很有用。
Many HTTP/1.0 cache implementations will treat an Expires value that is less than or equal to the response Date value as being equivalent to the Cache-Control response directive "no-cache". If an HTTP/1.1 cache receives such a response, and the response does not include a Cache-Control header field, it SHOULD consider the response to be non-cacheable in order to retain compatibility with HTTP/1.0 servers.
许多HTTP/1.0缓存实现将小于或等于响应日期值的Expires值视为等同于缓存控制响应指令“no cache”。如果HTTP／1.1缓存接收到这样的响应，并且响应不包括缓存控制头字段，则它应该考虑响应是不可缓存的，以便保持与HTTP / 1服务器的兼容性。
Note: An origin server might wish to use a relatively new HTTP cache control feature, such as the "private" directive, on a network including older caches that do not understand that feature. The origin server will need to combine the new feature with an Expires field whose value is less than or equal to the Date value. This will prevent older caches from improperly caching the response.
注意：源服务器可能希望在包含不了解该功能的旧缓存的网络上使用相对较新的HTTP缓存控制功能，例如“private”指令。原始服务器将需要将新功能与值小于或等于日期值的Expires字段相结合。这将防止较旧的缓存不正确地缓存响应。
s-maxage If a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4), i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. The s-maxage directive is always ignored by a private cache.
s-maxage如果响应包含s-maxage指令，则对于共享缓存（但不是专用缓存），此指令指定的最大使用年限将覆盖max age指令或Expires标头指定的最大使用年限。s-maxage指令还暗示了proxy revalidate指令的语义（参见第14.9.4节），即共享缓存在过时后不得使用条目响应后续请求，而无需首先与源服务器重新验证。专用缓存始终忽略s-maxage指令。
Note that 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 pre-HTTP/1.1-compliant caches do not observe the max-age directive.
请注意，大多数不符合此规范的旧缓存不实现任何缓存控制指令。希望使用限制但不阻止HTTP/1.1兼容缓存缓存的缓存控制指令的源服务器可能会利用max age指令覆盖Expires标头的要求以及HTTP/1.1兼容之前的缓存不遵守max age指令的事实。
Other directives allow a 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.
max age表示客户机愿意接受期限不大于指定时间（以秒为单位）的响应。除非还包含max stale指令，否则客户端不愿意接受过时的响应。
min-fresh Indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
min fresh表示客户端愿意接受新鲜度生命周期不小于其当前年龄加上指定时间（以秒为单位）的响应。也就是说，客户机希望响应至少在指定的秒数内保持新鲜。
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.
max stale表示客户端愿意接受超过其到期时间的响应。如果为max stale分配了一个值，则客户端愿意接受超出其过期时间不超过指定秒数的响应。如果没有为max stale指定值，那么客户机愿意接受任何年龄的stale响应。
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 110 (Response is stale).
如果缓存返回陈旧响应，或者是因为请求上的max stale指令，或者因为缓存配置为覆盖响应的过期时间，则缓存必须使用警告110（响应陈旧）将警告标头附加到陈旧响应。
A cache MAY be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive).
缓存可以配置为在不进行验证的情况下返回过时响应，但前提是这不会与任何有关缓存验证的“必须”级别要求（例如，“必须重新验证”缓存控制指令）相冲突。
If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining the freshness of the cached entry for that request.
如果新请求和缓存项都包含“max age”指令，则两个值中的较小值用于确定该请求的缓存项的新鲜度。
Sometimes a user agent might 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 might 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:
客户端可以使用缓存控制请求指令指定这三种操作：
End-to-end reload The request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT use a cached copy when responding to such a request.
端到端重新加载请求包括“无缓存”缓存控制指令，或者，为了与HTTP/1.0客户端兼容，“Pragma:no cache”。字段名不能包含在请求中的no cache指令中。服务器在响应此类请求时不得使用缓存副本。
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 request includes a cache-validating conditional with the client's current validator.
特定的端到端重新验证请求包括“max age=0”缓存控制指令，该指令强制沿到源服务器的路径的每个缓存使用下一个缓存或服务器重新验证其自己的条目（如果有）。初始请求包括一个缓存，用于验证客户端当前验证器的条件。
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
未指定的端到端重新验证请求包括“max age=0”缓存控制指令，该指令强制沿到源服务器的路径的每个缓存使用下一个缓存或服务器重新验证其自己的条目（如果有）。初始请求不包括缓存验证
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.
有条件的路径（如果有）上保存此资源的缓存项的第一个缓存包括一个带有当前验证程序的缓存验证条件。
max-age 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 might 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.
最大年龄通过max age=0指令强制中间缓存重新验证其自己的缓存项，并且客户端在请求中提供了自己的验证器时，提供的验证器可能与当前存储在缓存项中的验证器不同。在这种情况下，缓存可以使用任一验证器发出自己的请求，而不影响语义透明性。
However, the choice of validator might 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 can 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 can 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.
但是，验证器的选择可能会影响性能。最好的方法是中间缓存在发出请求时使用自己的验证器。如果服务器以304（未修改）进行回复，则缓存可以以200（确定）响应将其现在已验证的副本返回给客户端。但是，如果服务器使用新实体和缓存验证器进行响应，则中间缓存可以使用强比较功能将返回的验证器与客户端请求中提供的验证器进行比较。如果客户端的验证器等于源服务器的验证器，那么中间缓存只返回304（未修改）。否则，它将返回带有200（OK）响应的新实体。
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or max-age.
如果请求包含no cache指令，则不应包含min fresh、max stale或max age。
only-if-cached 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.
只有在某些情况下（如网络连接极差时）缓存时，客户机才可能希望缓存仅返回其当前存储的响应，而不是重新加载或与源服务器重新验证。为此，客户端可以在请求中包含only if cached指令。如果收到此指令，缓存应该使用与请求的其他约束一致的缓存条目进行响应，或者使用504（网关超时）状态进行响应。然而，如果一组缓存作为具有良好内部连接的统一系统运行，则可以在该组缓存内转发这样的请求。
must-revalidate 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 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
必须重新验证，因为缓存可能被配置为忽略服务器指定的过期时间，并且因为客户端请求可能包含max stale指令（具有类似效果），所以协议还包括一种机制，用于源服务器在任何后续使用时要求重新验证缓存项。当缓存接收到的响应中存在must revalidate指令时，该缓存不得在条目过时后使用该条目来响应请求
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.)
后续请求，无需首先与源服务器重新验证。（即，如果仅基于源服务器的Expires或max age值，缓存响应过时，则每次缓存都必须进行端到端重新验证。）
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.
必须重新验证指令对于支持某些协议功能的可靠运行是必要的。在所有情况下，HTTP/1.1缓存必须遵守必须重新验证指令；特别是，如果缓存由于任何原因无法到达源服务器，它必须生成504（网关超时）响应。
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.
当且仅当对实体的请求重新验证失败可能导致错误操作（例如未执行的静默金融交易）时，服务器才应发送must 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.
尽管不建议这样做，但在严重连接约束下运行的用户代理可能会违反此指令，但如果违反，则必须明确警告用户已提供未验证的响应。必须在每个未经验证的访问上提供警告，并应要求用户明确确认。
proxy-revalidate 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.
proxy revalidate proxy revalidate指令与must revalidate指令具有相同的含义，只是它不适用于非共享用户代理缓存。它可以用于对经过身份验证的请求的响应，以允许用户的缓存存储并稍后返回响应，而无需重新验证它（因为它已经由该用户进行了一次身份验证），同时仍然要求每次为多个用户服务的代理重新验证（以确保每个用户都经过身份验证）。请注意，此类经过身份验证的响应还需要公共缓存控制指令，以便允许缓存它们。
no-transform Implementors of intermediate caches (proxies) have found it useful to convert the media type of certain entity bodies. A non-transparent 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.
没有中间缓存（代理）的转换实现者发现转换某些实体的媒体类型是有用的。例如，不透明代理可能会在图像格式之间转换，以节省缓存空间或减少慢速链接上的通信量。
Serious operational problems occur, however, when these transformations are 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 message 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, including the value of the entity-body itself.
因此，如果消息包含no transform指令，则中间缓存或代理不得更改第13.5.2节中列出的受no transform指令约束的头。这意味着缓存或代理不能更改这些头指定的实体体的任何方面，包括实体体本身的值。
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.
缓存控制头字段可以通过使用一个或多个缓存扩展令牌进行扩展，每个令牌都有一个可选的赋值。可以添加信息扩展（不需要更改缓存行为的扩展），而不更改其他指令的语义。行为扩展被设计为充当现有缓存指令基础的修饰符。同时提供新指令和标准指令，这样不理解新指令的应用程序将默认为标准指令指定的行为，而理解新指令的应用程序将识别为修改与标准指令相关的要求。通过这种方式，可以对缓存控制指令进行扩展，而无需更改基本协议。
This extension mechanism depends on an 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) could do so by including
例如，假设一个假设的新响应指令称为Cube，它作为私有指令的修改器。我们将此新指令定义为，除了任何非共享缓存之外，任何仅由在其值内命名的社区成员共享的缓存都可以缓存响应。希望允许UCI社区在其共享缓存中使用其他私有响应的源服务器可以通过包括
Cache-Control: private, community="UCI"
缓存控制：专用，community=“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.
即使缓存不理解社区缓存扩展，看到此标头字段的缓存也会正确运行，因为它也会看到并理解private指令，因此默认为安全行为。
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 cacheability) such that the cache behavior will remain minimally correct even if the cache does not understand the extension(s).
必须忽略无法识别的缓存指令；假设HTTP/1.1缓存可能无法识别的任何缓存指令都将与标准指令（或响应的默认缓存能力）相结合，这样即使缓存不理解扩展，缓存行为也将保持最低限度的正确性。
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 general header字段允许发送方指定特定连接所需的选项，并且不得通过代理通过进一步的连接进行通信。
The Connection header has the following grammar:
连接头具有以下语法：
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
Connection = "Connection" ":" 1#(connection-token)
connection-token = token
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代理必须在转发消息之前解析连接头字段，对于此字段中的每个连接令牌，从消息中删除与连接令牌同名的任何头字段。连接选项由连接头字段中存在的连接令牌发出信号，而不是由任何相应的附加头字段发出信号，因为如果没有与该连接选项相关联的参数，则可能不会发送附加头字段。
Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.
连接标头中列出的消息标头不得包括端到端标头，例如缓存控制。
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: 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应用程序必须在每条消息中包含“关闭”连接选项。
A system receiving an HTTP/1.0 (or lower-version) message that includes a Connection header MUST, for each connection-token in this field, remove and ignore any header field(s) from the message with the same name as the connection-token. This protects against mistaken forwarding of such header fields by pre-HTTP/1.1 proxies. See section 19.6.2.
接收包含连接头的HTTP/1.0（或更低版本）消息的系统，对于此字段中的每个连接令牌，必须从消息中删除并忽略与连接令牌同名的任何头字段。这可以防止HTTP/1.1之前的代理错误地转发此类头字段。见第19.6.2节。
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-Encoding = "Content-Encoding" ":" 1#content-coding
Content-Encoding = "Content-Encoding" ":" 1#content-coding
Content codings are defined in section 3.5. An example of its use is
第3.5节定义了内容编码。其使用的一个例子是
Content-Encoding: gzip
内容编码：gzip
The content-coding 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. However, a non-transparent proxy MAY modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache-control directive is present in the message.
内容编码是由请求URI标识的实体的特征。通常，实体体使用此编码存储，并且仅在呈现或类似使用之前解码。然而，除非消息中存在“no transform”缓存控制指令，否则，如果接收方已知新编码是可接受的，则非透明代理可以修改内容编码。
If the content-coding of an entity is not "identity", then the response MUST include a Content-Encoding entity-header (section 14.11) that lists the non-identity content-coding(s) used.
如果实体的内容编码不是“标识”，则响应必须包括列出所用非标识内容编码的内容编码实体标题（第14.11节）。
If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).
如果源服务器不接受请求消息中实体的内容编码，则服务器应以状态代码415（不支持的媒体类型）响应。
If multiple encodings have been applied to an entity, the content codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
如果对一个实体应用了多个编码，则必须按应用顺序列出内容编码。关于编码参数的附加信息可由本规范未定义的其他实体头字段提供。
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.
Content Language entity标头字段描述所包含实体的预期受众的自然语言。请注意，这可能并不等同于实体体中使用的所有语言。
Content-Language = "Content-Language" ":" 1#language-tag
Content-Language = "Content-Language" ":" 1#language-tag
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-Language: da
内容语言：da
If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender 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
内容语言：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 would properly only include "en".
然而，仅仅因为一个实体中存在多种语言并不意味着它是针对多种语言受众的。一个例子是初学者语言入门，如“拉丁语第一课”，这显然是为了让懂英语的观众使用。在这种情况下，内容语言将正确地仅包括“en”。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
内容语言可以应用于任何媒体类型——它不限于文本文档。
The Content-Length entity-header field indicates the size of the entity-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-Length-entity-header字段表示发送给收件人的实体体的大小（以十进制八位字节为单位），或者在HEAD方法的情况下，表示如果请求是GET，则会发送的实体体的大小。
Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length = "Content-Length" ":" 1*DIGIT
An example is
例如
Content-Length: 3495
内容长度：3495
Applications SHOULD use this field to indicate the transfer-length of the message-body, unless this is prohibited by the rules in section 4.4.
应用程序应使用此字段指示消息正文的传输长度，除非第4.4节中的规则禁止这样做。
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.
任何大于或等于零的内容长度都是有效值。第4.4节描述了如果没有给出内容长度，如何确定消息正文的长度。
Note that 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, unless this is prohibited by the rules in section 4.4.
请注意，此字段的含义与MIME中的相应定义明显不同，MIME中的定义是“message/external body”内容类型中使用的可选字段。在HTTP中，除非第4.4节中的规则禁止，否则只要在传输之前可以确定消息的长度，就应该发送该消息。
The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially 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.
当可以从与请求的资源的URI分离的位置访问该实体时，可以使用Content-Location-entity报头字段为消息中包含的实体提供资源位置。服务器应为对应于响应实体的变量提供内容位置；特别是在一个资源有多个与之关联的实体，并且这些实体实际上有单独的位置，可以通过这些位置单独访问它们的情况下，服务器应该为返回的特定变量提供一个内容位置。
Content-Location = "Content-Location" ":" ( absoluteURI | relativeURI )
Content Location=“Content Location”“：”（绝对URI |相对URI）
The value of Content-Location also defines the base URI for the entity.
Content Location的值还定义了实体的基本URI。
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 specify the Content-Location URI as the request-URI if the desire is to identify the source of that particular entity.
内容位置值不是原始请求URI的替换；它只是请求时对应于该特定实体的资源位置的语句。如果希望识别该特定实体的源，则未来的请求可以将内容位置URI指定为请求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.
缓存不能假定内容位置与用于检索它的URI不同的实体可以用于响应该内容位置URI上的后续请求。但是，内容位置可用于区分从单个请求资源检索的多个实体，如第13.6节所述。
If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.
如果内容位置是相对URI，则相对URI将相对于请求URI进行解释。
The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.
PUT或POST请求中内容位置标头的含义未定义；在这种情况下，服务器可以随意忽略它。
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.)
RFC 1864[23]中定义的Content-MD5 entity header字段是实体主体的MD5摘要，用于提供实体主体的端到端消息完整性检查（MIC）。（注意：MIC可用于检测传输中实体主体的意外修改，但不能防止恶意攻击。）
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = <base64 of 128 bit MD5 digest as per RFC 1864>
The Content-MD5 header field MAY be generated by an origin server or client to function as an integrity check of the entity-body. Only origin servers or clients 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-coding that has been applied, but not including any transfer-encoding 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-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.
其结果是，在实体体的八位字节上计算摘要，其顺序与未应用传输编码时发送的顺序完全相同。
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 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.
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-Transfer-Encoding和Content-Encoding头）。如果主体部分具有内容传输编码或内容编码头，则假定主体部分的内容已应用编码，并且主体部分按原样包括在Content-MD5摘要中，即在应用之后。身体部位内不允许传输编码标头字段。
Conversion of all line breaks to CRLF MUST NOT be done before computing or checking the digest: the line break convention used in the text actually transmitted MUST be left unaltered when computing the digest.
在计算或检查摘要之前，不得将所有换行符转换为CRLF：在计算摘要时，实际传输的文本中使用的换行符约定必须保持不变。
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 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.
注意：虽然Content-MD5对HTTP的定义与RFC 1864中对MIME实体体的定义完全相同，但Content-MD5对HTTP实体体的应用与对MIME实体体的应用有几种不同的方式。一个是HTTP不同于MIME，它不使用内容传输编码，而是使用传输编码和内容编码。另一个原因是HTTP比MIME更频繁地使用二进制内容类型，因此值得注意的是，在这种情况下，用于计算摘要的字节顺序是为该类型定义的传输字节顺序。最后，HTTP允许使用任意一种换行约定传输文本类型，而不仅仅是使用CRLF的规范形式。
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 applied. Range units are defined in section 3.12.
内容范围实体标头与部分实体正文一起发送，以指定部分实体应在完整实体正文中的何处应用。范围单位在第3.12节中定义。
Content-Range = "Content-Range" ":" content-range-spec
Content Range=“Content Range”“：”内容范围规范
content-range-spec = byte-content-range-spec byte-content-range-spec = bytes-unit SP byte-range-resp-spec "/" ( instance-length | "*" )
内容范围规范=字节内容范围规范字节内容范围规范=字节单位SP字节范围响应规范“/”（实例长度“*”）
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
instance-length = 1*DIGIT
byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
| "*"
instance-length = 1*DIGIT
The header SHOULD indicate the total length of the full entity-body, unless this length is unknown or difficult to determine. The asterisk "*" character means that the instance-length is unknown at the time when the response was generated.
标题应指示整个实体主体的总长度，除非该长度未知或难以确定。星号“*”字符表示在生成响应时实例长度未知。
Unlike byte-ranges-specifier values (see section 14.35.1), a byte-range-resp-spec MUST only specify one range, and MUST contain absolute byte positions for both the first and last byte of the range.
与字节范围说明符值不同（参见第14.35.1节），字节范围resp规范只能指定一个范围，并且必须包含该范围第一个和最后一个字节的绝对字节位置。
A byte-content-range-spec with a byte-range-resp-spec whose last-byte-pos value is less than its first-byte-pos value, or whose instance-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值的字节范围resp spec的字节内容范围规范无效。无效字节内容范围规范的收件人必须忽略该规范以及随该规范一起传输的任何内容。
A server sending a response with status code 416 (Requested range not satisfiable) SHOULD include a Content-Range field with a byte-range-resp-spec of "*". The instance-length specifies the current length of
发送状态代码为416（请求的范围不可满足）的响应的服务器应包含一个字节范围resp spec为“*”的内容范围字段。实例长度指定实例的当前长度
the selected resource. A response with status code 206 (Partial Content) MUST NOT include a Content-Range field with a byte-range-resp-spec of "*".
选定的资源。状态代码为206（部分内容）的响应不得包含字节范围resp spec为“*”的内容范围字段。
Examples of byte-content-range-spec values, assuming that the entity contains a total of 1234 bytes:
假设实体总共包含1234个字节，则字节内容范围规范值示例如下：
. The first 500 bytes: bytes 0-499/1234
. 前500个字节：字节0-499/1234
. The second 500 bytes: bytes 500-999/1234
. 第二个500字节：字节500-999/1234
. All except for the first 500 bytes: bytes 500-1233/1234
. 除前500个字节外的所有字节：字节500-1233/1234
. The last 500 bytes: bytes 734-1233/1234
. 最后500个字节：字节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消息包含单个范围的内容时（例如，对单个范围的请求的响应，或对无孔重叠的一组范围的请求的响应），该内容通过内容范围标头和显示实际传输字节数的内容长度标头进行传输。例如
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 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
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 message. The multipart media type used for this purpose is "multipart/byteranges" as defined in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
当HTTP消息包含多个范围的内容（例如，对多个非重叠范围请求的响应）时，这些内容将作为多部分消息传输。用于此目的的多部分介质类型为附录19.2中定义的“多部分/byteranges”。有关兼容性问题，请参见附录19.6.3。
A response to a request for a single range MUST NOT be sent using the multipart/byteranges media type. A response to a request for multiple ranges, whose result is a single range, MAY be sent as a multipart/byteranges media type with one part. A client that cannot decode a multipart/byteranges message MUST NOT ask for multiple byte-ranges in a single request.
不得使用multipart/byteranges介质类型发送对单个范围请求的响应。对多个范围请求的响应（其结果是单个范围）可以作为包含一部分的多部分/byteranges媒体类型发送。无法解码多部分/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.
当客户机在一个请求中请求多个字节范围时，服务器应该按照它们在请求中出现的顺序返回它们。
If the server ignores a byte-range-spec because it is syntactically invalid, the server SHOULD treat the request as if the invalid Range header field did not exist. (Normally, this means return a 200 response containing the full entity).
如果服务器因为字节范围规范在语法上无效而忽略该规范，则服务器应将该请求视为无效范围标头字段不存在。（通常，这意味着返回包含完整实体的200响应）。
If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected resource), it SHOULD return a response code of 416 (Requested range not satisfiable) (section 10.4.17).
如果服务器接收到具有不可满足的范围请求标头字段（即，其所有字节范围规范值的第一个字节pos值大于所选资源的当前长度）的请求（不包括包含If范围请求标头字段的请求），则应返回416的响应代码（请求的范围不可满足）（第10.4.17节）。
Note: clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for an unsatisfiable Range request-header, since not all servers implement this request-header.
注意：客户端不能依赖服务器发送416（请求的范围不可满足）响应，而不是针对不可满足的范围请求标头发送200（确定）响应，因为并非所有服务器都实现此请求标头。
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.
Content-Type-entity-header字段表示发送给收件人的实体主体的媒体类型，或者在HEAD方法的情况下，表示如果请求是GET，则会发送的媒体类型。
Content-Type = "Content-Type" ":" media-type
Content Type=“Content 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
Content-Type: text/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节进一步讨论了识别实体媒体类型的方法。
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; it MUST be sent in RFC 1123 [8]-date format.
Date general header字段表示消息发起的日期和时间，其语义与RFC 822中的orig Date相同。字段值为HTTP日期，如第3.3.1节所述；必须以RFC 1123[8]-日期格式发送。
Date = "Date" ":" HTTP-date
Date=“Date”“：”HTTP日期
An example is
例如
Date: Tue, 15 Nov 1994 08:12:31 GMT
Date: Tue, 15 Nov 1994 08:12:31 GMT
Origin servers MUST include a Date header field in all responses, except in these cases:
原始服务器必须在所有响应中包含日期标头字段，以下情况除外：
1. If the response status code is 100 (Continue) or 101 (Switching Protocols), the response MAY include a Date header field, at the server's option.
1. 如果响应状态代码为100（Continue）或101（Switching Protocols），则响应可能包括一个日期头字段（由服务器选择）。
2. If the response status code conveys a server error, e.g. 500 (Internal Server Error) or 503 (Service Unavailable), and it is inconvenient or impossible to generate a valid Date.
2. 如果响应状态代码传达服务器错误，例如500（内部服务器错误）或503（服务不可用），并且不方便或不可能生成有效日期。
3. If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, the rules in section 14.18.1 MUST be followed.
3. 如果服务器没有能够提供当前时间合理近似值的时钟，则其响应不得包含日期标头字段。在这种情况下，必须遵守第14.18.1节中的规则。
A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date. An HTTP implementation without a clock MUST NOT cache responses without revalidating them on every use. An HTTP cache, especially a shared cache, SHOULD use a mechanism, such as NTP [28], to synchronize its clock with a reliable external standard.
如果收件人将缓存未包含日期标头字段的已接收邮件，或通过需要日期的协议将其网关化，则收件人必须为该邮件分配一个日期标头字段。没有时钟的HTTP实现在每次使用时都必须重新验证响应，才能缓存响应。HTTP缓存，特别是共享缓存，应该使用一种机制，如NTP[28]，以使其时钟与可靠的外部标准同步。
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 client without a clock MUST NOT send a Date header field in a request.
客户端应该只在包含实体主体的消息中发送日期头字段，就像PUT和POST请求一样，即使这样，它也是可选的。没有时钟的客户端不能在请求中发送日期头字段。
The HTTP-date sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to 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.
在日期标头中发送的HTTP日期不应表示生成消息之后的日期和时间。它应该代表消息生成日期和时间的最佳可用近似值，除非实现无法生成合理准确的日期和时间。理论上，日期应该代表实体生成之前的时刻。实际上，可以在消息发起期间的任何时间生成日期，而不影响其语义值。
Some origin server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).
某些源服务器实现可能没有可用的时钟。没有时钟的源服务器不得将Expires或Last Modified值分配给响应，除非这些值由具有可靠时钟的系统或用户与资源关联。它可以分配一个在服务器配置时或之前已知的过期值，该值将是过去的（这允许响应“预过期”，而无需为每个资源存储单独的过期值）。
The ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with entity tags are described in sections 14.24, 14.26 and 14.44. The entity tag MAY be used for comparison with other entities from the same resource (see section 13.3.3).
ETag响应标头字段提供所请求变量的实体标记的当前值。第14.24、14.26和14.44节描述了与实体标记一起使用的标题。实体标签可用于与来自同一资源的其他实体进行比较（见第13.3.3节）。
ETag = "ETag" ":" entity-tag
ETag=“ETag”“：”实体标记
Examples:
示例：
ETag: "xyzzy" ETag: W/"xyzzy" ETag: ""
ETag:“xyzy”ETag:W/“xyzy”ETag:“
The Expect request-header field is used to indicate that particular server behaviors are required by the client.
ExpectRequestHeader字段用于指示客户端需要特定的服务器行为。
Expect = "Expect" ":" 1#expectation
Expect = "Expect" ":" 1#expectation
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )
*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]
expectation = "100-continue" | expectation-extension
expectation-extension = token [ "=" ( token | quoted-string )
*expect-params ]
expect-params = ";" token [ "=" ( token | quoted-string ) ]
A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request MUST respond with appropriate error status. The server MUST respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with the request, some other 4xx status.
不理解或无法遵守请求的Expect字段中的任何期望值的服务器必须以适当的错误状态进行响应。如果无法满足任何期望，服务器必须以417（期望失败）状态响应，或者如果请求存在其他问题，则必须以其他4xx状态响应。
This header field is defined with extensible syntax to allow for future extensions. If a server receives a request containing an Expect field that includes an expectation-extension that it does not support, it MUST respond with a 417 (Expectation Failed) status.
此标头字段使用可扩展语法定义，以允许将来扩展。如果服务器收到一个包含Expect字段的请求，该字段包含它不支持的Expect扩展，则它必须以417（expectation Failed）状态响应。
Comparison of expectation values is case-insensitive for unquoted tokens (including the 100-continue token), and is case-sensitive for quoted-string expectation-extensions.
对于无引号的令牌（包括100 continue令牌），期望值的比较不区分大小写，对于带引号的字符串期望扩展，期望值的比较区分大小写。
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST return a 417 (Expectation Failed) status if it receives a request with an expectation that it cannot meet. However, the Expect request-header itself is end-to-end; it MUST be forwarded if the request is forwarded.
Expect机制是逐跳的：也就是说，如果HTTP/1.1代理接收到一个无法满足期望的请求，那么它必须返回417（期望失败）状态。但是，Expect请求头本身是端到端的；如果请求被转发，它必须被转发。
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
许多较旧的HTTP/1.0和HTTP/1.1应用程序不理解Expect标头。
See section 8.2.3 for the use of the 100 (continue) status.
关于100（继续）状态的使用，请参见第8.2.3节。
The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a 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 entity标头字段给出了响应被视为过时的日期/时间。缓存（代理缓存或用户代理缓存）通常不会返回过时的缓存项，除非首先使用源服务器（或具有实体新副本的中间缓存）对其进行验证。有关到期模型的进一步讨论，请参见第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.1; it MUST be in RFC 1123 date format:
格式为第3.3.1节中HTTP日期定义的绝对日期和时间；必须采用RFC 1123日期格式：
Expires = "Expires" ":" HTTP-date
Expires=“Expires”“：”HTTP日期
An example of its use is
其使用的一个例子是
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-age directive (see section 14.9.3), that directive overrides the Expires field.
注意：如果响应包含带有max age指令的缓存控制字段（请参阅第14.9.3节），则该指令将覆盖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 sends an Expires date that is equal to the Date header value. (See the rules for expiration calculations in section 13.2.4.)
要将响应标记为“已过期”，源服务器将发送一个等于日期标头值的过期日期。（参见第13.2.4节中的到期计算规则。）
To mark a response as "never expires," an origin server sends 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.
若要将响应标记为“永不过期”，源服务器将在发送响应后大约一年内发送过期日期。HTTP/1.1服务器发送的过期日期不应超过一年。
The presence of an Expires header field with a date value of some time in the future on a response that otherwise would by default be non-cacheable indicates that the response is cacheable, unless indicated otherwise by a Cache-Control header field (section 14.9).
除非缓存控制报头字段另有指示，否则默认情况下不可缓存的响应上存在日期值为未来某个时间的Expires报头字段表示该响应可缓存（第14.9节）。
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 [9] as updated by RFC 1123 [8]:
From request header字段（如果给定）应包含控制请求用户代理的人工用户的Internet电子邮件地址。地址应该是机器可用的，如RFC 822[9]中的“邮箱”所定义，并由RFC 1123[8]更新：
From = "From" ":" mailbox
From=“From”“：”邮箱
An example is:
例如：
From: webmaster@w3.org
发件人：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.
此标头字段可用于日志记录目的，并可作为标识无效或不需要的请求源的手段。不应将其用作不安全的访问保护形式。该字段的解释是，请求是代表接受所执行方法责任的人员执行的。特别是，机器人代理应包括此标题，以便在接收端出现问题时可以联系负责运行机器人的人员。
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.
此字段中的Internet电子邮件地址可能与发出请求的Internet主机分开。例如，当请求通过代理传递时，应使用原始颁发者的地址。
The client SHOULD NOT send the From header field without the user's approval, as it might 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.
未经用户批准，客户端不应发送“发件人”标题字段，因为这可能会与用户的隐私利益或其网站的安全策略相冲突。强烈建议用户能够在请求之前随时禁用、启用和修改此字段的值。
The Host request-header field specifies the Internet host and port number of the resource being requested, as obtained from the original URI given by the user or referring resource (generally an HTTP URL,
Host request header字段指定被请求资源的Internet主机和端口号，该端口号是从用户或引用资源（通常是HTTP URL）提供的原始URI获得的，
as described in section 3.2.2). The Host field value MUST represent the naming authority 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.
如第3.2.2节所述）。主机字段值必须表示原始URL给定的源服务器或网关的命名权限。这允许源服务器或网关区分内部不明确的URL，例如单个IP地址上多个主机名的服务器根“/”URL。
Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
Host = "Host" ":" host [ ":" port ] ; Section 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/> would properly include:
没有任何后续端口信息的“主机”表示请求的服务的默认端口（例如，HTTP URL的“80”）。例如，在源服务器上请求<http://www.w3.org/pub/WWW/>将适当包括：
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
GET /pub/WWW/ HTTP/1.1
Host: www.w3.org
A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
客户端必须在所有HTTP/1.1请求消息中包含主机头字段。如果请求的URI不包括所请求服务的Internet主机名，则必须为主机头字段提供空值。HTTP/1.1代理必须确保它转发的任何请求消息都包含适当的主机头字段，该字段标识代理请求的服务。所有基于Internet的HTTP/1.1服务器必须使用400（错误请求）状态代码响应任何缺少主机头字段的HTTP/1.1请求消息。
See sections 5.2 and 19.6.1.1 for other requirements relating to Host.
有关主机的其他要求，请参见第5.2节和第19.6.1.1节。
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. Entity tags are defined in section 3.11. 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 Match request header字段与方法一起使用，使其具有条件。具有先前从资源获得的一个或多个实体的客户机可以通过在If Match header字段中包含其关联实体标记的列表来验证其中一个实体是否为当前实体。实体标记在第3.11节中定义。此功能的目的是允许以最小的事务开销高效地更新缓存信息。在更新请求时，它还用于防止无意中修改错误版本的资源。作为一种特殊情况，值“*”匹配资源的任何当前实体。
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
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
如果任何实体标记与该资源上类似GET请求（不带If匹配头）的响应中返回的实体的实体标记匹配，或者如果给定了“*”
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.
并且该资源存在任何当前实体，那么服务器可以执行请求的方法，就好像if Match header字段不存在一样。
A server MUST use the strong comparison function (see section 13.3.3) to compare the entity tags in If-Match.
服务器必须使用强比较功能（见第13.3.3节）比较If Match中的实体标记。
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 or 412 status, then the If-Match header MUST be ignored.
如果在没有If Match header字段的情况下，请求将导致除2xx或412状态以外的任何其他状态，则必须忽略If Match header。
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.44) exists, and MUST NOT be performed if the representation does not exist.
“If Match:*”的含义是，如果源服务器（或缓存，可能使用Vary机制，参见第14.44节）选择的表示存在，则应执行该方法，如果表示不存在，则不得执行该方法。
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-Match报头字段，以指示如果与If-Match值（单个实体标记）对应的实体不再是该资源的表示，则不得应用请求方法。这允许用户指出，如果在他们不知情的情况下更改了资源，他们不希望请求成功。示例：
If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: *
如果匹配：“XYZY”如果匹配：“XYZY”、“r2d2xxxx”、“c3piozzzz”如果匹配：*
The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification.
请求的结果，该请求同时具有If-Match头字段和If-None-Match或If-Modified头字段，因为此规范未定义头字段。
The If-Modified-Since request-header field is used with a method to make it conditional: if the requested variant has not been modified since the time specified in this field, an entity will not be returned from the server; instead, a 304 (not modified) response will be returned without any message-body.
If Modified Since request header字段与一种方法一起使用，使其具有条件：如果请求的变量自该字段中指定的时间以来未被修改，则不会从服务器返回实体；相反，将返回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
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
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-Modified-Since头和no-Range头的GET方法请求仅当标识的实体自If-Modified-Since头给定的日期以来已被修改时，才传输该实体。确定这一点的算法包括以下情况：
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）状态之外的任何其他状态，或者如果自日期起已修改且已通过，则响应与正常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 modified since日期起已修改，则响应与正常GET的响应完全相同。
c) If the variant has not been modified since a valid If-Modified-Since date, the server SHOULD return a 304 (Not Modified) response.
c) 如果变量自有效的If modified-since日期起未被修改，则服务器应返回304（未修改）响应。
The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
此功能的目的是允许以最小的事务开销高效地更新缓存信息。
Note: The Range request-header field modifies the meaning of If-Modified-Since; see section 14.35 for full details.
注意：范围请求标头字段修改了If-Modified-Since的含义；详情见第14.35节。
Note: If-Modified-Since times are interpreted by the server, whose clock might not be synchronized with the client.
注意：如果修改，因为时间由服务器解释，其时钟可能不会与客户端同步。
Note: When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than function, for deciding whether to send a 304 (Not Modified) response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to use the exact date string received in a previous Last-Modified header field whenever possible.
注意：在处理If-Modified-Since报头字段时，一些服务器将使用精确的日期比较函数而不是小于函数来决定是否发送304（未修改）响应。为了在发送用于缓存验证的If-Modified-Since标头字段时获得最佳结果，建议客户机尽可能使用上一次修改的标头字段中接收到的确切日期字符串。
Note: 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
注意：如果客户端在If-Modified-Since报头中使用任意日期，而不是从同一请求的上次修改报头中获取的日期，那么客户端应该知道这样一个事实，即该日期是在服务器对时间的理解中解释的。由于客户端和服务器之间时间的不同编码，客户端应该考虑非同步时钟和舍入问题。这包括，如果文件在首次请求时间和后续请求日期之后的if修改时间之间发生变化，以及
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 Modified Since date是从客户端时钟派生的，而不更正服务器时钟，则可能会出现与时钟偏移相关的问题。由于网络延迟，客户机和服务器之间的不同时基的更正最多是近似值。
The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header fields is undefined by this specification.
此规范未定义同时具有If-Modified-Since标头字段和If-Match或If-Unmodified-Since标头字段的请求的结果。
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 to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist.
If None Match请求标头字段与方法一起使用，使其具有条件。具有先前从资源获取的一个或多个实体的客户端可以通过在If none Match header字段中包含其关联实体标记的列表来验证这些实体是否为当前实体。此功能的目的是允许以最小的事务开销高效地更新缓存信息。它还用于防止当客户端认为现有资源不存在时，方法（如PUT）无意中修改该资源。
As a special case, the value "*" matches any current entity of the resource.
作为一种特殊情况，值“*”匹配资源的任何当前实体。
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
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, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was GET or HEAD, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related 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 None match标头）响应中返回的实体的实体标记匹配，或者如果给定“*”且该资源存在任何当前实体，则服务器不得执行请求的方法，除非由于资源的修改日期与请求中If-Modified-Since标头字段中提供的日期不匹配而需要这样做。相反，如果请求方法是GET或HEAD，则服务器应以304（未修改）响应响应，包括匹配的实体之一的缓存相关头字段（尤其是ETag）。对于所有其他请求方法，服务器的响应状态必须为412（前提条件失败）。
See section 13.3.3 for rules on how to determine if two entities tags match. The weak comparison function can only be used with GET or HEAD requests.
有关如何确定两个实体标记是否匹配的规则，请参见第13.3.3节。弱比较函数只能用于GET或HEAD请求。
If none of the entity tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no entity tags match, then the server MUST NOT return a 304 (Not Modified) response.
如果所有实体标记都不匹配，则服务器可以执行请求的方法，就好像If none match头字段不存在一样，但也必须忽略请求中的If-Modified-Since头字段。也就是说，如果没有实体标记匹配，则服务器不得返回304（未修改）响应。
If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See section 13.3.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
如果请求在没有If None Match header字段的情况下会导致除2xx或304状态以外的任何其他状态，则必须忽略If None Match header。（请参阅第13.3.4节，了解在同一请求中同时出现“如果自修改”和“如果不匹配”时服务器行为的讨论。）
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.44) exists, and SHOULD be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.
“If None Match:*”的含义是，如果源服务器（或缓存，可能使用Vary机制，参见第14.44节）选择的表示存在，则不得执行该方法，如果表示不存在，则应执行该方法。此功能用于防止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: *
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: *
The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header fields is undefined by this specification.
由于此规范未定义标头字段，因此请求的结果既有If None Match标头字段，也有If Match或If Unmodified。
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一起使用（如果未修改，则使用其中一个或两个，如果自后未修改，如果匹配）。但是，如果由于实体已修改而导致条件失败，然后，客户机必须发出第二个请求以获取整个当前实体体。
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 Range头允许客户端“短路”第二个请求。非正式地说，它的意思是“如果实体没有改变，请将我缺少的部分发送给我；否则，请将整个新实体发送给我”。
If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
If Range=“If Range”：（实体标记| HTTP日期）
If the client has no entity tag for an entity, but does have a Last-Modified date, it MAY use that date in an 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.
如果客户机没有实体的实体标记，但有上次修改的日期，则可以在If范围标头中使用该日期。（服务器可以通过检查不超过两个字符来区分有效的HTTP日期和任何形式的实体标记。）如果请求不包括范围标头，或者如果服务器不支持子范围操作，则If范围标头只能与范围标头一起使用，并且必须忽略。
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 Range头中给出的实体标记与实体的当前实体标记匹配，则服务器应使用206（部分内容）响应提供实体的指定子范围。如果实体标记不匹配，则服务器应使用200（确定）响应返回整个实体。
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 Unmodified Since request header字段与方法一起使用，使其具有条件。如果请求的资源自该字段中指定的时间以来未被修改，则服务器应执行请求的操作，就像If Unmodified since标头不存在一样。
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（前提条件失败）。
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
If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If the request normally (i.e., without the If-Unmodified-Since header) would result in anything other than a 2xx or 412 status, the If-Unmodified-Since header SHOULD be ignored.
如果请求正常（即，没有If Unmodified-Since头）将导致除2xx或412状态以外的任何其他状态，则应忽略If Unmodified-Since头。
If the specified date is invalid, the header is ignored.
如果指定的日期无效，则忽略标题。
The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since header fields is undefined by this specification.
请求的结果，该请求既有If Unmodified-Since头字段，也有If None-Match头字段或If Modified-Since头字段，但本规范未定义。
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
Last Modified entity header字段表示原始服务器认为变体上次修改的日期和时间。
Last-Modified = "Last-Modified" ":" HTTP-date
Last Modified=“Last Modified”“：”HTTP日期
An example of its use is
其使用的一个例子是
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
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.
此标头字段的确切含义取决于源服务器的实现和原始资源的性质。对于文件，它可能只是上次修改的文件系统。对于具有动态包含零件的实体，它可能是其零部件的最近一次修改时间集。对于数据库网关，它可能是记录的最后更新时间戳。对于虚拟对象，它可能是最后一次更改内部状态。
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.
源服务器应在尽可能接近其生成响应日期值的时间获取实体的最后修改值。这允许接收者对实体的修改时间进行准确的评估，尤其是当实体在生成响应的时间附近发生更改时。
HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
只要可行，HTTP/1.1服务器应发送上次修改。
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 URI for automatic redirection to the resource. The field value consists of a single absolute URI.
Location response header字段用于将收件人重定向到请求URI以外的位置，以完成请求或标识新资源。对于201（已创建）响应，位置是由请求创建的新资源的位置。对于3xx响应，位置应指示服务器的首选URI，以便自动重定向到资源。字段值由单个绝对URI组成。
Location = "Location" ":" absoluteURI
Location=“Location”“：”绝对URI
An example is:
例如：
Location: http://www.w3.org/pub/WWW/People.html
Location: http://www.w3.org/pub/WWW/People.html
Note: The Content-Location header field (section 14.14) 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.
注意：内容位置标题字段（第14.14节）与位置不同，内容位置标识请求中包含的实体的原始位置。因此，响应可能同时包含位置和内容位置的标题字段。有关某些方法的缓存要求，请参见第13.10节。
The Max-Forwards request-header field provides a mechanism with the TRACE (section 9.8) and OPTIONS (section 9.2) methods 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.
Max Forwards request header字段提供了一种带有跟踪（第9.8节）和选项（第9.2节）方法的机制，用于限制可以将请求转发到下一个入站服务器的代理或网关的数量。当客户端试图跟踪一个似乎失败或在中间链中循环的请求链时，这可能很有用。
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
Max-Forwards = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.
Max Forwards值是一个十进制整数，指示此请求消息可转发的剩余次数。
Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request. If the received value is zero (0), the recipient MUST NOT forward the request; instead, it MUST respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message MUST contain an updated Max-Forwards field with a value decremented by one (1).
包含Max Forwards标头字段的跟踪或选项请求的每个代理或网关收件人必须在转发请求之前检查并更新其值。如果收到的值为零（0），则接收方不得转发请求；相反，它必须作为最终接收者作出回应。如果接收到的最大转发值大于零，则转发消息必须包含一个值递减一（1）的更新最大转发字段。
The Max-Forwards header field MAY 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.
对于本规范定义的所有其他方法，以及对于未明确作为该方法定义一部分引用的任何扩展方法，可以忽略Max Forwards header字段。
The Pragma general-header field is used to include implementation-specific directives that might 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-general-header字段用于包括可能应用于请求/响应链中任何收件人的特定于实现的指令。所有pragma指令都从协议的角度指定了可选行为；但是，有些系统可能要求行为与指令一致。
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
Pragma = "Pragma" ":" 1#pragma-directive
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" ( token | quoted-string ) ]
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 backward 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.
当请求消息中存在no cache指令时，应用程序应将请求转发到源服务器，即使它具有所请求内容的缓存副本。这个pragma指令与no-cache指令具有相同的语义（参见第14.9节），在这里定义它是为了与HTTP/1.0向后兼容。当向未知符合HTTP/1.1的服务器发送无缓存请求时，客户端应包括这两个标头字段。
Pragma directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives might 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；但是，收件人应忽略与收件人无关的任何pragma指令。
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缓存应将“Pragma:no cache”视为客户端发送了“cache Control:no cache”。HTTP中不会定义新的Pragma指令。
Note: because the meaning of "Pragma: no-cache as a response header field is not actually specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in a response
注意：由于“Pragma:no cache as a response header”字段的含义没有实际指定，因此它不能可靠地替换响应中的“cache Control:no cache”
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.
代理身份验证响应头字段必须作为407（需要代理身份验证）响应的一部分包含。字段值由一个质询组成，该质询指示适用于此请求URI的代理的身份验证方案和参数。
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. 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 might 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访问身份验证过程在“HTTP身份验证：基本和摘要访问身份验证”[43]中描述。与WWW-Authenticate不同，Proxy-Authenticate头字段仅适用于当前连接，不应传递给下游客户端。但是，中间代理可能需要通过从下游客户端请求凭据来获取自己的凭据，在某些情况下，这将显示为代理正在转发代理身份验证标头字段。
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 Authorization request header（代理授权请求标头）字段允许客户端向需要身份验证的代理标识其自身（或其用户）。Proxy Authorization（代理授权）字段值由凭据组成，其中包含所请求资源的代理和/或领域的用户代理的身份验证信息。
Proxy-Authorization = "Proxy-Authorization" ":" credentials
Proxy Authorization=“Proxy Authorization”“：”凭据
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43] . 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
HTTP访问身份验证过程在“HTTP身份验证：基本和摘要访问身份验证”[43]中描述。与授权不同，Proxy Authorization header字段仅适用于要求使用Proxy Authenticate字段进行身份验证的下一个出站代理。当链中使用多个代理时
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.
代理授权标头字段由第一个期望接收凭据的出站代理使用。代理可以将来自客户端请求的凭据中继到下一个代理，如果这是代理协同验证给定请求的机制。
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实体都是有意义的。（但是，并非所有客户端和服务器都需要支持字节范围操作。）
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.
字节范围操作可以指定单个字节范围或单个实体内的一组范围。
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-pos = 1*DIGIT
ranges-specifier = byte-ranges-specifier
byte-ranges-specifier = bytes-unit "=" byte-range-set
byte-range-set = 1#( byte-range-spec | suffix-byte-range-spec )
byte-range-spec = first-byte-pos "-" [last-byte-pos]
first-byte-pos = 1*DIGIT
last-byte-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值给出该范围内最后一个字节的字节偏移量；也就是说，指定的字节位置是包含的。字节偏移量从零开始。
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 syntactically invalid. The recipient of a byte-range-set that includes one or more syntactically invalid byte-range-spec values MUST ignore the header field that includes that byte-range-set.
如果存在最后一个字节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将被视为小于实体正文的当前长度（以字节为单位）。
By its choice of last-byte-pos, a client can limit the number of bytes retrieved without knowing the size of the entity.
通过选择最后一个字节的位置，客户端可以限制检索的字节数，而不知道实体的大小。
suffix-byte-range-spec = "-" suffix-length suffix-length = 1*DIGIT
后缀字节范围spec=“-”后缀长度后缀长度=1*位
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个字节。）如果实体短于指定的后缀长度，则使用整个实体正文。
If a syntactically valid byte-range-set includes at least one byte-range-spec whose first-byte-pos is less than the current length of the entity-body, or at least one suffix-byte-range-spec with a non-zero suffix-length, then the byte-range-set is satisfiable. Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set is unsatisfiable, the server SHOULD return a response with a status of 416 (Requested range not satisfiable). Otherwise, the server SHOULD return a response with a status of 206 (Partial Content) containing the satisfiable ranges of the entity-body.
如果语法上有效的字节范围集包括至少一个字节范围规范，其第一个字节位置小于实体主体的当前长度，或者至少一个后缀长度为非零的后缀字节范围规范，则字节范围集是可满足的。否则，字节范围集将无法满足要求。如果字节范围集不可满足，服务器应返回状态为416（请求的范围不可满足）的响应。否则，服务器应返回状态为206（部分内容）的响应，其中包含实体主体的可满足范围。
Examples of byte-ranges-specifier values (assuming an entity-body of length 10000):
字节范围说明符值示例（假设实体长度为10000）：
- The first 500 bytes (byte offsets 0-499, inclusive): bytes=0- 499
- 前500个字节（字节偏移量0-499，包括在内）：字节=0-499
- The second 500 bytes (byte offsets 500-999, inclusive): bytes=500-999
- 第二个500字节（字节偏移量500-999，包括在内）：字节=500-999
- The final 500 bytes (byte offsets 9500-9999, inclusive): bytes=-500
- 最后500个字节（字节偏移量9500-9999，包括在内）：字节=-500
- Or bytes=9500-
- 或字节=9500-
- The first and last bytes only (bytes 0 and 9999): bytes=0-0,-1
- 仅第一个和最后一个字节（字节0和9999）：字节=0-0，-1
- Several legal but not canonical specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999
- 第二个500字节（字节偏移量500-999，包括在内）的若干合法但非规范规范规范：字节=500-600601-999字节=500-700601-999
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检索请求可以使用范围请求头请求实体的一个或多个子范围，而不是整个实体，该范围请求头适用于作为请求结果返回的实体：
Range = "Range" ":" ranges-specifier
Range=“Range”“：”范围说明符
A server MAY ignore the Range header. However, HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities.
服务器可能会忽略范围标头。然而，HTTP/1.1源服务器和中间缓存应该尽可能支持字节范围，因为范围支持从部分失败的传输中进行有效恢复，并支持对大型实体进行有效的部分检索。
If the server supports the Range header and the specified range or ranges are appropriate for the entity:
如果服务器支持范围标头，并且指定的一个或多个范围适用于实体：
- 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).
- 如果无条件GET中存在范围标头，则会修改在GET成功时返回的内容。换句话说，响应携带状态代码206（部分内容），而不是200（确定）。
- 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.
- 如果条件GET中存在范围标头（一个请求使用一个或两个If-Modified-Since和If-None-Match，或者一个或两个If-Unmodified-Since和If-Match），则会修改在GET成功且条件为true时返回的内容。如果条件为false，则不影响返回的304（未修改）响应。
In some cases, it might be more appropriate to use the If-Range header (see section 14.27) in addition to the Range header.
在某些情况下，除了范围标头之外，使用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.
如果支持范围的代理收到范围请求，将该请求转发到入站服务器，并收到整个实体的响应，则它应仅将请求的范围返回给其客户端。如果与缓存分配策略一致，则应将整个接收到的响应存储在其缓存中。
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[sic]请求标头字段允许客户端为服务器的利益指定从中获取请求URI的资源的地址（URI）（“Referer”，尽管标头字段拼写错误。）Referer请求标头允许服务器生成指向资源的反向链接列表，以供感兴趣、记录、，优化缓存等。它还允许跟踪过时或键入错误的链接进行维护。如果请求URI是从没有自己URI的源（如用户键盘的输入）获取的，则不能发送Referer字段。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
Referer=“Referer”：（绝对的、相对的）
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 relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment. See section 15.1.3 for security considerations.
如果字段值是相对URI，则应相对于请求URI进行解释。URI不能包含片段。安全注意事项见第15.1.3节。
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. This field MAY also be used with any 3xx (Redirection) response to indicate the minimum time the user-agent is asked wait before issuing the redirected request. 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（服务不可用）响应一起使用，以指示服务预计对请求客户端不可用的时间。此字段还可与任何3xx（重定向）响应一起使用，以指示在发出重定向请求之前要求用户代理等待的最短时间。此字段的值可以是HTTP日期，也可以是响应时间后的整数秒数（十进制）。
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Retry After=“Retry After”“：”（HTTP日期|增量秒）
Two examples of its use are
使用它的两个例子是
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
在后一个示例中，延迟为2分钟。
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.
服务器响应标头字段包含有关源服务器用于处理请求的软件的信息。该字段可以包含多个产品令牌（第3.8节）和标识服务器和任何重要子产品的注释。产品标记按其对识别应用程序的重要性顺序列出。
Server = "Server" ":" 1*( product | comment )
Server = "Server" ":" 1*( product | comment )
Example:
例子：
Server: CERN/3.0 libwww/2.17
Server: CERN/3.0 libwww/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.45).
如果通过代理转发响应，则代理应用程序不得修改服务器响应头。相反，它应该包括一个过孔字段（如第14.45节所述）。
Note: Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable option.
注意：透露服务器的特定软件版本可能会使服务器机器更容易受到针对已知包含安全漏洞的软件的攻击。鼓励服务器实现者将此字段设置为可配置选项。
The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in section 3.6).
TE请求头字段指示它愿意在响应中接受哪些扩展传输编码，以及它是否愿意在分块传输编码中接受尾部字段。其值可能包括关键字“拖车”和/或带有可选接受参数的扩展传输编码名称的逗号分隔列表（如第3.6节所述）。
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
TE = "TE" ":" #( t-codings )
t-codings = "trailers" | ( transfer-extension [ accept-params ] )
The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, as defined in section 3.6.1. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
关键字“拖车”的出现表明客户愿意接受分块传输编码中的拖车字段，如第3.6.1节所定义。此关键字保留用于传输编码值，即使它本身并不表示传输编码。
Examples of its use are:
例如：
TE: deflate
TE:
TE: trailers, deflate;q=0.5
TE: deflate
TE:
TE: trailers, deflate;q=0.5
The TE header field only applies to the immediate connection. Therefore, the keyword MUST be supplied within a Connection header field (section 14.10) whenever TE is present in an HTTP/1.1 message.
TE header字段仅适用于直接连接。因此，每当HTTP/1.1消息中存在TE时，必须在连接头字段（第14.10节）中提供关键字。
A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules:
服务器根据TE字段，使用以下规则测试传输编码是否可接受：
1. The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, or that it will attempt to buffer the response on behalf of downstream recipients.
1. “分块”传输编码总是可以接受的。如果列出关键字“trailes”，则客户端表示它愿意代表自己和任何下游客户端接受分块响应中的trailer字段。这意味着，如果给定，客户端将声明所有下游客户端都愿意接受转发响应中的尾部字段，或者它将尝试代表下游接收方缓冲响应。
Note: HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering the entire response.
注意：HTTP/1.1没有定义任何方法来限制分块响应的大小，从而确保客户端能够缓冲整个响应。
2. If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in section 3.9, a qvalue of 0 means "not acceptable.")
2. 如果正在测试的传输编码是TE字段中列出的传输编码之一，则它是可接受的，除非它附带Q0值。（如第3.9节所定义，Q值为0表示“不可接受”。）
3. If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. The "chunked" transfer-coding always has a qvalue of 1.
3. 如果可接受多个传输编码，则首选具有最高非零Q值的可接受传输编码。“分块”传输编码的Q值始终为1。
If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding is always acceptable.
如果TE字段值为空或不存在TE字段，则唯一的传输编码为“分块”。始终可以接受没有传输编码的消息。
The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding.
Trailer general字段值表示给定的头字段集存在于使用分块传输编码编码的消息的尾部。
Trailer = "Trailer" ":" 1#field-name
Trailer = "Trailer" ":" 1#field-name
An HTTP/1.1 message SHOULD include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient to know which header fields to expect in the trailer.
HTTP/1.1消息应在使用非空尾部的分块传输编码的消息中包含尾部标头字段。这样做可以让收件人知道拖车中需要哪些标题字段。
If no Trailer header field is present, the trailer SHOULD NOT include any header fields. See section 3.6.1 for restrictions on the use of trailer fields in a "chunked" transfer-coding.
如果不存在拖车头字段，拖车不应包括任何头字段。有关在“分块”传输编码中使用拖车字段的限制，请参见第3.6.1节。
Message header fields listed in the Trailer header field MUST NOT include the following header fields:
拖车标题字段中列出的消息标题字段不得包括以下标题字段：
. Transfer-Encoding
. 传输编码
. Content-Length
. 内容长度
. Trailer
. 拖车
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-coding in that the transfer-coding is a property of the message, not of the entity.
Transfer Encoding general header（传输编码通用头）字段指示已应用于邮件正文的转换类型（如果有），以便在发件人和收件人之间安全地传输邮件。这与内容编码不同，因为传输编码是消息的属性，而不是实体的属性。
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-codings are defined in section 3.6. An example is:
第3.6节定义了转移编码。例如：
Transfer-Encoding: chunked
传输编码：分块
If multiple encodings have been applied to an entity, the transfer-codings MUST be listed in the order in which they were applied. Additional information about the encoding parameters MAY be provided by other entity-header fields not defined by this specification.
如果对一个实体应用了多个编码，则必须按应用顺序列出传输编码。关于编码参数的附加信息可由本规范未定义的其他实体头字段提供。
Many older HTTP/1.0 applications do not understand the Transfer-Encoding header.
许多较旧的HTTP/1.0应用程序不理解传输编码头。
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 MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
Upgrade general标头允许客户端指定它支持的其他通信协议，以及如果服务器认为适合切换协议，它希望使用的其他通信协议。服务器必须在101（交换协议）响应中使用Upgrade header字段来指示正在交换的协议。
Upgrade = "Upgrade" ":" 1#product
Upgrade = "Upgrade" ":" 1#product
For example,
例如
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
Upgrade: 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 header字段旨在提供从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 header字段仅适用于在现有传输层连接上交换应用层协议。升级不能用于坚持协议更改；服务器对其的接受和使用是可选的。协议更改后应用层通信的功能和性质完全取决于所选的新协议，尽管更改协议后的第一个操作必须是对包含升级头字段的初始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.
升级标头字段仅适用于即时连接。因此，每当HTTP/1.1消息中出现升级时，必须在连接头字段（第14.10节）中提供upgrade关键字。
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 header字段不能用于指示切换到其他连接上的协议。为此，更适合使用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版本规则和本规范的未来更新所定义。任何令牌都可以用作协议名称；但是，只有当客户端和服务器都将名称与同一协议相关联时，它才有用。
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.
用户代理请求标头字段包含有关发起请求的用户代理的信息。这是出于统计目的，跟踪协议冲突，以及自动识别用户代理，以便调整响应以避免特定的用户代理限制。用户代理应在请求中包含此字段。该字段可以包含多个产品标记（第3.8节）和注释，标识代理和构成用户代理重要部分的任何子产品。按照惯例，产品标记按其识别应用程序的重要性顺序列出。
User-Agent = "User-Agent" ":" 1*( product | comment )
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
例子：
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. See section 13.6 for use of the Vary header field by caches.
Vary字段值表示一组请求头字段，当响应是新的时，这些字段完全确定是否允许缓存使用响应来答复后续请求，而无需重新验证。对于不可缓存或过时的响应，“更改”字段值会向用户代理建议用于选择表示的条件。Vary字段值“*”表示缓存无法从后续请求的请求头确定此响应是否为适当的表示形式。请参阅第13.6节，了解按缓存使用不同的标头字段。
Vary = "Vary" ":" ( "*" | 1#field-name )
Vary = "Vary" ":" ( "*" | 1#field-name )
An HTTP/1.1 server SHOULD include a Vary header field with any cacheable 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
HTTP/1.1服务器应该包含一个Vary头字段，该字段包含受服务器驱动协商约束的任何可缓存响应。这样做允许缓存正确解释该资源上的未来请求，并通知用户代理存在协商
on that resource. A server MAY include a Vary header field with a non-cacheable 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 varies at the time of the response.
关于这个资源。服务器可以包括具有受服务器驱动协商的不可缓存响应的Vary报头字段，因为这可以向用户代理提供关于响应在响应时变化的维度的有用信息。
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 for which the response is fresh.
由字段名列表组成的变量字段值表示为响应选择的表示基于选择算法，该算法在选择最合适的表示时仅考虑列出的请求头字段值。缓存可能会假定，在响应为新响应的持续时间内，将对具有相同值的所列字段名的未来请求进行相同的选择。
The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names are case-insensitive.
给出的字段名不限于本规范定义的标准请求头字段集。字段名不区分大小写。
A Vary field value of "*" signals that unspecified parameters not limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation. The "*" value MUST NOT be generated by a proxy server; it may only be generated by an origin server.
变量字段值“*”表示不限于请求头的未指定参数（例如，客户端的网络地址）在选择响应表示中起作用。“*”值不能由代理服务器生成；它只能由源服务器生成。
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 [9] 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 general header字段来指示请求时用户代理和服务器之间以及响应时源服务器和客户端之间的中间协议和收件人。它类似于RFC 822[9]中的“已接收”字段，用于跟踪消息转发、避免请求循环以及识别请求/响应链上所有发送方的协议能力。
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
received-protocol = [ protocol-name "/" ] protocol-version
protocol-name = token
protocol-version = token
received-by = ( host [ ":" port ] ) | pseudonym
pseudonym = token
Via = "Via" ":" 1#( received-protocol received-by [ comment ] )
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.
received protocol指示服务器或客户端沿请求/响应链的每个段接收的消息的协议版本。转发消息时，接收到的协议版本将附加到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”时，协议名是可选的。received by字段通常是随后转发邮件的收件人服务器或客户端的主机和可选端口号。但是，如果真实主机被视为敏感信息，则可能会被笔名替换。如果未给出端口，则可以假定它是所接收协议的默认端口。
Multiple Via field values represents 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头字段中使用注释来标识接收方代理或网关的软件，类似于用户代理和服务器头字段。但是，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用户代理发送到名为“fred”的内部代理，该代理使用HTTP/1.1将请求转发到nowhere.com上的公共代理，该代理通过将请求转发到www.ics.uci.edu上的源服务器来完成请求。然后，www.ics.uci.edu接收到的请求将具有以下Via头字段：
Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
Via:1.0 fred，1.1 nowhere.com（Apache/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.
默认情况下，用作通过网络防火墙的入口的代理和网关不应转发防火墙区域内主机的名称和端口。仅当显式启用时，才应传播此信息。如果未启用，则防火墙后面任何主机的主机接收的数据应替换为该主机的适当笔名。
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,
对于对隐藏内部结构有强烈隐私要求的组织，代理可以将具有相同接收协议值的Via头字段项的有序子序列组合到单个此类项中。例如
Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
Via:1.0瑞奇，1.1埃塞尔，1.1弗雷德，1.0露西
could be collapsed to
可能会倒塌到
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
Via:1.0瑞奇，1.1默兹，1.0露西
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.
应用程序不应该合并多个条目，除非它们都在同一个组织控制下，并且主机已经被假名替换。应用程序不得组合具有不同接收协议值的条目。
The Warning general-header field is used to carry additional information about the status or transformation of a message which might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message.
Warning general header字段用于携带有关消息状态或转换的附加信息，这些信息可能不会反映在消息中。此信息通常用于警告应用于消息实体体的缓存操作或转换可能缺乏语义透明度。
Warning headers are sent with responses using:
警告标题与响应一起发送，使用：
Warning = "Warning" ":" 1#warning-value
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text [SP warn-date]
警告值=警告代码SP警告代理SP警告文本[SP警告日期]
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
warn-code = 3DIGIT
warn-agent = ( host [ ":" port ] ) | pseudonym
; the name or pseudonym of the server adding
; the Warning header, for use in debugging
warn-text = quoted-string
warn-date = <"> HTTP-date <">
A response MAY carry more than one Warning header.
一个响应可能包含多个警告标题。
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.
警告文本应采用自然语言和字符集，以便接收响应的人类用户最容易理解。此决定可能基于任何可用知识，例如缓存或用户的位置、请求中的接受语言字段、响应中的内容语言字段等。默认语言为英语，默认字符集为ISO-8859-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 2047 [14].
如果使用ISO-8859-1以外的字符集，则必须使用RFC 2047[14]中描述的方法在警告文本中对其进行编码。
Warning headers can in general be applied to any message, however some specific warn-codes are specific to caches and can only be applied to response messages. New Warning headers SHOULD be added after any existing Warning headers. A cache MUST NOT delete any Warning header that it received with a message. 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.
具体的警告代码。然后，它必须添加在验证响应中收到的任何警告头。换句话说，警告标题是附加到最新相关响应的标题。
When multiple Warning headers are attached to a response, the user agent ought to inform the user of as many of them as possible, in the order that they appear in the response. If it is not possible to inform the user of all of the warnings, the user agent SHOULD follow these heuristics:
当多个警告头附加到响应时，用户代理应该按照它们在响应中出现的顺序通知用户尽可能多的警告头。如果无法将所有警告通知用户，则用户代理应遵循以下试探法：
- Warnings that appear early in the response take priority over those appearing later in the response.
- 响应早期出现的警告优先于响应后期出现的警告。
- Warnings in the user's preferred character set take priority over warnings in other character sets but with identical warn-codes and warn-agents.
- 用户首选字符集中的警告优先于其他字符集中的警告，但具有相同的警告代码和警告代理。
Systems that generate multiple Warning headers SHOULD order them with this user agent behavior in mind.
生成多个警告标头的系统应该在对其排序时牢记此用户代理行为。
Requirements for the behavior of caches with respect to Warnings are stated in section 13.1.2.
第13.1.2节规定了有关警告的缓存行为要求。
This is a list of the currently-defined warn-codes, each with a recommended warn-text in English, and a description of its meaning.
这是当前定义的警告代码列表，每个代码都有一个推荐的英文警告文本及其含义说明。
110 Response is stale MUST be included whenever the returned response is stale.
110无论何时返回的响应过时，都必须包括Response is stale。
111 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.
111如果缓存返回过时响应，因为无法访问服务器而导致重新验证响应的尝试失败，则必须包括重新验证失败。
112 Disconnected operation SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
112如果缓存故意与网络的其余部分断开连接一段时间，则应包括断开连接的操作。
113 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.
113如果缓存启发式地选择了大于24小时的新鲜度生存期，并且响应的期限大于24小时，则必须包括启发式过期。
199 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, besides presenting the warning to the user.
199杂项警告警告文本可能包括要呈现给人类用户或记录的任意信息。收到此警告的系统除了向用户显示警告外，不得采取任何自动操作。
214 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, or the entity-body of the response, unless this Warning code already appears in the response.
214如果中间缓存或代理应用更改响应的内容编码（如内容编码标头中所指定）或媒体类型（如内容类型标头中所指定）或响应的实体体的任何转换，则必须通过中间缓存或代理添加应用的转换，除非此警告代码已出现在响应中。
299 Miscellaneous persistent 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.
299杂项持续警告警告文本可能包括要呈现给人类用户或记录的任意信息。收到此警告的系统不得采取任何自动操作。
If an implementation sends a message with one or more Warning headers whose version is HTTP/1.0 or lower, then the sender MUST include in each warning-value a warn-date that matches the date in the response.
如果实现发送的消息包含一个或多个版本为HTTP/1.0或更低版本的警告标头，则发送方必须在每个警告值中包含与响应中的日期匹配的警告日期。
If an implementation receives a message with a warning-value that includes a warn-date, and that warn-date is different from the Date value in the response, then that warning-value MUST be deleted from the message before storing, forwarding, or using it. (This prevents bad consequences of naive caching of Warning header fields.) If all of the warning-values are deleted for this reason, the Warning header MUST be deleted as well.
如果实现接收到包含警告日期的警告值的消息，并且该警告日期与响应中的日期值不同，则必须在存储、转发或使用该消息之前从消息中删除该警告值。（这可以防止对警告标头字段进行简单缓存的不良后果。）如果因此删除了所有警告值，则还必须删除警告标头。
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 Authenticate响应头字段必须包含在401（未经授权）响应消息中。字段值由至少一个质询组成，该质询指示认证方案和适用于请求URI的参数。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" [43]. User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
HTTP访问身份验证过程在“HTTP身份验证：基本和摘要访问身份验证”[43]中描述。建议用户代理在解析WWW Authenticate字段值时特别小心，因为它可能包含多个质询，或者如果提供了多个WWW Authenticate标头字段，质询本身的内容可以包含以逗号分隔的身份验证参数列表。
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中的安全限制。虽然讨论中提出了一些降低安全风险的建议，但并没有包括对所揭示问题的最终解决方案。
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 implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company.
HTTP客户端通常对大量个人信息（例如用户名、位置、邮件地址、密码、加密密钥等）保密，因此应非常小心，以防止这些信息通过HTTP协议意外泄漏到其他来源。我们强烈建议为用户提供一个方便的界面来控制此类信息的传播，并且设计者和实施者在这方面要特别小心。历史表明，该领域的错误通常会造成严重的安全和/或隐私问题，并对实施者的公司造成高度负面的宣传。
A server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling can 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协议提供数据的人员有责任确保未经发布结果可识别的任何个人许可，不得分发此类材料。
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无法调节所传输数据的内容，也没有任何先验方法来确定任何给定请求上下文中任何特定信息的敏感性。因此，应用程序应尽可能多地向该信息的提供者提供对该信息的控制。在此上下文中，有四个标题字段值得特别提及：Server、Via、Referer和From。
Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementors SHOULD make the Server header field a configurable option.
透露服务器的特定软件版本可能会使服务器机器更容易受到针对已知包含安全漏洞的软件的攻击。实现者应该将服务器头字段设置为可配置选项。
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.
作为通过网络防火墙的入口的代理应采取特别的预防措施，以传输识别防火墙后面主机的头信息。特别是，他们应该删除防火墙后面生成的任何Via字段，或者用经过消毒的版本进行替换。
The Referer header 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
Referer标题允许研究阅读模式并绘制反向链接。虽然它可能非常有用，但如果用户详细信息不与文档中包含的信息分离，它的功能可能会被滥用
the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.
推荐人。即使删除了个人信息，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.
“发件人”字段中发送的信息可能与用户的隐私利益或其网站的安全策略相冲突，因此，在用户无法禁用、启用和修改字段内容的情况下，不应传输该信息。用户必须能够在用户首选项或应用程序默认配置中设置此字段的内容。
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.
我们建议（尽管不要求）为用户提供一个方便的切换界面，以启用或禁用发送发件人和参考人信息。
The User-Agent (section 14.43) or Server (section 14.38) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism.
用户代理（第14.43节）或服务器（第14.38节）标题字段有时可用于确定特定客户机或服务器具有可能被利用的特定安全漏洞。不幸的是，同样的信息经常被用于其他有价值的目的，而HTTP目前没有更好的机制。
Because the source of a link might be private information or might 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信息的发送。
Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
如果引用页面是使用安全协议传输的，则客户端不应在（非安全）HTTP请求中包含引用者标头字段。
Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead
使用HTTP协议的服务的作者不应使用基于GET的表单提交敏感数据，因为这将导致在请求URI中对这些数据进行编码。许多现有服务器、代理和用户代理将在第三方可能可见的位置记录请求URI。服务器可以使用基于POST的表单提交
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 Language标头内容的用户代理在配置过程中包含一条消息，该消息会让用户意识到所涉及的隐私损失。
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 or not to 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 Language标头，并通过查找服务器生成的任何Variable response标头字段，询问用户是否开始向服务器发送Accept Language标头（如果检测到），这种发送可以提高服务质量。
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 ought to 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.
详细说明在每个请求中发送的用户自定义接受标头字段，特别是如果这些字段包含质量值，则服务器可以将其用作相对可靠和长期存在的用户标识符。这样的用户标识符将允许内容提供商进行点击跟踪，并允许协作内容提供商匹配跨服务器点击跟踪或形成单个用户的提交。请注意，对于许多不在代理后面的用户，运行用户代理的主机的网络地址也将用作长期用户标识符。在使用代理来增强隐私的环境中，用户代理在向最终用户提供accept标头配置选项时应该保守。作为一种极端的隐私措施，代理可以过滤中继请求中的accept头。提供高度标头可配置性的通用用户代理应警告用户可能涉及的隐私损失。
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源服务器的实现应该小心地将HTTP请求返回的文档限制为服务器管理员想要的文档。如果HTTP服务器将HTTP URI直接转换为文件系统调用，则服务器必须特别注意不要提供不打算传递给HTTP客户端的文件。例如，UNIX、Microsoft Windows和其他操作系统使用“.”作为路径组件，以指示高于当前目录级别的目录级别。在这样的系统上，如果HTTP服务器允许访问那些通过HTTP服务器可访问的资源之外的资源，则必须禁止请求URI中的任何此类构造。类似地，仅用于服务器内部引用的文件（如访问控制文件、配置文件和脚本代码）必须受到保护，以防止不当检索，因为它们可能包含敏感信息。经验表明，这种HTTP服务器实现中的小错误已经转化为安全风险。
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的客户端严重依赖域名服务，因此通常容易受到基于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. It is proper for these lookups to 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客户端应该依赖其名称解析器来确认IP号码/DNS名称关联，而不是缓存以前主机名查找的结果。许多平台已经可以在适当的时候在本地缓存主机名查找，并且应该将它们配置为这样做。但是，只有当名称服务器报告的TTL（生存时间）信息使得缓存的信息可能仍然有用时，才适合缓存这些查找。
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 [24], the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability.
如果HTTP客户端不遵守此规则，则当以前访问的服务器的IP地址更改时，它们可能被欺骗。随着网络重新编号预计将变得越来越普遍[24]，这种形式的攻击的可能性将增加。因此，遵守此要求可以减少此潜在的安全漏洞。
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名称的复制服务器的客户端的负载平衡行为，并降低了用户在访问使用该策略的站点时遇到故障的可能性。
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.
如果一台服务器支持多个彼此不信任的组织，那么它必须检查在所述组织控制下生成的响应中的位置和内容位置头的值，以确保它们不会试图使其无权访问的资源无效。
RFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details.
RFC 1806[35]是HTTP中经常实现的内容处置（见第19.5.1节）头的来源，它有许多非常严重的安全考虑因素。内容处置不是HTTP标准的一部分，但由于它被广泛实施，我们正在为实施者记录其使用和风险。有关详细信息，请参见RFC 2183[49]（更新了RFC 1806）。
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
现有HTTP客户端和用户代理通常无限期地保留身份验证信息。HTTP/1.1。不提供服务器指示客户端丢弃这些缓存凭据的方法。这是一个需要进一步扩展到HTTP的重大缺陷。凭据缓存可能干扰应用程序安全模型的情况包括但不限于：
- Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt the user for credentials.
- 已空闲较长时间的客户端，在此之后服务器可能希望使客户端重新向用户请求凭据。
- Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which the server side of the application `knows' that there is no further reason for the client to retain the credentials.
- 包含会话终止指示的应用程序（如页面上的“注销”或“提交”按钮），在此指示之后，应用程序的服务器端“知道”客户端没有进一步的理由保留凭据。
This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
目前正在进行单独研究。对于这个问题的一部分，有许多解决方法，我们鼓励在屏幕保护程序、空闲超时和其他方法中使用密码保护，以缓解这个问题固有的安全问题。特别是，鼓励缓存凭据的用户代理提供易于访问的机制，以便在用户控制下丢弃缓存的凭据。
By their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
就其本质而言，HTTP代理是中间人，代表了中间人攻击的机会。代理在其上运行的系统受损可能会导致严重的安全和隐私问题。代理可以访问安全相关信息、个人用户和组织的个人信息以及属于用户和内容提供商的专有信息。一个被破坏的代理，或者一个在不考虑安全和隐私考虑的情况下实现或配置的代理，可能被用于实施一系列潜在的攻击。
Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed and followed. (Section 15.1.1).
代理操作员应保护代理运行的系统，因为他们将保护任何包含或传输敏感信息的系统。特别是，在代理处收集的日志信息通常包含高度敏感的个人信息和/或有关组织的信息。应仔细保护日志信息，并制定和遵循适当的使用指南。（第15.1.1节）。
Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected as sensitive information.
缓存代理提供了额外的潜在漏洞，因为缓存内容是恶意攻击的诱人目标。由于缓存内容在HTTP请求完成后仍然存在，因此在用户认为信息已从网络中删除很久之后，对缓存的攻击可能会泄露信息。因此，缓存内容应作为敏感信息进行保护。
Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to proxy operators (especially the default configuration).
代理实现者应该考虑它们的设计和编码决策的隐私和安全影响，以及它们为代理运营商提供的配置选项（特别是默认配置）。
Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve this problem.
代理的用户需要意识到他们并不比运行代理的人更可信；HTTP本身无法解决这个问题。
The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification.
在适当的情况下，明智地使用加密技术可能足以防止广泛的安全和隐私攻击。这种加密技术超出了HTTP/1.1规范的范围。
They exist. They are hard to defend against. Research continues. Beware.
它们是存在的。他们很难防御。研究仍在继续。当心
16 Acknowledgments
16致谢
This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME [7]. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP and Internet mail message formats.
本规范大量使用了David H.Crocker为RFC 822定义的增广BNF和通用构造[9]。类似地，它重用了Nathaniel Borenstein和Ned Freed为MIME提供的许多定义[7]。我们希望在本规范中包含它们将有助于减少过去对HTTP和Internet邮件格式之间关系的混淆。
The HTTP protocol has evolved considerably over the 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协议在过去几年中有了很大的发展。它受益于一个庞大而活跃的开发者社区——许多人都参与了www talk邮件列表——正是这个社区对HTTP和万维网的成功负有最大责任。马克·安德烈森、罗伯特·凯利奥、丹尼尔·康诺利、鲍勃·丹尼、约翰·弗兰克斯、让·弗朗索瓦·格罗夫、菲利普·M·哈拉姆·贝克、哈肯·W·李、阿里·洛托宁、罗布·麦库尔、卢·蒙图利、戴夫·拉格特、托尼·桑德斯和马克·范海宁根在界定议定书早期方面所做的努力值得特别认可。
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 Ross Patterson Harald Tveit Alvestrand Albert Lunde Keith Ball John C. Mallery Brian Behlendorf Jean-Philippe Martin-Flatin 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 Josh Cohen
加里·亚当斯·罗斯·帕特森·哈拉尔德·特维特·阿尔维斯特兰德·阿尔伯特·隆德·基思·鲍尔约翰·C·马利里·布莱恩·贝伦多夫·让·菲利普·马丁·弗拉廷·保罗·伯查德·米特拉·莫里斯·莫里斯·迈克·考利肖·加文·尼科尔·罗曼·齐伯拉·比尔·佩里·迈克尔·A·多兰·杰弗里·佩里·大卫·J·芬德·斯科特·鲍尔斯·阿兰·弗里尔·欧文·里斯·马克·赫德隆德·路易吉·里佐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 Klesins Eric W.Sink Martijn Koster Simon E.Spero Alexei Kosut Richard N.Taylor David M.Kristol Robert S.Thau Daniel LaLiberte Bill（熊心）温曼·本·劳里·弗朗索瓦·耶尔盖·保罗·里奇·玛丽·艾伦·祖尔科·丹尼尔·杜波伊斯·乔什·科恩
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.
缓存设计的大部分内容和演示都来自个人的建议和评论，包括：Shel Kaphan、Paul Leach、Koen Holtman、David Morris和Larry Masinter。
Most of the specification of ranges is based on work originally done by Ari Luotonen and John Franks, with additional input from Steve Zilles.
范围的大部分规范都是基于Ari Luotonen和John Franks最初完成的工作，以及Steve 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, Josh Cohen, Alex Hopmann, Scott Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
吉姆·盖蒂斯（本文件现任编辑）特别感谢本文件前任编辑罗伊·菲尔丁，以及约翰·克莱辛、杰夫·莫格尔、保罗·利奇、戴夫·克里斯托尔、科恩·霍特曼、约翰·弗兰克斯、乔什·科恩、亚历克斯·霍普曼、斯科特·劳伦斯和拉里·马斯滕的帮助。特别感谢杰夫·莫格尔和斯科特·劳伦斯执行“必须/可能/应该”审计。
The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik Frystyk implemented RFC 2068 early, and we wish to thank them for the discovery of many of the problems that this document attempts to rectify.
Apache小组、《拼图》的作者Anselm Baird Smith和Henrik Frystyk很早就实现了RFC 2068，我们要感谢他们发现了本文档试图纠正的许多问题。
17 References
17参考文献
[1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995.
[1] Alvestrand，H.，“语言识别标签”，RFC1766，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, March 1993.
[2] Anklesaria，F.，McCahill，M.，Lindner，P.，Johnson，D.，Torrey，D.和B.Alberti，“互联网地鼠协议（分布式文档搜索和检索协议）”，RFC 1436，1993年3月。
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC 1630, June 1994.
[3] Berners Lee，T.，“WWW中的通用资源标识符”，RFC1630，1994年6月。
[4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[4] Berners Lee，T.，Masinter，L.和M.McCahill，“统一资源定位器（URL）”，RFC 17381994年12月。
[5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[5] Berners Lee，T.和D.Connolly，“超文本标记语言-2.0”，RFC 18661995年11月。
[6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[6] Berners Lee，T.，Fielding，R.和H.Frystyk，“超文本传输协议——HTTP/1.0”，RFC 1945，1996年5月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[7] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[8] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1123, October 1989.
[8] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1123，1989年10月。
[9] Crocker, D., "Standard for The Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[9] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[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] Davis，F.，Kahle，B.，Morris，H.，Salem，J.，Shen，T.，Wang，R.，Sui，J.，和M.Grinbaum，“WAIS接口协议原型功能规范”（v1.5），Thinking Machines公司，1990年4月。
[11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808, June 1995.
[11] 菲尔丁，R.，“相对统一资源定位器”，RFC 1808，1995年6月。
[12] Horton, M. and R. Adams, "Standard for Interchange of USENET Messages", RFC 1036, December 1987.
[12] Horton，M.和R.Adams，“USENET消息交换标准”，RFC 1036，1987年12月。
[13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, February 1986.
[13] Kantor，B.和P.Lapsley，“网络新闻传输协议”，RFC 977，1986年2月。
[14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[14] Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.
[15] Nebel，E.和L.Masinter，“基于表单的HTML文件上传”，RFC 18671995年11月。
[16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[16] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[17] Postel, J., "Media Type Registration Procedure", RFC 1590, November 1996.
[17] Postel，J.，“媒体类型注册程序”，RFC 1590，1996年11月。
[18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[18] Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[19] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[20] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994.
[20] Sollins，K.和L.Masinter，“统一资源名称的功能要求”，RFC 1737，1994年12月。
[21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
[21] US-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. 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.
[22] ISO-8859。国际标准信息处理8位单字节编码图形字符集第1部分：拉丁字母表1。第2部分：拉丁字母表2，ISO-8859-21987。第3部分：拉丁字母表3，ISO-8859-31988。第4部分：拉丁字母表4，ISO-8859-41988。第5部分：拉丁/西里尔字母，ISO-8859-51988。第6部分：拉丁/阿拉伯语字母表，ISO-8859-61987。第7部分：拉丁/希腊字母表，ISO-8859-71987。第8部分：拉丁/希伯来字母表，ISO-8859-81988。第9部分：拉丁字母表5，ISO-8859-91990。
[23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995.
[23] Meyers，J.和M.Rose，“Content-MD5标题字段”，RFC 18641995年10月。
[24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[24] Carpenter，B.和Y.Rekhter，“重新编号需要工作”，RFC 1900，1996年2月。
[25] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[25] Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC 1952，1996年5月。
[26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35, Dec. 1995. Slightly revised version of paper in Proc. 2nd International WWW Conference '94: Mosaic and the Web, Oct. 1994, which is available at http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat ency.html.
[26] 文卡塔·帕德马纳班和杰弗里·莫格尔。“改善HTTP延迟”，计算机网络和ISDN系统，v。第28页，第25-35页，1995年12月。在Proc中稍微修订的文件版本。第二届国际WWW会议'94:Mosaic和Web，1994年10月，可在http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat html。
[27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>, ISI Research Report ISI/RR-98-463, (original report dated Aug. 1996), USC/Information Sciences Institute, August 1998.
[27] Joe Touch、John Heidemann和Katia Obraczka。“HTTP性能分析”，<URL:http://www.isi.edu/touch/pubs/http-perf96/>，ISI研究报告ISI/RR-98-463，（原始报告日期为1996年8月），USC/信息科学研究所，1998年8月。
[28] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[28] Mills，D.，“网络时间协议（第3版）规范、实施和分析”，RFC13051992年3月。
[29] Deutsch, P., "DEFLATE Compressed Data Format Specification version 1.3", RFC 1951, May 1996.
[29] Deutsch，P.，“DEFLATE压缩数据格式规范1.3版”，RFC1951，1996年5月。
[30] S. Spero, "Analysis of HTTP Performance Problems," http://sunsite.unc.edu/mdma-release/http-prob.html.
[30] S.Spero，“HTTP性能问题分析，”http://sunsite.unc.edu/mdma-release/http-prob.html.
[31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format Specification version 3.3", RFC 1950, May 1996.
[31] Deutsch，P.和J.Gailly，“ZLIB压缩数据格式规范3.3版”，RFC 1950，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] Franks，J.，Hallam Baker，P.，Hostetler，J.，Leach，P.，Lootonen，A.，Sink，E.和L.Stewart，“HTTP的扩展：摘要访问认证”，RFC 2069，1997年1月。
[33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[33] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[34] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[34] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[35] Troost, R. and Dorner, S., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 1806, June 1995.
[35] Troost，R.和Dorner，S.，“在互联网信息中传达呈现信息：内容处置标题”，RFC 1806，1995年6月。
[36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and Interpretation of HTTP Version Numbers", RFC 2145, May 1997. [jg639]
[36] Mogul，J.，Fielding，R.，Gettys，J.和H.Frystyk，“HTTP版本号的使用和解释”，RFC 2145，1997年5月。[jg639]
[37] Palme, J., "Common Internet Message Headers", RFC 2076, February 1997. [jg640]
[37] Palme，J.，“通用互联网消息头”，RFC 2076，1997年2月。[jg640]
[38] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO-10646", RFC 2279, January 1998. [jg641]
[38] “UTF-8，Unicode和ISO-10646的转换格式”，RFC 2279，1998年1月。[jg641]
[39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E., Lie, H., and C. Lilley. "Network Performance Effects of HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes France, September 1997.[jg642]
[39] 尼尔森，H.F.，盖蒂斯，J.，贝尔德·史密斯，A.，普鲁德·霍默，E.，李，H.，和C.莉莉。“HTTP/1.1、CSS1和PNG对网络性能的影响”，《ACM SIGCOMM'97会议录》，法国戛纳，1997年9月。[jg642]
[40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [jg643]
[40] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。[jg643]
[41] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [jg644]
[41] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。[jg644]
[42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax and Semantics", RFC 2396, August 1998. [jg645]
[42] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法和语义”，RFC 2396，1998年8月。[jg645]
[43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [jg646]
[43] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，Sink，E.和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。[jg646]
[44] Luotonen, A., "Tunneling TCP based protocols through Web proxy servers," Work in Progress. [jg647]
[44] Luotonen，A.，“通过Web代理服务器挖掘基于TCP的协议”，正在进行中。[jg647]
[45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997.
[45] Palme，J.和A.Hopmann，“聚合文档的MIME电子邮件封装，如HTML（MHTML）”，RFC 2110，1997年3月。
[46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[46] Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[47] Masinter, L., "Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)", RFC 2324, 1 April 1998.
[47] Masinter，L.，“超文本咖啡壶控制协议（HTCPCP/1.0）”，RFC 23241998年4月1日。
[48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[48] Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[49] Troost，R.，Dorner，S.和K.Moore，“在互联网消息中传达呈现信息：内容处置标题字段”，RFC 2183，1997年8月。
18 Authors' Addresses
18作者地址
Roy T. Fielding Information and Computer Science University of California, Irvine Irvine, CA 92697-3425, USA
罗伊·T·菲尔丁加利福尼亚大学信息科学与计算机学院，欧文·欧文，CA92697－325，美国
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
Fax: +1 (949) 824-1715
EMail: fielding@ics.uci.edu
James Gettys World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
James Gettys万维网联盟麻省理工学院计算机科学实验室545美国马萨诸塞州剑桥技术广场02139
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Fax: +1 (617) 258 8682
EMail: jg@w3.org
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, USA
美国加利福尼亚州帕洛阿尔托大学大道250号康柏计算机公司杰弗里·C·莫格尔西部研究实验室，邮编94305
EMail: mogul@wrl.dec.com
EMail: mogul@wrl.dec.com
Henrik Frystyk Nielsen World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Henrik Frystyk Nielsen万维网联盟麻省理工学院计算机科学实验室美国马萨诸塞州剑桥技术广场545号02139
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Fax: +1 (617) 258 8682
EMail: frystyk@w3.org
Larry Masinter Xerox Corporation 3333 Coyote Hill Road Palo Alto, CA 94034, USA
美国加利福尼亚州帕洛阿尔托郊狼山路3333号拉里·马斯特施乐公司，邮编94034
EMail: masinter@parc.xerox.com
EMail: masinter@parc.xerox.com
Paul J. Leach Microsoft Corporation 1 Microsoft Way Redmond, WA 98052, USA
Paul J.Leach微软公司美国华盛顿州微软路雷德蒙1号，邮编：98052
EMail: paulle@microsoft.com
EMail: paulle@microsoft.com
Tim Berners-Lee Director, World Wide Web Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, USA
Tim Berners Lee，万维网联盟麻省理工学院计算机科学实验室主任，美国马萨诸塞州剑桥技术广场545号，邮编02139
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
19 Appendices
19附录
In addition to defining the HTTP/1.1 protocol, this document serves as the specification for the Internet media type "message/http" and "application/http". The message/http type can be used to enclose a single HTTP request or response message, provided that it obeys the MIME restrictions for all "message" types regarding line length and encodings. The application/http type can be used to enclose a pipeline of one or more HTTP request or response messages (not intermixed). The following is to be registered with IANA [17].
除了定义HTTP/1.1协议外，本文档还作为Internet媒体类型“message/HTTP”和“application/HTTP”的规范。message/http类型可用于封装单个http请求或响应消息，前提是它遵守有关行长度和编码的所有“消息”类型的MIME限制。application/http类型可用于封装一个或多个http请求或响应消息（不混合）的管道。以下内容将在IANA注册[17]。
Media Type name: message Media subtype name: http Required parameters: none Optional parameters: version, msgtype version: The HTTP-Version number of the enclosed message (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: only "7bit", "8bit", or "binary" are permitted Security considerations: none
媒体类型名称：消息媒体子类型名称：http必需参数：无可选参数：版本，msgtype版本：随附消息的http版本号（例如，“1.1”）。如果不存在，则可从正文的第一行确定版本。msgtype：消息类型--“请求”或“响应”。如果不存在，则可从主体的第一行确定类型。编码注意事项：仅允许使用“7位”、“8位”或“二进制”安全注意事项：无
Media Type name: application Media subtype name: http Required parameters: none Optional parameters: version, msgtype version: The HTTP-Version number of the enclosed messages (e.g., "1.1"). If not present, the version can be determined from the first line of the body. msgtype: The message type -- "request" or "response". If not present, the type can be determined from the first line of the body. Encoding considerations: HTTP messages enclosed by this type are in "binary" format; use of an appropriate Content-Transfer-Encoding is required when transmitted via E-mail. Security considerations: none
媒体类型名称：应用程序媒体子类型名称：http必需参数：无可选参数：版本，msgtype版本：随附消息的http版本号（例如，“1.1”）。如果不存在，则可从正文的第一行确定版本。msgtype：消息类型--“请求”或“响应”。如果不存在，则可从主体的第一行确定类型。编码注意事项：此类型包含的HTTP消息采用“二进制”格式；通过电子邮件传输时，需要使用适当的内容传输编码。安全考虑：无
When an HTTP 206 (Partial Content) response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these are transmitted as a multipart message-body. The media type for this purpose is called "multipart/byteranges".
当HTTP 206（部分内容）响应消息包括多个范围的内容（对多个非重叠范围的请求的响应）时，这些内容被作为多部分消息正文发送。用于此目的的媒体类型称为“multipart/byteranges”。
The multipart/byteranges media type includes two or more parts, each with its own Content-Type and Content-Range fields. The required boundary parameter specifies the boundary string used to separate each body-part.
multipart/byteranges媒体类型包括两个或多个部分，每个部分都有自己的内容类型和内容范围字段。所需的边界参数指定用于分隔每个实体零件的边界字符串。
Media Type name: multipart Media subtype name: byteranges Required parameters: boundary Optional parameters: none Encoding considerations: only "7bit", "8bit", or "binary" are permitted Security considerations: none
媒体类型名称：多部分媒体子类型名称：byteranges必需参数：边界可选参数：无编码注意事项：仅允许“7位”、“8位”或“二进制”安全注意事项：无
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 206 Partial Content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
--THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 500-999/8000
--此字符串分隔内容类型：应用程序/pdf内容范围：字节500-999/8000
...the first range... --THIS_STRING_SEPARATES Content-type: application/pdf Content-range: bytes 7000-7999/8000
…第一个范围--此字符串分隔内容类型：应用程序/pdf内容范围：字节7000-7999/8000
...the second range --THIS_STRING_SEPARATES--
…第二个范围--这个字符串--
Notes:
笔记：
1) Additional CRLFs may precede the first boundary string in the entity.
1) 实体中第一个边界字符串之前可能会有其他CRLF。
2) Although RFC 2046 [40] permits the boundary string to be quoted, some existing implementations handle a quoted boundary string incorrectly.
2) 尽管RFC 2046[40]允许引用边界字符串，但一些现有实现不正确地处理引用的边界字符串。
3) A number of browsers and servers were coded to an early draft of the byteranges specification to use a media type of multipart/x-byteranges, which is almost, but not quite compatible with the version documented in HTTP/1.1.
3) 许多浏览器和服务器被编码到byteranges规范的早期草案中，以使用一种媒体类型的multipart/x-byteranges，它几乎与HTTP/1.1中记录的版本兼容，但并不完全兼容。
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.
客户端在解析状态行时应该是宽容的，而服务器在解析请求行时应该是宽容的。特别是，即使只需要一个SP，它们也应该在字段之间接受任意数量的SP或HT字符。
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 not labeling the entity is preferred over labeling the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1 and 3.4.1.
实体实体的字符集应标记为该实体内使用的字符代码的最低公分母，但不标记实体优于使用标签US-ASCII或ISO-8859-1标记实体。见第3.7.1节和第3.4.1节。
Additional rules for requirements on parsing and encoding of dates and other potential problems with date encodings include:
有关日期解析和编码的要求以及日期编码的其他潜在问题的其他规则包括：
- 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).
- HTTP/1.1客户端和缓存应假定RFC-850日期（看起来在未来超过50年）实际上已经过去（这有助于解决“2000年”问题）。
- 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.
- HTTP/1.1实现可以在内部表示解析的过期日期早于正确的值，但不能在内部表示解析的过期日期晚于正确的值。
- 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.
- 所有与到期相关的计算必须在格林尼治标准时间内完成。本地时区不得影响年龄或到期时间的计算或比较。
- 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.
- 如果HTTP标头错误地携带了时区不是GMT的日期值，则必须使用最保守的转换将其转换为GMT。
HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC 822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 2045 discusses mail, and HTTP has a few features that are different from those described in RFC 2045. 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使用了许多为Internet邮件定义的结构（RFC 822[9]）和多用途Internet邮件扩展（MIME[7]），允许以开放的各种表示形式和可扩展的机制传输实体。然而，RFC 2045讨论了邮件，HTTP有一些不同于RFC 2045中描述的特性。仔细选择这些差异是为了优化二进制连接的性能，允许在使用新媒体类型时有更大的自由度，使日期比较更容易，并承认一些早期HTTP服务器和客户端的做法。
This appendix describes specific areas where HTTP differs from RFC 2045. 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 might be required.
本附录描述了HTTP不同于RFC 2045的具体领域。到严格MIME环境的代理和网关应该意识到这些差异，并在必要时提供适当的转换。从MIME环境到HTTP的代理和网关也需要注意这些差异，因为可能需要进行一些转换。
HTTP is not a MIME-compliant protocol. 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 (as defined in RFC 2045[7]). Proxies/gateways are responsible for ensuring full compliance (where possible) when exporting HTTP messages to strict MIME environments.
HTTP不是MIME兼容协议。但是，HTTP/1.1消息可能包含一个MIME版本通用头字段，以指示用于构造消息的MIME协议版本。使用MIME版本头字段表示消息完全符合MIME协议（如RFC 2045[7]中所定义）。在将HTTP消息导出到严格的MIME环境时，代理/网关负责确保完全符合要求（如果可能）。
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
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.
MIME版本“1.0”是HTTP/1.1中使用的默认版本。但是，HTTP/1.1消息解析和语义是由本文档而不是MIME规范定义的。
RFC 2045 [7] requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in section 4 of RFC 2049 [48]. Section 3.7.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. RFC 2046 requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line
RFC 2045[7]要求互联网邮件实体在传输之前转换为规范形式，如RFC 2049[48]第4节所述。本文件第3.7.1节描述了通过HTTP传输时“文本”媒体类型的子类型所允许的格式。RFC 2046要求具有“文本”类型的内容将换行符表示为CRLF，并禁止在行外使用CR或LF
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.
中断序列。HTTP允许CRLF、bare CR和bare LF在通过HTTP传输消息时指示文本内容中的换行符。
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 RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of a Content-Encoding and by the fact that HTTP 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.
在可能的情况下，从HTTP到严格MIME环境的代理或网关应将本文档第3.7.1节中描述的文本媒体类型中的所有换行符转换为RFC 2049标准格式的CRLF。然而，请注意，由于存在内容编码，以及HTTP允许使用某些字符集（不使用八位字节13和10来表示CR和LF，如某些多字节字符集）这一事实，这可能会变得复杂。
Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
实现者应该注意，转换将破坏应用于原始内容的任何加密校验和，除非原始内容已经是规范形式。因此，对于在HTTP中使用此类校验和的任何内容，建议使用规范形式。
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节）简化日期比较过程。来自其他协议的代理和网关应确保消息中的任何日期头字段符合HTTP/1.1格式之一，并在必要时重写日期。
RFC 2045 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 a function equivalent to Content-Encoding. However, this parameter is not part of RFC 2045.)
RFC 2045不包含任何与HTTP/1.1的内容编码头字段等效的概念。由于这充当媒体类型的修饰符，因此从HTTP到MIME兼容协议的代理和网关必须在转发消息之前更改内容类型标头字段的值或解码实体正文。（互联网邮件内容类型的一些实验应用程序使用了媒体类型参数“conversions=<Content coding>”来执行与内容编码等效的功能。但是，该参数不是RFC 2045的一部分。）
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC 2045. 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不使用RFC 2045的内容传输编码（CTE）字段。从MIME兼容协议到HTTP的代理和网关必须在将响应消息传递到HTTP客户端之前删除任何非标识CTE（“引用的可打印”或“base64”）编码。
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
从HTTP到MIME兼容协议的代理和网关负责确保消息的格式和编码正确，以便在该协议上安全传输，其中“安全”
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/1.1 introduces the Transfer-Encoding header field (section 14.41). Proxies/gateways MUST remove any transfer-coding prior to forwarding a message via a MIME-compliant protocol.
HTTP/1.1引入了传输编码头字段（第14.41节）。在通过MIME兼容协议转发消息之前，代理/网关必须删除任何传输编码。
A process for decoding the "chunked" transfer-coding (section 3.6) can be represented in pseudo-code as:
解码“分块”传输编码的过程（第3.6节）可以用伪码表示为：
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
length := 0
read chunk-size, chunk-extension (if any) and CRLF
while (chunk-size > 0) {
read chunk-data and CRLF
append chunk-data to entity-body
length := length + chunk-size
read chunk-size and CRLF
}
read entity-header
while (entity-header not empty) {
append entity-header to existing header fields
read entity-header
}
Content-Length := length
Remove "chunked" from Transfer-Encoding
HTTP implementations which share code with MHTML [45] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see section 3.7.2) and does not interpret the content or any MIME header lines that might be contained therein.
与MHTML[45]实现共享代码的HTTP实现需要注意MIME行长度限制。因为HTTP没有这个限制，所以HTTP不会折叠长线。通过HTTP传输的MHTML消息遵循MHTML的所有约定，包括行长度限制和折叠、规范化等，因为HTTP将所有消息体作为有效负载传输（参见第3.7.2节），并且不解释其中可能包含的内容或任何MIME头行。
RFC 1945 and RFC 2068 document protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.1 applications. Implementors are advised to be aware of these features, but cannot rely upon their presence in, or interoperability with, other HTTP/1.1 applications. Some of these
RFC 1945和RFC 2068记录了一些现有HTTP实现使用的协议元素，但在大多数HTTP/1.1应用程序中并不一致且正确。建议实现者注意这些特性，但不能依赖它们在其他HTTP/1.1应用程序中的存在或与其他HTTP/1.1应用程序的互操作性。其中一些
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规范中得到了解决。
A number of other headers, such as Content-Disposition and Title, from SMTP and MIME are also often implemented (see RFC 2076 [37]).
SMTP和MIME中的许多其他标头（如内容处置和标题）也经常被实现（请参见RFC 2076[37]）。
The Content-Disposition response-header field has been proposed as a means for the origin server to suggest a default filename if the user requests that the content is saved to a file. This usage is derived from the definition of Content-Disposition in RFC 1806 [35].
如果用户请求将内容保存到文件中，则Content Disposition response header字段可作为源服务器建议默认文件名的一种方式。此用法源自RFC 1806[35]中的内容处置定义。
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
content-disposition = "Content-Disposition" ":"
disposition-type *( ";" disposition-parm )
disposition-type = "attachment" | disp-extension-token
disposition-parm = filename-parm | disp-extension-parm
filename-parm = "filename" "=" quoted-string
disp-extension-token = token
disp-extension-parm = token "=" ( token | quoted-string )
An example is
例如
Content-Disposition: attachment; filename="fname.ext"
Content-Disposition: attachment; filename="fname.ext"
The receiving user agent SHOULD NOT respect any directory path information present in the filename-parm parameter, which is the only parameter believed to apply to HTTP implementations at this time. The filename SHOULD be treated as a terminal component only.
接收用户代理不应尊重filename parm参数中存在的任何目录路径信息，这是目前认为应用于HTTP实现的唯一参数。文件名应仅作为终端组件处理。
If this header is used in a response with the application/octet-stream content-type, the implied suggestion is that the user agent should not display the response, but directly enter a `save response as...' dialog.
如果在具有应用程序/八位字节流内容类型的响应中使用此标头，则暗示用户代理不应显示响应，而应直接进入“将响应另存为…”对话框。
See section 15.5 for Content-Disposition security issues.
有关内容处置安全问题，请参见第15.5节。
It is beyond the scope of a protocol specification to mandate compliance with previous versions. HTTP/1.1 was deliberately designed, however, to make supporting previous versions easy. It is worth noting that, at the time of composing this specification (1996), we would expect commercial HTTP/1.1 servers to:
强制遵守以前的版本超出了协议规范的范围。然而，HTTP/1.1的设计初衷是为了使支持以前的版本变得容易。值得注意的是，在编写本规范（1996年）时，我们预计商业HTTP/1.1服务器将：
- recognize the format of the Request-Line for HTTP/0.9, 1.0, and 1.1 requests;
- 识别HTTP/0.9、1.0和1.1请求的请求行格式；
- understand any valid request in the format of HTTP/0.9, 1.0, or 1.1;
- 理解HTTP/0.9、1.0或1.1格式的任何有效请求；
- respond appropriately with a message in the same major version used by the client.
- 使用与客户端使用的主版本相同的消息进行适当响应。
And we would expect HTTP/1.1 clients to:
我们希望HTTP/1.1客户端能够：
- recognize the format of the Status-Line for HTTP/1.0 and 1.1 responses;
- 识别HTTP/1.0和1.1响应的状态行格式；
- understand any valid response in the format of HTTP/0.9, 1.0, or 1.1.
- 理解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. Some implementations implement the Keep-Alive version of persistent connections described in section 19.7.1 of RFC 2068 [33].
对于大多数HTTP/1.0实现，每个连接都是在请求之前由客户端建立的，在发送响应之后由服务器关闭。一些实现实现实现了RFC 2068[33]第19.7.1节中描述的持久连接的保持活动版本。
This section summarizes major differences between versions HTTP/1.0 and HTTP/1.1.
本节总结了HTTP/1.0和HTTP/1.1版本之间的主要差异。
19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP Addresses
19.6.1.1 更改以简化多主机Web服务器并保留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.
客户机和服务器支持主机请求头、在HTTP/1.1请求中缺少主机请求头（第14.23节）时报告错误以及接受绝对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
较旧的HTTP/1.0客户端假定IP地址和服务器之间存在一对一的关系；除了请求所指向的IP地址之外，没有其他已建立的机制来区分请求的预期服务器。上述变化将允许互联网，一旦旧的HTTP客户端不再常见，就可以从一个IP地址支持多个网站，从而大大简化大型可操作Web服务器，因为将多个IP地址分配给单个主机会产生严重问题。互联网还将能够恢复分配的IP地址，这些地址的唯一目的是允许在根级别HTTP URL中使用专用域名。考虑到Web的增长速度和已经部署的服务器数量，这是非常困难的
important that all implementations of HTTP (including updates to existing HTTP/1.0 applications) correctly implement these requirements:
重要的是，所有HTTP实现（包括对现有HTTP/1.0应用程序的更新）都正确实现这些要求：
- Both clients and servers MUST support the Host request-header.
- 客户端和服务器都必须支持主机请求头。
- A client that sends an HTTP/1.1 request MUST send a Host header.
- 发送HTTP/1.1请求的客户端必须发送主机头。
- Servers MUST report a 400 (Bad Request) error if an HTTP/1.1 request does not include a Host request-header.
- 如果HTTP/1.1请求不包含主机请求头，服务器必须报告400（错误请求）错误。
- Servers MUST accept absolute URIs.
- 服务器必须接受绝对URI。
Some clients and servers might wish to be compatible with some previous implementations of persistent connections in HTTP/1.0 clients and servers. Persistent connections in HTTP/1.0 are 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客户端可能正在向不理解连接的代理服务器发送Keep-Alive，然后代理服务器将错误地将其转发到下一个入站服务器，这将建立Keep-Alive连接，并导致挂起的HTTP/1.0代理等待响应关闭。结果是HTTP/1.0客户端在与代理对话时必须禁止使用Keep-Alive。
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. See section 14.10.
然而，与代理交谈是持久连接的最重要用途，因此禁止显然是不可接受的。因此，我们需要一些其他机制来指示需要持久连接，即使在与忽略连接的旧代理交谈时也可以安全地使用。持久连接是HTTP/1.1消息的默认连接；我们引入一个新的关键字（Connection:close）来声明非持久性。见第14.10节。
The original HTTP/1.0 form of persistent connections (the Connection: Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
原始HTTP/1.0形式的持久连接（连接：Keep-Alive和Keep-Alive头）记录在RFC2068中。[33]
This specification has been carefully audited to correct and disambiguate key word usage; RFC 2068 had many problems in respect to the conventions laid out in RFC 2119 [34].
本规范经过仔细审核，以纠正和消除关键词使用的歧义；RFC 2068在RFC 2119[34]中规定的公约方面存在许多问题。
Clarified which error code should be used for inbound server failures (e.g. DNS failures). (Section 10.5.5).
阐明了入站服务器故障（例如DNS故障）应使用的错误代码。（第10.5.5节）。
CREATE had a race that required an Etag be sent when a resource is first created. (Section 10.2.2).
CREATE有一个要求在首次创建资源时发送Etag的竞赛。（第10.2.2节）。
Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML [45].
内容库从规范中删除了：它没有得到广泛的实现，没有健壮的扩展机制，也没有简单、安全的方法来引入它。此外，它在MHTML中以类似但不完全相同的方式使用[45]。
Transfer-coding and message lengths all interact in ways that required fixing exactly when chunked encoding is used (to allow for transfer encoding that may not be self delimiting); it was important to straighten out exactly how message lengths are computed. (Sections 3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
传输编码和消息长度的交互方式都要求在使用分块编码时准确确定（以允许传输编码可能不是自定界的）；弄清楚消息长度是如何计算的非常重要。（第3.6、4.4、7.2.2、13.5.2、14.13、14.16节）
A content-coding of "identity" was introduced, to solve problems discovered in caching. (section 3.5)
引入了“标识”的内容编码，以解决缓存中发现的问题。（第3.5节）
Quality Values of zero should indicate that "I don't want something" to allow clients to refuse a representation. (Section 3.9)
质量值为零应该表示“我不想要什么”，以允许客户拒绝陈述。（第3.9节）
The use and interpretation of HTTP version numbers has been clarified by RFC 2145. Require proxies to upgrade requests to highest protocol version they support to deal with problems discovered in HTTP/1.0 implementations (Section 3.1)
RFC 2145澄清了HTTP版本号的使用和解释。需要代理将请求升级到它们支持的最高协议版本，以处理在HTTP/1.0实现中发现的问题（第3.1节）
Charset wildcarding is introduced to avoid explosion of character set names in accept headers. (Section 14.2)
引入字符集通配符是为了避免接受头中字符集名称的爆炸。（第14.2节）
A case was missed in the Cache-Control model of HTTP/1.1; s-maxage was introduced to add this missing case. (Sections 13.4, 14.8, 14.9, 14.9.3)
HTTP/1.1的缓存控制模型中遗漏了一个案例；引入s-maxage以添加此缺失案例。（第13.4、14.8、14.9、14.9.3节）
The Cache-Control: max-age directive was not properly defined for responses. (Section 14.9.3)
没有为响应正确定义Cache-Control:max-age指令。（第14.9.3节）
There are situations where a server (especially a proxy) does not know the full length of a response but is capable of serving a byterange request. We therefore need a mechanism to allow byteranges with a content-range not indicating the full length of the message. (Section 14.16)
有些情况下，服务器（尤其是代理）不知道响应的完整长度，但能够为byterange请求提供服务。因此，我们需要一种机制来允许内容范围不指示消息全长的byterange。（第14.16节）
Range request responses would become very verbose if all meta-data were always returned; by allowing the server to only send needed headers in a 206 response, this problem can be avoided. (Section 10.2.7, 13.5.3, and 14.27)
如果总是返回所有元数据，范围请求响应将变得非常冗长；通过允许服务器在206响应中只发送所需的报头，可以避免此问题。（第10.2.7、13.5.3和14.27节）
Fix problem with unsatisfiable range requests; there are two cases: syntactic problems, and range doesn't exist in the document. The 416 status code was needed to resolve this ambiguity needed to indicate an error for a byte range request that falls outside of the actual contents of a document. (Section 10.4.17, 14.16)
解决无法满足范围请求的问题；有两种情况：语法问题和文档中不存在范围。需要416状态代码来解决这种模糊性，这种模糊性需要指示超出文档实际内容的字节范围请求的错误。（第10.4.17、14.16节）
Rewrite of message transmission requirements to make it much harder for implementors to get it wrong, as the consequences of errors here can have significant impact on the Internet, and to deal with the following problems:
重写消息传输要求，使实施者更难出错，因为此处错误的后果可能会对互联网产生重大影响，并处理以下问题：
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where this was incorrectly placing a requirement on the behavior of an implementation of a future version of HTTP/1.x
1. 将“HTTP/1.1或更高版本”更改为“HTTP/1.1”，在这种情况下，对未来版本的HTTP/1.x的实现行为提出了错误的要求
2. Made it clear that user-agents should retry requests, not "clients" in general.
2. 明确指出，用户代理应该重试请求，而不是一般的“客户端”。
3. Converted requirements for clients to ignore unexpected 100 (Continue) responses, and for proxies to forward 100 responses, into a general requirement for 1xx responses.
3. 将客户端忽略意外100（继续）响应和代理转发100个响应的要求转换为1xx响应的一般要求。
4. Modified some TCP-specific language, to make it clearer that non-TCP transports are possible for HTTP.
4. 修改了一些特定于TCP的语言，以便更清楚地说明HTTP可以使用非TCP传输。
5. Require that the origin server MUST NOT wait for the request body before it sends a required 100 (Continue) response.
5. 要求源服务器在发送所需的100（Continue）响应之前不得等待请求正文。
6. Allow, rather than require, a server to omit 100 (Continue) if it has already seen some of the request body.
6. 如果服务器已经看到一些请求主体，则允许而不是要求服务器省略100（Continue）。
7. Allow servers to defend against denial-of-service attacks and broken clients.
7. 允许服务器抵御拒绝服务攻击和损坏的客户端。
This change adds the Expect header and 417 status code. The message transmission requirements fixes are in sections 8.2, 10.4.18, 8.1.2.2, 13.11, and 14.20.
此更改添加Expect标头和417状态代码。第8.2节、第10.4.18节、第8.1.2.2节、第13.11节和第14.20节介绍了信息传输要求。
Proxies should be able to add Content-Length when appropriate. (Section 13.5.2)
代理应该能够在适当的时候添加内容长度。（第13.5.2节）
Clean up confusion between 403 and 404 responses. (Section 10.4.4, 10.4.5, and 10.4.11)
清除403和404响应之间的混淆。（第10.4.4、10.4.5和10.4.11节）
Warnings could be cached incorrectly, or not updated appropriately. (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning also needed to be a general header, as PUT or other methods may have need for it in requests.
警告可能被不正确地缓存，或者没有适当地更新。（第13.1.2节、第13.2.4节、第13.5.2节、第13.5.3节、第14.9.3节和第14.46节）警告也需要是通用标题，因为PUT或其他方法在请求中可能需要它。
Transfer-coding had significant problems, particularly with interactions with chunked encoding. The solution is that transfer-codings become as full fledged as content-codings. This involves adding an IANA registry for transfer-codings (separate from content codings), a new header field (TE) and enabling trailer headers in the future. Transfer encoding is a major performance benefit, so it was worth fixing [39]. TE also solves another, obscure, downward interoperability problem that could have occurred due to interactions between authentication trailers, chunked encoding and HTTP/1.0 clients.(Section 3.6, 3.6.1, and 14.39)
传输编码有很大的问题，特别是与分块编码的交互。解决方案是，传输编码和内容编码一样成熟。这涉及到为传输编码（与内容编码分开）添加IANA注册表、新的标题字段（TE）以及将来启用拖车标题。传输编码是一个主要的性能优势，因此值得修复[39]。TE还解决了另一个模糊的向下互操作性问题，该问题可能是由于身份验证拖车、分块编码和HTTP/1.0客户端之间的交互而产生的。（第3.6、3.6.1和14.39节）
The PATCH, LINK, UNLINK methods were defined but not commonly implemented in previous versions of this specification. See RFC 2068 [33].
补丁、链接和取消链接方法已定义，但在本规范的早期版本中通常未实现。参见RFC 2068[33]。
The Alternates, Content-Version, Derived-From, Link, URI, Public and Content-Base header fields were defined in previous versions of this specification, but not commonly implemented. See RFC 2068 [33].
替代项、内容版本、派生自、链接、URI、公共和内容库标题字段在本规范的早期版本中定义，但通常未实现。参见RFC 2068[33]。
20 Index
20指数
Please see the PostScript version of this RFC for the INDEX.
有关索引，请参阅此RFC的PostScript版本。
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。