标签：desc requested 完成 address 附加 empty pes drive flow
part of Hypertext Transfer Protocol -- HTTP/1.1
RFC 2616 Fielding, et al.
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.
The Accept request-header field can be used to specify(指定) certain(某一，必然，确定的) media(媒体) types(类型) which are acceptable(可接受的，合理的) for the response. Accept headers can be used to indicate(标识) that the request is specifically(特有的，指定的) limited to a small set of desired(需要的) types, as in the case of（就...来说，至于...） a request for an in-line(内联) image.
Accept = "Accept" ":" #( media-range(媒体范围) [ accept-params (可接受的参数)] )
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.
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.
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".
The example
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."
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.
A more elaborate(复杂) example is
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."
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, */*
have the following precedence:
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
would cause the following values to be associated:
text/html;level=1 = 1
text/html = 0.7
text/plain = 0.3
image/jpeg = 0.5
text/html;level=2 = 0.4
text/html;level=3 = 0.7
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 = "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
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.
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.
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-Encoding" ":"
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
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.")
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly(明确的) listed in the header field.
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
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.
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.
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., "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.
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.
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 = "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,
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.
Note: This use of a prefix matching rule does not imply(暗示，说明) that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply(简单的，简易的) allows the use of prefix tags if this is the case.
The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor(权重因子) assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume(假设) that all languages are equally(相等的，公平的) acceptable. If an Accept-Language header is present, then all languages which are assigned a quality factor greater than 0 are acceptable.
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.
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.
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(行为，态度).
The Accept-Ranges response-header field allows the server to indicate(表明，标示，指示) its acceptance of range requests for a resource:
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.
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 = "Age" ":" age-value
age-value = delta-seconds
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.
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 = "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.
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.
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.
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.
Authorization = "Authorization" ":" credentials
HTTP access authentication is described in "HTTP Authentication:Basic and Digest Access Authentication". 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).
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:
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.
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.
3. If the response includes the "public" cache-control directive, it MAY be returned in reply to any subsequent request.
The Cache-Control general-header field is used to specify(指定) directives(指令) that MUST be obeyed(服从;遵守) by all caching (机械，机制) 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.
Note : that HTTP/1.0 caches might not implement(使生效，实现;) Cache-Control and might only implement Pragma(编译指示): no-cache (see section 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-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-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.
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:
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.)
private
Indicates that all or part of the response message is intended(打算) for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state(规定;陈述，声明) that the specified(指定) parts of the response are intended for only one user and are not a valid response for requests by other users. A private (non-shared) cache MAY cache the response.
Note: This usage of the word private only controls where the response may be cached, and cannot ensure(确保;) the privacy(隐私，秘密;) of the message content.
no-cache
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.
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(剩余的响应).
Note: Most HTTP/1.0 caches will not recognize(承认;识别;认出) or obey(遵守，遵循) this directive.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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(验证器).
Unspecified end-to-end revalidation
The request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validating conditional(视…而定的;[语]条件的，假定的;); the first cache along the path (if any) that holds a cache entry for this resource includes a cache-validating conditional with its current validator.
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.
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.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh, max-stale, or 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.
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 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.)
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.
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.
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.
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.
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.
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
Cache-Control: private, 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.
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).
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.
The Connection header has the following grammar:
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.
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,
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.
HTTP/1.1 applications that do not support persistent connections MUST include the "close" connection option in every message.
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 section19.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 codings are defined in section 3.5. An example of its use is
Content-Encoding: 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.
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.
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).
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 = "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(i.
区分，区别，辨别) 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
Content-Language: 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
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".
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 = "Content-Length" ":" 1*DIGIT
An example is
Content-Length: 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.
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.
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.
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.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
The value of Content-Location also defines(规定) the base URI for the entity.
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.
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.
If the Content-Location is a relative URI, the relative(相对的;相关的;) URI is interpreted(理解;解释) relative to the Request-URI.
The meaning of the Content-Location header in PUT or POST requests is undefined; servers are free to ignore it in those cases.
The Content-MD5 entity-header field, as defined(有定义的，明确的;) in RFC 1864, 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.)
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.
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.
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(段落;分段符号).
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.
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.
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.
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 section3.12.
Content-Range = "Content-Range" ":" content-range-spec
content-range-spec = byte-content-range-spec
byte-content-range-spec = bytes-unit SP
byte-range-resp-spec "/" ( instance-length | "*" )
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.
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.
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 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 "*".
Examples of byte-content-range-spec values, assuming(假定;取得) that the entity contains a total of 1234 bytes:
. The first 500 bytes: bytes 0-499/1234
. The second 500 bytes: bytes 500-999/1234
. All except for the first 500 bytes: bytes 500-1233/1234
. The last 500 bytes: bytes 734-1233/1234
When an HTTP message includes the content of a single range (for example, a response to a request for a single range, or to a request for a set of ranges that overlap(互搭，重叠;部分相同) without any holes(球洞;破洞;洞穴)), this content is transmitted(传播;发射，播送) with a Content-Range header, and a Content-Length header showing the number of bytes actually transferred. For example,
HTTP/1.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.
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.
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).
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).
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.
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 = "Content-Type" ":" media-type
Media types are defined in section 3.7. An example of the field is
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.
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 = "Date" ":" HTTP-date
An example is
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.
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.
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.
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.
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.
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(影响( affect的现在分词 );) its semantic value.
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).
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.26and 14.44. The entity tag MAY be used for comparison(比较，对照) with other entities from the same resource (see section 13.3.3).
ETag = "ETag" ":" entity-tag
Examples:
ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
The Expect request-header field is used to indicate that particular(特别的;详细的;独有的;挑剔的) server behaviors are required by the client.
Expect = "Expect" ":" 1#expectation
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.
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.
Comparison(比较，对照;) of expectation values is case-insensitive(大小写不敏感;不区分大小写;) for unquoted(结束引语) tokens (including the 100-continue token), and is case-sensitive for quoted-string expectation-extensions.
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.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
See section 8.2.3 for the use of the 100 (continue) status.
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.
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.
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:
Expires = "Expires" ":" HTTP-date
An example of its use is
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.
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").
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.)
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.
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).
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 = "From" ":" mailbox
An example is:
From: webmaster@w3.org
This header field MAY be used for logging purposes(目的;意志) and as a means for identifying(确认;辨认;认出) the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure(无安全的;不稳定的;) form of access protection. The interpretation(理解;解释，说明;) of this field is that the request is being performed(表演;履行;执行) on behalf(利益;维护;支持) of the person given, who accepts responsibility(责任;职责;负责任;责任感，责任心) for the method performed. In particular(特别的;), robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.
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.
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,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.
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:
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.
See sections 5.2 and 19.6.1.1 for other requirements(需要;所需的) relating(联系起来) to Host.
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 = "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 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.
A server MUST use the strong comparison(比较，对照;) function(功能，作用;) (see section 13.3.3) to compare the entity tags in 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.
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.
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.
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:
If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *
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(规格;说明书;详述).
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 = "If-Modified-Since" ":" HTTP-date
An example of the field is:
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:
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.
b) If the variant has been modified since the If-Modified-Since date, the response is exactly the same as for a normal 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.
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.
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.
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 subsequen(随后的;后来的;) request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived(衍生;导出;起源;由来) from the client‘s clock without correction(修改;改[纠]正;惩罚;有待改正) to the server‘s clock. Corrections for different time bases between client and server are at best approximate(接近于;近似于) due to network latency(潜伏;潜在因素).
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.
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.
As a special case, the value "*" matches any current entity of the resource.
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).
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.
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 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 section13.3.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
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.
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: *
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 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.
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" ":" ( entity-tag | HTTP-date )
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 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.
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 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).
If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
An example of the field is:
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 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.
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified.
Last-Modified = "Last-Modified" ":" HTTP-date
An example of its use is
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.
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 = "Location" ":" absoluteURI
An example is:
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.
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 = "Max-Forwards" ":" 1*DIGIT
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.
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).
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.
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 = "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(遵从的;依从的;).
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.
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.
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
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field value consists(包括;) of a challenge(战;质疑;盘问;怀疑) that indicates(指示;标示) the authentication scheme()策划，图谋 and parameters(因素，特征;) applicable to the proxy for this Request-URI.
Proxy-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.
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 = "Proxy-Authorization" ":" credentials
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 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.)
Byte range specifications(规格;载明;) in HTTP apply to the sequence of bytes in the entity-body (not necessarily the same as the message-body).
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
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.
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.
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.
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
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.
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.
Examples of byte-ranges-specifier values (assuming(假定;) an entity-body of length 10000):
- The first 500 bytes (byte offsets 0-499, inclusive): bytes=0-499
- The second 500 bytes (byte offsets 500-999, inclusive):bytes=500-999
- The final 500 bytes (byte offsets 9500-9999, inclusive):bytes=-500
- Or bytes=9500-
- The first and last bytes only (bytes 0 and 9999): bytes=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
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:
Range = "Range" ":" ranges-specifier
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.
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).
- 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.
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 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 = "Referer" ":" ( absoluteURI | relativeURI )
Example:
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.
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.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter(后者的;末了的;较后的) example, the delay is 2 minutes.
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 (section3.8) and comments identifying(确认;辨认;认出) the server and any significant subproducts(子积;子乘积;[). The product tokens are listed in order of their significance(意义;重要性;意思) for identifying the application.
Server = "Server" ":" 1*( product | comment )
Example:
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).
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 = "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.
Examples of its use are:
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.
A server tests whether a transfer-coding is acceptable(可接受的;合意的;), according to a TE field, using these rules:
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(接受的;受领的;).
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.
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.")
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.
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.
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 = "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.
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.
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 = "Transfer-Encoding" ":" 1#transfer-coding
Transfer-codings are defined in section 3.6. An example is:
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.
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 = "Upgrade" ":" 1#product
For example,
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).
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.
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.
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.
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.
The User-Agent request-header field contains information about the user agent originating(起源于，来自) the request. This is for statistical purposes, the tracing of protocol violations(违反), and automated recognition of user agents for the sake(缘故;理由;) of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens (section 3.8) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment )
Example:
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" ":" ( "*" | 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 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.
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 = "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.
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.
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.
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.
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:
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: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
could be collapsed(倒塌;崩溃;) to
Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
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 headers are sent with responses using:
Warning = "Warning" ":" 1#warning-value
warning-value = warn-code SP warn-agent SP warn-text
[SP warn-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.
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].
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.
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.
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.
112 Disconnected operation SHOULD be included if the cache is intentionally disconnected from the rest of the network for a period of time.
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.
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.
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.
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.
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.
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 = "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.
原文地址：https://www.w3.org/Protocols/rfc2616/rfc2616.html
RFC2616-HTTP1.1-Header Field Definitions(头字段规定部分—单词注释版)
标签：desc requested 完成 address 附加 empty pes drive flow
原文地址：https://www.cnblogs.com/zaking/p/9197019.html
