15.安全考虑这一部分是用来提醒程序开发人员,信息提供者,和HTTP/1.1中的安全限制的用户这篇 文档所叙述的事情.虽然这个讨论为减少安全风险确实提供了一些建议,但是它并不包括所透露问题的最终解决方案. |
15 Security ConsiderationsThis section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.1 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks. |
15.1 个人信息HTTP的客户机经常对大量的个人信息是敏感的(例如用户的名字,域,邮件地址,口令,密匙等.),并且应当(SHOULD)非常小心地防止这些信息无意 识地通过HTTP泄露到其他的主机.我们非常强烈地建议应该提供给用户一个方便的界面来控制这种信息的分发,并且设计者和使用者在这方面应该特别注意.历 史告诉我们在这方面的错误经常引起严重的安全和/或者机要问题并导致出现对使用者的公司非常不利的公开的情况. |
15.1 Personal InformationHTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company. |
15.1.1服务器日志信息的滥用服务器是处在存储个人数据的位置上,这些数据是关于用户的请求的,这些请求可以识别他们的阅读习惯或者感兴趣的主题.自然这种信息明显是机要的并且在某些 国家对它的处理是受限制的.使用HTTP协议提供数据的人们有责任确保这样的材料不会在没有得到任何公开结果确认的人允许的情况下被散布出去. |
15.1.1 Abuse of Server Log InformationA server is in the position to save personal data about a user's requests which might identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling can be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results. |
15.1.2敏感信息的传输就像任何种类的数据传输协议一样,HTTP不能控制被传输数据的内容,也没有任何一种区分的方法来决定在任何给定请求的上下文中某个特别的信息片段的敏感 性.因此,应用程序应该(SHOULD)提供给发布信息的人尽可能多的对这个信息的控制能力.四个报头域是值得在这段文字中特别提到 的:Server,Via,Referer和From. 暴露服务器详细的软件版本信息可能会导致服务器因为已知有安全漏洞的软件而变得更易受到攻击.开发人员应该(SHOULD)使Server报头域是一个可 配置的选项. 作为通过一个网络防火墙的入口的代理服务器应该(SHOULD)对关于确认防火墙后面的主机的报头信息的传输采取特别的防范.特别的,它们应当移走或者用 清洁的版本代替,Via域在放火墙后面产生. Referer报头允许学习的阅读模式并且可以进行反向连接.虽然它非常有用,但是如果用户的资料没有从Referer包括的信息中分离出来的话它的能力 就可能会被滥用.甚至当信息已经被移开,Referer报头还是可能指示出一个不适于公开的私人文档的URI. 在From域发送的信息可能和用户的个人利益或者他们站点的安全政策相抵触,因此用户如果不能使之失效,对其授权,和修改域的内容的话,它就不应该 (SHOULD NOT)被传输.用户必须(MUST)能够按用户的选择或者应用程序的缺省配置设置这个域的内容. 虽然并不是必须的,我们建议向用户提供一个可以选择允许或者禁止From和Referer信息的发送的方便捆绑界面. 用户代理(14.43节)或者服务器(14.38节)的报头域有时候会被用来判断某个特定的客户机或者服务器有一个可以被利用的特别的安全漏洞.不幸的是 同样的信息经常被用作其它有价值的目的因为HTTP现在没有更好的机制. |
15.1.2 Transfer of Sensitive InformationLike any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications SHOULD supply as much control over this information as possible to the provider of that information. Four header fields are worth special mention in this context: Server, Via, Referer and From. Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementors SHOULD make the Server header field a configurable option. Proxies which serve as a portal through a network firewall SHOULD take special precautions regarding the transfer of header information that identifies the hosts behind the firewall. In particular, they SHOULD remove, or replace with sanitized versions, any Via fields generated behind the firewall. The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate. The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it SHOULD NOT be transmitted without the user being able to disable, enable, and modify the contents of the field. The user MUST be able to set the contents of this field within a user preference or application defaults configuration. We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information. The User-Agent (section 14.43) or Server (section 14.38) header fields can sometimes be used to determine that a specific client or server have a particular security hole which might be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has no better mechanism. |
15.1.3 URI中敏感信息的编码因为一个连接的源地址可能是机要的信息或者可能会暴露另外一个机要的信息源,所以强烈推荐用户能够选择是否发送Referer域.例如,一个浏览器的用户 能够有一个捆绑的选择是公开/匿名浏览,这将会分别允许/禁止Referer和From信息的发送. 如果目标页使用安全的协议传输的话,在一个(不安全)HTTP请求中客户机不应该(SHOULD NOT)包括一个Referer报头域. 使用HTTP协议的服务提供者不应该(SHOULD NOT)使用基于使敏感数据屈服的形式的GET命令,因为这将导致在Request-URI中编码这个数据.许多现有的服务器,代理服务器,和用户代理将 把请求URI日志记录在某个第三方可以看见的地方.服务器可以用基于屈服形式的POST代替. |
15.1.3 Encoding Sensitive Information in URI'sBecause the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information. Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. Authors of services which use the HTTP protocol SHOULD NOT use GET based forms for the submission of sensitive data, because this will cause this data to be encoded in the Request-URI. Many existing servers, proxies, and user agents will log the request URI in some place where it might be visible to third parties. Servers can use POST-based form submission instead |
15.1.4连接到Accept报头的机要问题接受request-header可能暴露关于用户可以进入的所有服务器的信息.特别的Accept-language报头可能暴露用户个人的民族,因为 对特殊语言的理解对特殊的同文化的民族的成员经常有很强的相关性.提供在每个请求中配置发送的Accept-language报头的选项的用户代理被坚定 的鼓励让配置过程包括让用户明白有关机要泄露的信息. 对于用户代理来说一种限制机要泄露的方法是在缺省的情况下忽略发送Accept-language包头,并且如果通过寻找任何由服务器发出的变化的 response-header域,发现这样的发送能够提高服务的质量,就询问用户是否向服务器发送Accept-language报头. 在每个request中发送的为用户精心制作的accept报头域,特别如果这些包括质量价值,能够被服务器用作相关地可信赖的和长久的用户标识符.这样 的用户标识符将会允许内容提供者进行单击轨迹跟踪以及允许合作的内容提供者匹配交叉服务器单击轨迹或者形成单个用户的屈从.注意对于许多并不在代理服务器 后面的用户,运行用户代理的主机的网络地址也将作为长久用户的标识符.在代理服务器被用作增强保密的环境里,用户代理在提供给终端用户accept报头配 置选项上应该是保守的.作为一个保密的极端措施,代理服务器应该在转发请求信息的时候过滤accept报头.提供高度报头配置能力的一般用途的用户代理应 该(SHOULD)警告用户可能涉及的机要泄漏. |
15.1.4 Privacy Issues Connected to Accept HeadersAccept request-headers can reveal information about the user to all servers which are accessed. The Accept-Language header in particular can reveal information the user would consider to be of a private nature, because the understanding of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer the option to configure the contents of an Accept-Language header to be sent in every request are strongly encouraged to let the configuration process include a message which makes the user aware of the loss of privacy involved. An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language headers by default, and to ask the user whether or not to start sending Accept-Language headers to a server if it detects, by looking for any Vary response-header fields generated by the server, that such sending could improve the quality of service. Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be used by servers as relatively reliable and long-lived user identifiers. Such user identifiers would allow content providers to do click-trail tracking, and would allow collaborating content providers to match cross-server click-trails or form submissions of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could filter the accept headers in relayed requests. General purpose user agents which provide a high degree of header configurability SHOULD warn users about the loss of privacy which can be involved. |
15.2 基于文件和路径名称的攻击实现HTTP的原服务器应该(SHOULD)小心地限制由HTTP请求返回的文档仅仅是那些服务器管理员授权设置的.如果HTTP服务器直接把HTTP URIs翻译成文件的系统名称,服务器必须(MUST)特别注意不要提供没有授权发布给HTTP客户的文件.例如UNIX,微软Windows,和其它操 作系统使用".."作为指示当前目录的上一层的路径的一部分.在这样一个系统中,如果不允许通过HTTP服务器访问那些除授权允许访问以外的资源的 话,HTTP服务器就必须(MUST)禁止在Request-URI中任何这样的结构.同样的,必须(MUST)保护认为仅仅涉及服务器内部的文件(例如 访问控制文件,配置文件,和剧本代码)不要被不适当的获取,因为它们可能包含敏感信息.经验表明在HTTP服务器这样的使用中次要的bug已经转变为威胁 安全的风险. |
15.2 Attacks Based On File and Path NamesImplementations of HTTP origin servers SHOULD be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. If an HTTP server translates HTTP URIs directly into file system calls, the server MUST take special care not to serve files that were not intended to be delivered to HTTP clients. For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an HTTP server MUST disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) MUST be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor bugs in such HTTP server implementations have turned into security risks. |
15.3 DNS欺骗客户使用HTTP严重依赖于域名服务,因此一般倾向基于故意不相关的IP地址和DNS名称的安全攻击.客户需要在假定一个IP号/DNS名称关联继续合法 时谨慎. 特别的,HTTP客户对于一个IP号/DNS名称关联的确认应该(SHOULD)依靠对它们名字的解析,而不是存在高速缓存中以前主机名解析查找的结果. 在适当的时候并且他们应该(SHOULD)被设置成这样做的时候,许多论坛已经能够在本地用高速缓存存储主机名.只有当域名服务器报告的TTL(现在时 刻)信息使高速缓存里的信息很可能仍然是有用的时候,对这些高速缓存的查询才是适当的. 如果HTTP客户为了达到提高性能的目的把查询到的主机名结果存在高速缓存中,他们必须(MUST)遵守域名服务器报告的TTL信息. 如果HTTP客户不遵守这个规则,在一个以前访问过的服务器的IP地址改变的时候他们就会被欺骗.在网络重新编号被认为变得日益普遍的时候,这种形式的攻 击的可能性将会增大.遵守这个必要条件将会因此减少这种潜在的安全隐患. 这个必要条件也改进了客户机对使用同样域名的镜像服务器的平衡加载行为并且减少了用户访问使用这种策略的站点经历失败的可能性. |
15.3 DNS SpoofingClients using HTTP rely heavily on the Domain Name Service, and are thus generally prone to security attacks based on the deliberate mis-association of IP addresses and DNS names. Clients need to be cautious in assuming the continuing validity of an IP number/DNS name association. In particular, HTTP clients SHOULD rely on their name resolver for confirmation of an IP number/DNS name association, rather than caching the result of previous host name lookups. Many platforms already can cache host name lookups locally when appropriate, and they SHOULD be configured to do so. It is proper for these lookups to be cached, however, only when the TTL (Time To Live) information reported by the name server makes it likely that the cached information will remain useful. If HTTP clients cache the results of host name lookups in order to achieve a performance improvement, they MUST observe the TTL information reported by DNS. If HTTP clients do not observe this rule, they could be spoofed when a previously-accessed server's IP address changes. As network renumbering is expected to become increasingly common [24], the possibility of this form of attack will grow. Observing this requirement thus reduces this potential security vulnerability. This requirement also improves the load-balancing behavior of clients for replicated servers using the same DNS name and reduces the likelihood of a user's experiencing failure in accessing sites which use that strategy. |
15.4 Location(位置)报头和欺骗 如果单个的服务器支持互不信任的多个组织,那么它必须(MUST)检查在自称的某个组织控制下产生的应答信息中Location和Content- Location报头的值以确认他们没有企图使他们没有权限的资源无效. |
15.4 Location Headers and SpoofingIf a single server supports multiple organizations that do not trust one another, then it MUST check the values of Location and Content- Location headers in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority. |
15.5 内容倾向问题(Content-Disposition Issues)RFC 1806 [35],在HTTP中经常使用的Content-Disposition(见19.5.1节)报头就源于此,有许多非常认真的安全考虑. Content-Disposition并不是HTTP标准版本中的一部分,但自从它被广泛应用以来,我们正在证明它对使用者的价值和风险.详细资料见 RFC 2183 [49](对RFC 1806的升级). |
15.5 Content-Disposition IssuesRFC 1806 [35], from which the often implemented Content-Disposition (see section 19.5.1) header in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementors. See RFC 2183 [49] (which updates RFC 1806) for details. |
15.6 鉴定证书和空闲的客户机现有的HTTP客户机和用户代理有代表性地不确定地保留鉴定信息.HTTP/1.1没有提供一个从服务器到直接的客户机的方法来丢弃这些保存在高速缓存里 的证书.这是一个重大的需要对HTTP做进一步扩展的的缺点.在高速缓存里的证书可能干扰应用程序的安全模式的情况包括但不只限于: --客户机已经空闲了很长时间,然后服务器可能希望引起客户机再一次出示用户的证书. --应用程序包括了一个进程中断的指令(例如在一页上有"logout"或者"commit"的按钮),在此之后应用程序的服务器方面"知道"客户机没有 进一步的理由保留证书. 这是当前分散考虑的情况下.这个问题的各部分有许多的工作区,我们鼓励在屏保程序中使用密码保护,空闲暂停,以及其它在这个问题中减轻固有安全问题的方 法.特别的,在高速缓存中保存证书的用户代理被鼓励提供一个在用户控制下丢弃保存在高速缓存中的证书的可以容易访问的机制. |
15.6 Authentication Credentials and Idle ClientsExisting HTTP clients and user agents typically retain authentication information indefinitely. HTTP/1.1. does not provide a method for a server to direct clients to discard these cached credentials. This is a significant defect that requires further extensions to HTTP. Circumstances under which credential caching can interfere with the application's security model include but are not limited to: - Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt the user for credentials. - Applications which include a session termination indication (such as a `logout' or `commit' button on a page) after which the server side of the application `knows' that there is no further reason for the client to retain the credentials. This is currently under separate study. There are a number of work- arounds to parts of this problem, and we encourage the use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control. |
15.7 代理服务器和高速缓存HTTP代理是中间人,并且扮演一个"中间者"攻击的目标.代理运行系统的妥协可能导致严重的安全和保密问题.代理有权访问与安全相关的信息,关于个人用 户和组织的私人信息,属于用户和内容提供者的所有权信息.一个不安全的代理,或者一个使用或配置没有注意安全和保密考虑 的代理,可能被用作广泛的潜在攻击的代理. 代理服务器的管理员应当保护代理服务器上运行的系统就像他们保护包括或者传递敏感信息的任何系统一样.特别的,在代理上聚集的日志信息经常包括高度敏感的 个人信息,和/或者关于组织的信息.日志信息应该被小心地保护,并且对发展的和接下来的使用持适当的指导方针.(15.1.1节) 高速缓存代理给其它潜在的攻击提供了机会,因为高速缓存的内容对于恶意利用是一个有吸引力的目标.因为当一个HTTP请求完成以后高速缓存的内容仍然存 在,对高速缓存的攻击能揭示很早以前用户就认为已经从网络上移走的信息.因此,高速缓存的内容应该当作敏感信息保护. 代理服务器的设计者应当考虑他们的设计和编码的制定,以及他们提供给代理服务器操作人员的配置选项(尤其是缺省配置)所牵涉到的保密和安全问题. 代理服务器的用户必须明白他们并不比管理代理服务器的人更值得信任;HTTP自己不能解决这个问题. 在适当的时候明智的使用密码系统可以提供足够的保护免遭广泛的针对安全和保密的攻击.这种密码系统超出了HTTP/1.1规范的范围. |
15.7 Proxies and CachingBy their very nature, HTTP proxies are men-in-the-middle, and represent an opportunity for man-in-the-middle attacks. Compromise of the systems on which the proxies run can result in serious security and privacy problems. Proxies have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised proxy, or a proxy implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks. Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information, and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use developed and followed. (Section 15.1.1). Caching proxies provide additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected as sensitive information. Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to proxy operators (especially the default configuration). Users of a proxy need to be aware that they are no trustworthier than the people who run the proxy; HTTP itself cannot solve this problem. The judicious use of cryptography, when appropriate, may suffice to protect against a broad range of security and privacy attacks. Such cryptography is beyond the scope of the HTTP/1.1 specification. |
15.7.1 对代理服务器的拒绝服务攻击它们是存在的.它们很难防御.研究在继续.当心. |
15.7.1 Denial of Service Attacks on ProxiesThey exist. They are hard to defend against. Research continues. Beware. |
Written on 2009/01/17 by Bill Lue
HTTP超文本传输协议-HTTP/1.1[15.安全考虑]
Filed Under:
HTTP超文本传输协议-HTTP/1.1
0 Comments
Written on by Bill Lue
HTTP超文本传输协议-HTTP/1.1[14.报头域定义]
Filed Under:
HTTP超文本传输协议-HTTP/1.1
0 Comments
| 14 报头域定义 本节定义了所有HTTP/1.1种标准头域的语法和语义.对于实体头域,发送者和接收者指的是客户端和服务器,它是由实体的发送和接收者来定义的. 14.1接受(Accept) 接受请求报头区域可以同作详细说明特定对于响应来说可以接受的媒体形式.接 受报头可以同作说明,请求对于一小组需要的形式来说是受限的,就像在为了内 嵌图像的请求的情况下一样. Accept = "Accept" ":" #( media-range [ accept-params ] ) media-range = ( "*/*" | ( type "/" "*" ) | ( type "/" subtype ) ) *( ";" parameter ) accept-params = ";" "q" "=" qvalue *( accept-extension ) accept-extension = ";" token [ "=" ( token | quoted-string ) ] 星号字符用作将媒体形式聚集成为一个范围."*/*"指出了所有的媒体形式,"type/ *"指出了某种形式的图表类形.媒体范围可能包含适用于那个范围的媒体形式参数. 每个媒体范围可能跟随着一个或者多个接受-参数.开始为字母"q"的参数指出相关 质量的因素.任何一个开头字母为"q"将媒体范围参量和接受参量区分开来.质量要 因素允许用户或者是用户代理使用从零到一的值来指出对于此媒体形式来说喜欢 的相关程度,缺省时q的值是1. 注释:q参数名字可以用来将媒体形式从接受扩展参量中分辨出来,这是由于以前的 练习.虽然这保护了任何任何首字母为q的参量被煤体范围一起使用,这样的事件被 认为不太可能在LANA注册中被给与缺少的"q"参量或者在Accept中任何媒体形式的 珍稀用法.未来的媒体形式从注册和"q"参量中气馁了. 例子: Accept: audio/*; q=0.2, audio/basic 该例应该被解释作"我喜欢audio/basic,但是如果在质量中€标记向下之后是最佳 可利用的话,就给我发送任何音频形式.如果当前没有接受报头区域,那么可以认为 是客户接受了所有的媒体形式.如果当前有 Copyright www.cnpaf.net (2007). All Rights Reserved. 接受报头区域并且如果服务器不能发送 根据组合接受区域的值可以接受的响应的话,那么服务器应该发送一个406响应. 一个精心挑选的例子 Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c 口头上的,这个可以被解释作"text/html和text/x-c是首选的媒体形式,但是如果他 们并不存在,那么给他们发送text/x-dvi实体,如果它不存在,则发送text/plain实 体." 媒体范围可以不被更多特定媒体范围或者特定媒体形式考虑.如果多余一个的媒体 范围适用于一个给出的形式的话,那么最最特定的参考优先.比如"Accept: text /*, text/html, text/html;level=1, */*"就有以下的优先: 1) text/html;leve=1 2) text/html 3) text/* 4) */* 和一个给出的形式相关联的媒体形式质量要素就是由寻找有和形式相匹配的的最 最优先的媒体形式来决定的,比如: Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5 会使以下的值有关联 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 注释:一个用户代理可能会被提供一套默认的针对于特定媒体范围的值.然而,除非 用户代理是个关闭的系统并且不可以和其他翻译代理相互作用,这套缺省可以由用 户自己来配置. 14.2 接受-字符集(Accept-Charset) 接受-字符集请求报头区域可以用来指出什么特性装置可以为响应所接受.这个区域允许有能力理解更复杂或者是特定目的特性的装置的客户通知给在那些特性装置中有能力描述文档的服务器服务器是否具有上述所述的能力. Accept-Charset = "Accept-Charset" ":" 1#( ( charset | "*" )[ ";" "q" "=" qvalue ] ) 特性装置的值在3.4章节中描述.每一个??可以分配一个表示用户对??喜爱程度的相关联质量的值.缺升值是q=1.一个例子是: Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 特殊的值"*",如果在接受-??区域显示的话,则可以与每一个并没有在接受??中其他 什么地方提起的特性装置相匹配.如果没有'*'在当前接受-??区域,那么所有没有明 确提出的特性装置都回得到一个为零的质量值,除去在相同情况下可以得到1的 iso-8859-1.如果没有接受-??报头在当前,那么缺省设置就是任何特性装置都是可 接受的.如果当前存在接受-??报头并且服务器不能发送根据接受-??报头可以接受 的响应的话,那么服务器就会发送一个错误响应和406状态代码,在不可接受响应在 发送过程中时也是允许的, 14.3 接收编码(Accept-Encoding) 接收编码(Accept-Encoding)请求报头域和接收(Accept)相似,但限定响应中可接收的内容码(content-codings) (3.5节). 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 根据接收编码(Accept-Encoding)域测试内容码(content-coding)是否可接受的服务器采用这些规则: 如果内容码(content-coding)是接收编码(Accept-Encoding)域中列出的一系列内容码(content-codings)中 的一种,则它是可接受的,除非它跟着 a qvalue of 0.(定义在3.9节, a qvalue of 0.意思是不可接受的) 接收编码(Accept-Encoding)域中的特殊符号”*”匹配任何报头域中没有明确列出的可利用的内容码(content-coding). 如果多种内容码(content-codings)是可接受的,则具有最高非零qvalue的内容码(content-codings)是优先的. "identity" 内容码(content-codings)总是可接受的,除非特定的说明其是不可接受的,因为接收编码(Accept-Encoding)域包 括"identity;q=0"或者因为域中包括"*;q=0"和不明确的包括"identity"内容编码.如果接收编码域的值为空,则只 有"identity"编码是可接收的. 如果接收编码域出现在请求中,且根据接收编码报头服务器不能发送可接收的响应,则服务器应当发送带有406(Not Acceptable)状态码的出错响应. 如果请求中没有接收编码域,服务器可以假定客户机将接收任意的内容编码.在这种情况下,如果"identity"是可利用的内容编码之一,则服务器应该采 用"identity"内容编码,除非有额外的信息说明别的内容编码对客户机更有用. 注意:如果请求中没有包括接收编码域,且"identity"内容码是不可利用的,则能被HTTP/1.0客户机解读(i.e."gzip" and "compress")的内容码一般是优先的.当发送别的内容码是,一些老的客户机显示不正确的信息.服务器也许会以关于用户代理或客户机的信息为基础做 出决定. 注意:大多数HTTP/1.0应用程序不承认或遵守域内容码相关的qvalues.这意味着qvalues将不工作或被x-gzip or x-compress允许. 14.4 认可术语 The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Language tags are defined in section 3.10. 认可术语请求报头区与认可是相近的,但规定了一套自然语言用来响应请求.术语 标识在3.10节说明. Accept-Language = "Accept-Language" ":" 1#( language-range [ ";" "q" "=" qvalue ] ) language-range = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" ) 每个语言范围均被赋以一个品质因数,它代表用户用这种语言的钟爱程度.品质因 数默认值为一.例如: 认可语言: da, en-gb;q=0.8, en;q=0.7 表示:我喜欢丹麦语,但也接受不列颠英语和其它种英语.一种语言范围对应一 种术语标识如果它正好等于标识,或者如果它正好等于标识的前缀,例如第一个跟 在前缀后面的标识符是'-'.特殊范围"*",如果在认可术语区中出现,对应所有标 识符. 说明:使用前缀匹配规则并不表示如果用户理解一戴又标识的术语,他就也理解 所有代前缀标识的术语. 认可术语区指定给语言标识的语言品质因数是匹配标识的最大语言范围 的品质数值.如果在此区内没有语言范围匹配此标识,则品质因数制定为0.如果 请求中没有认可术语报头,服务器应假设所有语言被等同接受.如够出现了认可 术语报头,则所有品质因数大于0的语言均是可接受的. 在每个请求中发送认可术语报头说明可接受语言与保护用户隐私识背道而 驰的,对此问题的专门讨论见15.1.4 鉴于可理解性高度依赖于个别用户,推荐客户应用用户理解的语言.如果 选择用户不理解的,则请求中不能加入认可术语报头区. 说明:当选择用户可接受语言时,我们提醒实现者如下事实,用户并不熟悉术语匹 配的细节,所以应给出适当提示. 14.5接收范围(Accept-Range) 接收范围(Accept-Range)响应报头域允许服务器给出对资源请求的接收范围: Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges acceptable-ranges = 1#range-unit | "none" 接收byte-range请求的源服务器可以发送 Accept-Ranges: bytes 但没必要那样做.客户机可以产生byte-range请求,即使是它没有收到相关的报头域. Range units定义在3.12节. 不接收任何种类对资源的范围(range)请求的服务器可以发送 Accept-Ranges: none 来建议客户机不要尝试范围(range)请求. 14.6 年龄(Age) Age响应报头域表示发送者对传输时间的估计,既然响应是由源服务器产生的.假如缓存的响应没有超过它的寿命,则认为它是有活力的 (fresh).13.2.3节说明了Age值的计算. Age = "Age" ":" age-value age-value = delta-seconds Age值是十进制非负整数,以秒为单位. 如果高速缓存存储器收到一个大于它所能表示的上限整数的值,或它的Age计算溢出,它必须传送值为2147483648 (2^31)的Age报头域. 带有高速缓存存储器的HTTP/1.1服务器产生的每一个响应(从它本身的高速缓存存储器中)都必须包括Age报头域. 高速缓存存储器应当采用至少31位的算法. 14.7 允许(Allow) 允许 (Allow)实体报头域中列出了由 Copyright www.cnpaf.net (2007). All Rights Reserved. 请求指定资源支持的几种方法--URI.这一报头域的目的严格限于通知接收者与资源相联系的方法有哪些.允许报头域必须出现在405(方法不被允许)应答 中. 允许="允许"":" #方法 使用示例: 允许: GET, HEAD, PUT 这一报头域不能阻止用户使用其他方法.然而允许域给出的指示应予以执行.由原服务器在处理每一请求时定义允许的方法集. 允许域可由PUT请求提供,以建议新资源支持某些方法.服务器不必一定支持这些方法,且应在允许域中给出实际支持的方法. 因为用户有其他与原服务器通信的渠道,故代理服务器即便不理解域中指明的所有方法,也不得修改允许报头域 14.8 授权(Authorization) 用户代理往往希望服务器自我验证,但在收到401响应后则没有必要了.用户代理通过包括Authorization请求报头域的请求那样做. Authorization请求报头域的值 由包含用户代理验证信息的信任状所组成,这些用户代理处于请求资源的领域. Authorization = "Authorization" ":" credentials HTTP Authentication中描述了HTTP访问的身份鉴定: Basic and Digest Access Authentication" [43].假如请求在特定的领域中通过了验证,则同样的信任状对该领域内所有其它请求都是有效的(假定验证方案本身不需要,否则信任状依照亟待解决的问题 或用同步时钟而不同) 当共享的高速缓冲存储器(看13.7节)接收具有验证(Authorization)域的请求时,必须返回相应的响应作为其他请求的应答,除非是接下来的 特殊情况之一. 如果响应包括s-maxage缓存控制指示信息,高速缓存可以用响应来应答并发的请求.但(如果已超过了特定的最大生存期)代理服务器的高速缓存首先必须 重新生效,用来自新请求的请求报头允许源服务器验证新的请求.(这是为s-maxage定义的行为.)假如响应包括"s-maxage=0",代理服务器 必须在重新利用之前使之生效. 如果响应包括must-revalidate缓存控制指示信息,高速缓存可用响应来应答并发请求.但如果响应失去时效,所有缓存首先必须使它重新生效河源 服务器一致,用来自新请求的请求报头允许源服务器验证新的请求. 假如响应包括public缓存控制指示信息,它可以被返回来应答并发请求. 14.9 缓存-控制(Cache-control) 缓存-控制通用-报头域用于标明请求/应答链上所有缓存机制必须遵守的指令.这些指令规定了一些意在预防缓存对请求或应答造成不良影响的行为.它们通常覆 盖了缺省的缓存算法. 缓存指令是单方向的,因为请求中指令的存在并不意味着应答中也会有同样的指令. 请注意HTTP/1.0缓存机可能并不实现缓存-控制,而是只实现 Pragma:无-缓存(参见14.31节). 代理服务器或网关的应用程序必须不顾缓存指令对其本身的意义,毫无例外的让它们通过,因为这些指令可能对请求/应答链上的所有接收者都适用. 缓存-控制="缓存-控制"":" 1#缓存-指令 缓存-指令="缓存-请求-指令|缓存-应答-指令 缓存-请求-指令= "无-缓存" ; 14.9.1节 | "无-存储" ; 14.9.2节 | "最大-时限""=" delta-秒 ; 14.9.3, 14.9.4节 | "最大-陈旧" ["="delta-秒] ; 14.9.3节 | "最小-保鲜"["="] delta-秒 ; 14.9.3节 | "不传输" ; 14.9.5节 | "仅当缓存时" ; 14.9.4节 | 缓存-扩展 ; 14.9.6节 缓存-应答-指令= "公共" ; 14.9.1节 |" 私有"["="<"" 1#域名〈"〉]; 14.9.1节 |"无缓存" ["="<"" 1#域名〈"〉]; 14.9.1节 |"不存储" 14.9.2节 |"不传输" 14.9.5节 |"必须经重新确定有效" 14.9.4节 |"代理服务器重新确定有效" 14.9.4节 |"最大时限""="delta-秒 14.9.3节 |"s-最大时限""="delta-秒 14.9.3节 |缓存-扩展 14.9.6节 当指令不伴有1#域名参数出现时,该指令适用于整个请求或应答. 当指令伴有1#域名参数出现时,它仅适用于被命名的域,而不适于请求或应答的其他部分.这一机制支持可扩展性;HTTP协议将来的版本可以通过将指令应用 于HTTP/1.1中未定义的域来实现. 缓存-控制指令 可分为如下几类: -- 对可缓存的范围的限制;这可能只由原服务器指定. -- 对缓存内容的限制;这可由原服务器或用户代理指定. -- 对基本过期无效机制的改进;这可由原服务器或用户代理指定. -- 对缓存重新确认有效及重载的控制;这可能仅由用户代理指定. -- 对实体传输的控制 -- 缓存系统的扩展. 14.9.1 何谓可缓存的 缺省情况下,若请求方法,请求报头域和应答状态指明了应答为可缓存的,则它就是可以缓存的. 13.4节总结了这些可缓存性的缺省情况. 下列缓存-控制应答指令允许原服务器覆盖缺省的应答的可缓存性: 公共 指明应答可被任意高速缓存机缓存,即便在该应答通常是不可缓存的或只可由不共享的高速缓存机缓存的情况下也是如此.(参见14.8节,关于认证的附加详 述) 私有 表明应答报文的所有部分都是为单一用户准备的且不得被共享缓存机缓存. 这使原服务器可以申明应答的特定部分是针对单一用户的,对其他用户的请求而言并非有效应答. 私有(不共享)缓存可以缓存应答. 注:私有一词仅用来控制应答在何处可被缓存, 而不能保证报文内容的私有性. 不缓存 若指令"不缓存"没有指定域名,则缓存机不得应答那些未经原服务器重新确认有效的后继的请求. 这使得原服务器即便对设置为回送陈旧应答给客户请求的高速缓存机也能防止缓存. 若指令"不缓存"确实指定了一个或多个域名,则高速缓存机可以在其他的缓存要求限制下应答后继请求. 然而,指定的域名不得在用于应答那些未经原服务器重新确认有效的后继请求.这使得原服务器防止了应答中某些报头域重复使用,同时又允许缓存应答的剩余部 分. 注:大多数HTTP/1.0高速缓存机不会认出或遵守这一指令. 14.9.2 哪些可被高速缓存机保存 不保存 "不保存"指令的目的在于防止无意中泄露或滞留了敏感信息(比如存在备用磁带上了). "不保存"指令适用于整个报文,可在请求或 Copyright www.cnpaf.net (2007). All Rights Reserved. 应答中发送.若由请求方发送,则高速缓存机不得保存该请求或其应答的任何部分.若由应答方发送,高速缓存机不得保存该应答和相应请求的任何部分.该指令对 非共享与共享高速缓存机都适用. "不得保存"在这里意味着缓存机不得有意地将信息保存在非易逝存储器上,且必须尽最大努力将信息在转发后尽快从易逝存储器上转移. 即使这一指令是与应答相联系的,用户也可能明言要在缓存系统之外保存该应答(比如通过"另存为"对话框). 历史缓存区可作为例行公事保存这些应答. 这一指令地目的在于满足某些在意信息经未知渠道偶然泄漏到缓存数据区的用户与服务程序作者提出的要求.虽然这一指令的使用可能改善了保密性,但值得提醒的 是,它又绝非保证保密性的充分的或可靠的机制. 14.9.3 对基本过期失效机制的改进 实体的过期时间可由原服务器的"过期"报头(参见14.21节)指定.或者,它也可由应答中的"最大-年龄"指令说明.当被缓存的应答含有"最大-年龄" 缓存-控制指令时,应答若现有年龄大于出现对同一资源的新请求中所给年龄值(以秒为单位)则被视为陈旧.应答中的"最大-年龄"指令意味着该应答是可缓存 的(如,"公共"),除非存在其他更严格的缓存指令. 若应答同时含有过期报头与"最大-年龄"指令,最大-年龄指令覆盖过期报头,即便过期报头中的描述更严格也不例外.这一规则使原服务器可就给定应答为 HTTP/1.1(或更新的版本)缓存机提供比HTTP/1.0缓存机更长的过期时间.这在某一HTTP/1.0缓存机出于诸如类似同步时钟的原因错算了 年龄或过期时间的情况下可能有用. 许多HTTP/1.0缓存机会按照与缓存-控制应答指令"不缓存"等价的方式来处理小于或等于应答日期值的过期值.若HTTP/1.1缓存机接到这种应 答,且应答不含缓存-控制报头域,则它应视应答为不可缓存,从而保持与HTTP/1.0服务器的兼容性. 注:在兼有不懂新特性的旧版缓存机的网络上,一台原服务器可能愿意采用较新的HTTP缓存控制功能,如"私有"指令.这样,原服务器就需要将新特性与其值 小于等于日期值的过期报头域结合起来.这将防止旧版缓存机误缓存应答. s-最大年龄 若应答包含s-最大年龄指令,则对共享缓存机(而非私有缓存机)而言,由该指令指定的最大年龄覆盖其他最大年龄指令或过期报头的指定. S-最大年龄指令也暗示了代理服务器-重新确定有效指令的句法(参见14.9.4节),也就是说,在首先经原服务器重新确认为有效之前,共享缓存机不得用 那些变得陈旧了的目录来应答后继请求. 私有高速缓存机忽略此s-最大年龄指令. 请注意,大多数与此规范不相适的旧版缓存机并不执行任何缓存-控制指令. 想要使用缓存-控制指令来限制而非避免遵守HTTP/1.1的缓存机进行缓存得原服务器可以利用最大-年龄指令覆盖过期报头的条件以及早于HTTP /1.1的缓存机不检查最大-年龄指令这一事实. 其他指令允许用户代理修改基本过期失效机制. 这些指令可由请求指定: 最大-年龄 表明客户机愿接受其年龄不大于指定时间(以秒计算)的应答.除非也含"最大-陈旧"指令,否则客户机不愿接受陈旧应答. 最小-保鲜 表明客户机愿接受其保鲜寿命不小于现有年龄与指定时间之和(以秒计算)的应答.也就是说,客户机想要一至少在一定时间内保持保鲜的应答. 最大-陈旧 表明客户机愿接受已经过期的应答. 若指定最大-陈旧为某值,则客户机愿接受过期时间不超过给定秒数的应答.若未指定最大-陈旧的值,则客户机愿接受任意年龄的陈旧应答. 若缓存机或出于请求的最大-陈旧指令,或出于缓存机被设置为覆盖应答过期时间的原因,最终返回了一个陈旧的应答,缓存机都必须在旧应答上添加一警告报头, 采用警告110(应答是陈旧的). 高速缓存机可被设置成不经确认就返回陈旧应答,但这不应与任何"必须"等级的关于缓存重确认的要求(如"必须-重新确认有效"缓存-控制指令)冲突. 若新请求与缓存的条目均包括"最大-年龄"指令,则取两者间较小值来决定该请求的缓存条目的保鲜程度. 14.9.4 缓存重新确认有效和重载控制 有时用户代理可能希望或出于需要坚持让 Copyright www.cnpaf.net (2007). All Rights Reserved. 缓存机与原服务器之间重新确认缓存条目的有效性(而不只是通向原服务器的传输路径中的下一高速缓存机),或是从原服务器处重载缓存条目.端到端的重新确认 有效手续在缓存机或原服务器高估了缓存应答的过期时间时可能需要.端到端重载在缓存条目由于某些原因被侵蚀时可能需要. 如果客户机没有自己的本地缓存拷贝,即所谓"未指明的端到端重新确认有效",或客户机没有本地的缓存拷贝,即所谓"经指明的端到端重新确认有效", 都有可能要求端到端的重新确认有效. 客户机可用缓存-控制请求指令来指明三种行动中的一种: 端到端重载 请求包括"不缓存"缓存-控制指令,或是与HTTP/1.0客户机兼容的"Pragma:不缓存". 请求的"不缓存"指令中不得含有域名.服务器应答这种请求时不得使用缓存的拷贝. 经指明的端到端重新确认有效 请求包括"最大-年龄=0"缓存-控制指令,从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性.初始请求 包括由客户机现有的确认模块决定的缓存有效性确认过程. 未指明的端到端重新确认有效 请求包括"最大-年龄=0"缓存-控制指令,从而迫使通向原服务器路径上的每一高速缓存机都与下一缓存机或服务器之间重新确认自身条目的有效性.初始请求 中不包括缓存条件有效性确认过程.沿途第一个含有此资源缓存条目缓存机(如果存在的话)包括决定于现有的有效性确认模块的缓存-有效性确认. 最大-年龄 当中转缓存机被"最大-年龄=0"的指令迫使重新确认其缓存条目有效性,且客户机在请求中提供了自己的有效性确认器时,所供的有效性确认器可能不同于缓存 条目中现存的有效性确认模块.在这一情况下,缓存机可以在不影响句法透明性的前提下将其中的任一有效性确认模块用于自己的请求. 然而,对有效性确认器的选择可能影响性能. 最好的方法是让中转缓存机采用自己的有效性确认模块来构造请求.若服务器应答以304(未经修改),则缓存机可以将自己的确认后拷 Copyright www.cnpaf.net (2007). All Rights Reserved. 贝连同200(OK)应答一起发回给客户机.但若服务器发回新的实体和有效性确认器,则中转缓存机可使用强比较函数比较返回的有效性确认器与客户机请求中 提供的有效性确认器.若客户机的有效性确认器与原服务器的一致,则中转缓存机仅需发送回304(未经修改).否则,它就发回新的实体和200(OK)应 答. 若请求含有"不缓存"指令,则它不得包括最小-保鲜,最大-陈旧或最大-年龄指令. 仅当经缓存时 在某些情况下,如网络连接极为糟糕时,客户机可能想要缓存机只返回它现存的应答,而不要与原服务器之间进行重载或重新确认有效性.为实现这一点,客户机可 以在请求中包括"仅当经缓存时"指令.若它收到这一指令,缓存机应该应答以符合请求其他限制的缓存条目,或是应答以504(网关超时)状态.然而,当一组 缓存机是作为呢部内部联系良好的同一系统来操作的话,这样的请求可能会在那组缓存机内部转发. 必须-重新确认有效性 由于缓存机可能被设置为忽略服务器指定的过期时间,且客户机请求可能包括最大-陈旧指令(与前者效用相似),协议还包括了一种由原服务器要求后继使用中重 新确认缓存条目有效性的机制. 当缓存机接到的应答中有必须-重新确认有效性指令时,该缓存机不得在条目变得陈旧后不经与原服务器重新确认有效性就用来应答后继请求.(也就是说,若仅由 原服务器的"过期"报头或"最大-年龄"取值确定缓存的应答已陈旧,缓存机就每次都必须执行端到端有效性重新确认.) "必须重新确认有效性"指令对支持某些协议特性可靠运作是必要的.在所有情况下,HTTP/1.1缓存机必须遵守"必须重新确认有效性"指令;特别是,若 缓存机出于任何原因无法到达原服务器,则它必须产生504(网关超时)应答. 当且仅当对实体的请求的有效性重确认的失败会导致错误的操作(比如未申明但未被执行的最终事务)时,服务器应该发送"必须重新确认有效性"指令. 接收者不得采取任何违背该指令的自动行动,也不得在重确认失败时自动提供未经确认的实体拷贝. 虽不提倡如此,但受到严格的连接限制的用户代理还是可以违背这一指令,但在这么做的同时必须明确警告用户提供的是未经有效性确认的应答.每一未确认的访问 都必须伴有警告,且应要求明确的用户许可. 代理服务器-重新确认有效性 除了不适于非共享用户代理缓存机之外, "代理服务器-重新确认有效性"指令与"必须重新确认有效性"指令含义相同.它可用于对经认证的请求的应答,以允许用户的缓存机保存应答,并在稍后无须重 新确认就返回应答(因为它已经被该用户认证了),同时仍然要求服务于多个用户的代理每次都重新确认有效性(从而确保每一用户都通过认证). 请注意这种经认证的应答还需要"公共"缓存-控制指令,使得它们可以被缓存. 14.9.5 不得转换指令 不得转换 中转缓存机(代理服务器)的实现者们发现转换某些实体正文的媒体类型是很有用的. 比如,一台非透明的代理服务器可以在图象格式之间进行转换,以节省缓存空间或减少慢速链路上的数据通信量. 然而,当这些转换应用于某些应用的实体正文时,会引发严重的操作方面的问题.比如,医学图象应用,科学数据分析和端到端认证都依赖于接收到与原实体正文一 比特都不差的实体正文. 所以,如果报文包括了"不得转换"指令, 中转缓存机或代理服务器就不得改变13.5.2节中列出的受"不得转换"指令影响的报头.这意味着缓存机或代理服务器不得改变由这些报头定义的实体正文的 任何方面,包括实体正文值本身. 14.9.6 缓存控制扩展 缓存-控制报头域可通过一个或多个缓存-扩展标志的使用来实现扩展.其中每一标志都赋予一可选的值. 信息性的扩展(那些无须改变缓存机行为的)可以不经改变其他指令的句法而添加. 行为性扩展被设计为现有基本缓存指令的修正. 新指令与标准指令都有提供,于是不理解新指令的应用程序会缺省地按采用标准指令规定的行为,而理解新指令的应用程序则将其认作标准指令提出的要求的修正. 这样,缓存-控制指令可以无须改变基本协议就得到扩展. 这一扩展机制依赖于HTTP缓存机对所有初始HTTP版本中缓存-控制指令和某些扩展方式的遵守,以及对所有它不理解的指令的忽略. 例如,考虑一个假想中的名为"共同体"的新应答指令,作为"私有"这里指令的修正.我们定义这个新的指令以表明除了非共享缓存机之外,任何只可被同一共同 体成员共享的缓存机都可以缓存此应答.原服务器若想允许UCI共同体在它们的共享缓存机之间使用本来是私有的应答,只需在该应答中添入: 缓存-控制:私有, 共同体="UCI" 见到这一报头域的缓存机即便不理解"共同体"缓存-扩展也能正确操作,因为它还见到并理解"私有"指令,就会按缺省的安全方式行事. 未经认出的缓存-指令必须被忽略;按照假定,任何可能未被HTTP/1.1高速缓存机认出的缓存-指令都与标准指令(或应答的缺省可缓存性)相结合使用, 从而是缓存机的行为即便在它不理解扩展指令时也尽可能保持正确. 14.10 连接 连接这一概括报头域允许发送者指定某一特定连接中的选项设置,且不得由代理服务器在以后的连接中传送. 连接报头遵循如下语法: 连接="连接"":" 1#(连接-标志) 连接-标志=标志 HTTP/1.1代理服务器必须在转发报文之前即解析连接报头域,针对域中每一连接-标志,从报文中移开所有与连接-标志同名的报头域. 连接选项是由连接报头域中的连接-标志指明的,而非任何附加的报头域,因为这些附加报头在缺少与连接选项相关的参数时无法被传送. 连接报头中列出的报文报头不得含有诸如缓存-控制之类的端到端报头. HTTP/1.1定义了"close"选项,以供发送者宣布连接在完成应答后将被关闭.例如 连接:close 无论是出现在请求或应答的报头域中,都表明连接不应被视为在完成现有请求/应答后是"持续的"(参见8.1节). 不支持持续连接的HTTP/1.1应用程序必须在每一报文中都添上"close"连接选项. 接收到含有连接报头的HTTP/1.0(或更低版本)报文的系统必须为每一连接-标志都去除或忽略报文中与之同名的报头域.这样做避免了早于HTTP /1.1版本的代理服务器误转发这些报头域. 14.11 内容编码 "内容编码"实体报头域是作为媒体类型的修正.此域存在时,其值表明对实体正文采用了何种附加的内容编码,从而须采用何种解码机制以获取"内容类型"报头 域中指出的媒体类型."内容编码"的主要目的是使文件可以在不丧失其基本媒体类型身份的同时被压缩. 内容编码="内容编码" ":" 1#内容译码 内容译码由3.5节定义.其应用示例为: 内容编码:gzip 内容译码是由请求定义(URI)的实体特性.通常,实体正文以编码方式存储,只在翻译或类似使用前才解码.然而,非透明代理服务器在确知新译码可被接受者 认可的情况下可能会改变内容译码,除非报文中含有"不得转换"的缓存控制谓词. 若实体的内容译码不具备同一性,则应答必须包含列有所用非同一内容译码的内容编码实体报头(14.11节). 若请求报文中的实体内容编码对原服务器而言不可接受,则服务器应以415(不被支持的媒体类型)状态码应答. 若实体采用多种编码,则内容译码应按它们的使用顺序列出. 关于编码参数的其他信息和由未被此说明定义的实体报头域给出. 14.12 内容语言 内容语言实体报头域描述了实体面向的受众的使用语言.请注意,这不一定等同于实体正文中用到的所有语言. 实体语言="实体语言"":"1#语言标记 语言标记由3.10节定义.内容语言的主要目的在于让用户根据自己喜用的语言确认并区别众实体.由是,若正文内容只是针对懂荷兰语的人的话,相应的域应 为: 内容语言:da 若未指明内容语言,缺省值为内容针对所有语种的受众.这既可能指发送者认为内容与任意自然语言无关,也可能指发送者不知此内容应面向何种语言. 要面向多种听众,可列出多种语言.例如,同时用毛里土语和英语发行的"Waitangi之约"就可以用: 内容语言:mi,en 然而,实体中有多个语种并不代表它一定是为多语种的观众准备的.比如"初学拉丁文"之类的语言启蒙教程,显然是针对英语观众的.这里,恰当的"内容语言" 应只包括"en". 内容语言可用于任意媒体类型 -- 它不限于文本式文件. 14.13 内容长度 内容长度实体报头域按十进制或八位字节数指明了发给接收者的实体正文的大小,或是在使用HEAD方法的情况下,指明若请求为GET时将发送实体正文的大 小. 内容长度="内容长度"":"1*DIGIT 示例: 内容长度:3495 除非按4.4节的规则被禁用,应用程序应使用此域指明报文正文的传输长度. 任何不小于零的内容长度均为有效值. 4.4节描述了如何在未知内容长度时测定报文长度的方法. 请注意此域的含义域MIME中的相应定义迥异.MIME中,它是"报文/扩展正文"内容类型的可选域;在HTTP中,除非按4.4节的规则被禁用,一旦报 文长度在传送前被确定,就应发送此域. 14.14 内容位置 内容位置可用来在从一独立于请求资源的URI的位置访问实体时提供报文中实体的资源位置.服务器应根据应答实体为此变量提供一内容位置;尤其是在资源和多 个实体相联系,而这些实体各享独立位置,可被分别访问时,服务器应为特定的返回变量提供内容位置. 内容位置="内容位置"":"(绝对URI|相对URI) 内容位置的值也决定了实体的基础URI. 内容位置值并非原请求URI的替代;它只是申明了请求中对应特定实体的资源位置. 此后的请求若想确定特定实体的来源,可以指定内容位置URI为请求的URI. 缓冲存储机不能以为若实体的内容位置URI异于访问URI就可用此实体来应答那一内容位置URI下的后续请求.但如13.6节所述,内容位置可用于区分从 同一请求资源得到的多个实体. 若内容位置是相对URI,则此相对URI是相对于请求URI来解释的. PUT或POST请求中内容位置报头的含义未定;服务器可自由忽略. 14.15 内容-MD5 如RFC 1864[23]中所定义的,内容-MD5实体报头域是实体正文的MD5摘要,以期提供端到端的实体正文的报文完整性检验(MIC).(注:MIC有利于 检测实体正文传送中的偶发改动,但不一定能防范恶意袭击.) 内容-MD5="内容-MD5"":" MD5-摘要 MD5-摘要=< 由RFC 1864 定义的的 基64的128比特MD5摘要> 内容-MD5报头域可由原服务器或客户机生成,用作实体正文的完整性检验.只有原服务器或客户机可生成内容-MD5报头域;不得由代理服务器和网关生成, 否则会有悖于其作为端到端完整性检验的价值.任何实体正文的接收者,包括代理服务器和网关,都可检查此域中摘要值与实体正文是否相符. MD5摘要的计算基于实体正文的内容,包括任何所用的内容译码,但不包括任何对报文正文进行的传输编码.若接到的报文有传输编码,则必须在核对内容 -MD5与所收正文之前解除编码. 这样造成的后果是:摘要完全按照它们若未经传输编码而被发出的顺序进行逐字节计算. HTTP 将RFC 1864拓宽到允许对MIME组成的媒体类型(如multipart/*,message/rfc822)计算摘要,但这并不改变如前所述的摘要计算方 法. 由此产生了一系列影响.组件类型的实体正文可能会包括多个正文部分,每一部分都有自己的MIME和HTTP报头(包括内容-MD5,内容-传输-编码,和 内容编码报头).如果正文部分有内容-传输-编码或内容编码报头,则被假定为正文部分的内容已经过编码处理,且正文部分依样包括在内容-MD5摘要中. 正文部分不得含有传输编码报头域. 不可在摘要计算或核对之前就将任何断线转换为CRLF:实际传输的文本中使用的断线转换协定必须原封不动的参与摘要计算. 注:虽然HTTP的内容-MD5定义和RFC 1864中关于MIME实体正文的完全一样, 但HTTP 实体正文在对内容-MD5的应用上仍然有几处与MIME实体正文有所区别.首先,HTTP不象MIME会用内容-传输编码,而是使用传输编码与内容编码. 其次,HTTP比MIME更多地使用二进制内容类型,故值得提出的是:在此种情况下,用于计算摘要的字节序也即由类型定义的传输字节顺序.最后,HTTP 允许文本类传输时采用数种断线协定,而不只是规范的使用CRLF的形式. 14.16 内容-范围 内容-范围实体报头与部分实体正文一起发送,用于指明在全部实体正文中,那一部分正文应该应用于何处. 范围的单位在3.12节中有定义. 内容-范围 = "内容-范围"":"内容-范围-说明 内容-范围-说明 = 字节-内容-范围-说明 字节-内容-范围-说明 =字节-单位 SP 字节-范围-方面-说明 "/" (实例-长度|"*") 字节-范围-方面-说明 =(首字节位置 "-" 末字节位置) |"*" 实例-长度 =1*DIGIT 除非无法或很难测定,报头应指明全部实体正文的总长度.星号"*"表示生成应答信息时实例长度未知. 与字节-范围-指定符的值(参见14.35.1节)不同的是,字节-范围-方面-说明仅可指明一个范围,且必须包含首末字节的绝对位置. 其字节-范围-方面-说明的末字节值小于首字节值或实例-长度值小于等于末字节值的字节-内容-范围-说明是无效的.收到无效的字节-内容-范围-说明值 时接收者必须忽略此值与随其传输的任何内容. 应答时发送状态码416(请求的范围无法满足)的服务器应在内容-范围域中填上字节-范围-方面-说明为"*".实例-长度项指明被选资源的现有长度.状 态码为206(部分内容)的应答不应将内容-范围域的字节-范围-方面-说明填为"*". 假定实体共含1234字节,字节-范围-方面-说明项的示范值为: 头500字节: 字节0-499/1234 次500字节: 字节500-999/1234 除头500 字节外的所有: 字节500-1233/1234 末500字节: 字节734-1233/1234 当HTTP报文包含单一范围的内容时,(比如,对单一范围请求,或对一组互有覆盖但无遗漏的请求的应答)此内容在传输时内容-范围报头与内容-长度报头会 显示实际传输的字节数.例如: HTTP/1.1 206 部分内容 日期: 星期三, 1995年11月15日 06:25:24 (格林威治时间) 上次修改时间:星期三, 1995年11月15日 04:58:08 (格林威治时间) 内容-范围:字节21010-47021/47022 内容-长度: 26012 内容-类型:image/gif 当HTTP报文包含多个范围时(比如,对多个未重叠范围请求的应答),它们会被当作多部分报文来传送. 用于此目的的多部分媒体类型如附录19.2节中所述定义为"multipart/byteranges". 其兼容性问题述于附录19.6.3中. 对单一范围请求的应答不得使用multipart/byteranges媒体类型.若对多范围请求的应答结果为单一范围,可以采用只有一个部分的 multipart/byteranges媒体类型发送.无法对multipart/byteranges报文解码的客户机不得在单一请求中申请多个字节 范围. 当客户机在单一请求中申请多个字节范围时,服务器应按请求中出现的顺序发回信息. 若服务器出于句法无效的原因忽略了字节-范围-说明,它应视无效的范围报头域不存在来处理请求.(正常情况下,这意味着发回含有全部实体的200应 答.) 如果服务器接到请求报头域中含无法满足的范围(也即,所有字节-范围-说明值的首字节值大于所选资源现有长度)的请求(含条件-范围请求报头域的除外), 则它应应答以代码416(请求的范围无法满足)(参见10.4.17节). 注: 客户机对无法满足范围的请求报头不能指望服务器一定发回416(请求的范围无法满足)而非200(OK)的应答,因为不是所有服务器都处理这一请求报头. 14.17 内容-类型 内容-类型实体报头域指明发给接收者的实体正文的媒体类型,或在HEAD方法中指明若请求为GET时将发送的媒体类型. 内容-类型="内容-类型"":"媒体类型 媒体类型有3.7节定义. 此域的示例如下: 内容-类型:text/html; charset(字符集)=ISO-8859-4 7.2.1节提供了关于确定实体媒体类型方法的进一步论述. 14.18 日期 日期头域描述消息产生的日期和时间,它和RFC822中的ORIG-DATE语义一样.域值是一个在3.3.1描述的HTTP日期;它必须用 RFC1123[8]数据格式发送. Date="Date"":"HTTP-date 举个例子 Date:Tue,15 Nov 1994 08:12:31GMT 原服务器在所有的应答中必须包括一个日期头域,除了这些特例: 1 如果应答的状态代码时100(继续)获101(选者协议),相应可以在服务的选项中包括日期头域. 2 如果应答状态代码传送服务器错误,如500(ｉｎｔｅrｎｅｔ服务器错误)获503(服务器不可达),它没有困难或不可能产生有效的日期. 3 如果服务器没有时钟,不能提供合理的当前时间的近似值,这个应答没必要包括日期头域,但在这种情况下必须遵照 14.18.1节中的规则. 一个收到的消息没有日期头域的话会被接收者加上一个,如果这条消息将被那个接收者或网关储存并进由一个需要日期的协议.一个没有时钟的http执行不能缓 存没有重新使之关于每一个使用有效的应答.一个http缓存,特别是一个共享的缓存,必须使用一种机制使它与外界可靠的时钟保持同步. 客户端秩序在包括实体的消息中发送日期头域,正如在PUT和POST请求的过程,甚至它是随意的.一个没有时钟的客户端不能在请求中发送日期头域. 一个日期头中的http-date没必要描述一个后续消息的产生的日期和时间.它必须描述消息产生的最有用的日期和实践的近似值.除非执行没有方法产生一 个恰当的相当精确的日期和时间.理论上说,日期必须是实体产生之前的那一刻,实际上,日期能是消息产生的任何时候的时间而不会影响其语义. 14.18.1 没有时钟的原服务器的运作 一些原服务器的执行可能没有可用的时钟.一个没有时钟的原服务器不能指定一个应答断开或维持修改的值除非这些值是和系统或用户可靠的时钟资源相关联的.它 可以指定一个知道的终止值,在服务配置的时间或以前,这是过去的(这允许应答的预终止而不保存每个资源分离的分割值). 14.19 ETag Etag应答报头域提供了请求变量的当前实体标签.与实体标签一起使用的报头由14.14,14.26,14.44节描述. 实体标签可用于比较来自同一资源的不同实体.(参见13.3.3节) Etag="ETag" "Etag"":" 实体-标签 例: ETag: "xyzzy" ETag: W/"xyzzy" ETag: "" 14.20 期望 期望请求报头域用于指明客户机需要特定的服务器行为. 期望="期望"":"1#期望值 期望值="100-继续"|期望值-扩展 期望值-扩展=标号["="(标号|引用-字符串) *期望-参数] 期望-参数=";"标号["="(标号|引用-字符串)] 对请求的期望域中期望值不理解或与其不相容的服务器必须应答以相应的出错状态. 如果所有期望都无法满足,服务器必须应答以417(期望失败)状态. 若请求有其他问题,则应应答以其他4xx状态. 本报头域依照可扩展语法定义,以满足将来扩展需要.若服务器接到的请求含有它不支持的期望-扩展,则它必须应答以417(期望失败)状态. 期望值的比较对于未经引用的标号(包括"100-继续"标号)是而言对个例敏感的,对引用字符串的期望-扩展而言是对个例不敏感的. 期望机制是逐站进行的:即HTTP/1.1代理服务器在无法满足请求期望时必须.回送417(期望失败)状态. 然而,期望请求报头本身却是端到端的;它必须随请求一起转发. 许多旧版的HTTP/1.0和HTTP/1.1应用程序不理解期望报头. 参见8.2.3节中100(继续)状态的使用. 14.21 过期(Expire) "过期"实体报头域给出了在何日何时之后应答即被视为陈旧.除非首先经原服务器(或含有此实体较新拷贝的中介代理服务器缓存)确认为有效,缓存一般不会返 回陈旧的缓存目录值. 请参见13.2节中对过期模型的深入论述. 其格式为由3.3.1节中HTTP-日期定义的绝对日期与时间; 它必须遵照RFC 1123的日期格式: 过期="过期"":" HTTP-日期 使用示例为: 过期: 星期四,1994年12月1日, 16:00:00 格林威治时间 注:若应答包含填有最大时限谓词(参见14.9.3节)的缓存-控制域,则谓词作用覆盖过期域. HTTP/1.1客户机和缓存必须把其它无效的,尤其是含有"0"值的日期格式按过去值(即"已经过期")处理. 要将应答标为"已经过期",原服务器须发送和日期报头值相等的过期日期值.(参见13.2.4节的过期计算规则) 为标记应答为"永不过期",原服务器须发送过期日期晚于发送应答的时间一年左右的过期日期.HTTP/1.1服务器不应发送超过将来一年的过期日期. 对于原本不可被缓存的应答而言,除非缓存控制域中另有指定,否则 过期报头域中填有将来的某一日期和时间值即是表明该应答允许缓存, 14.22 From From请求报头域,如果给定的话,应该(SHOULD)包括控制请求用户代理的人的互联网E-MAIL地址.这个地址应该(SHOULD)是适用于机器 的,就像在RFC 822 [9]里定义的“mailbox"以及在RFC 1123 [8]修订的: From = "From" ":" mailbox 例如: From: webmaster@w3.org 报头域可以(MAY)用作记录日志的目的和作为认证无效或者多余请求源的方法.他不应该(SHOULD NOT)用作不安全形式的访问保护.这个域的解释是请求正在为某个给定的人执行,它承担这个方法执行的责任.特别的,自动控制代理应该(SHOULD)包 括这个域这样一来如果接收端出现问题的话,对运行这个自动控制程序有责任的人能够得到联系. 这个域的互联网E-MAIL地址可以(MAY)从发出请求的互联网主机中分离出来.例如,当一个请求通过一个代理服务器是应该(SHOULD)使用原发出 者的地址. 客户机不应该(SHOULD)发出没有得到用户批准的From域,因为它可能和用户的个人利益或者他们站点的安全政策冲突.强烈建议用户在任何一次请求之 前能够取消,授权,和修改这个域的值. 14.23 主机(Host) 主机(Host)请求报头域说明了正在请求的资源的互联网主机和端口号,就包括在用户或者提交的资源指定的源URI中(一般是一个HTTP URL,就像在3.2.2部分描述的).Host域的值必须(MUST)代表源URL给定的源网关或者服务器的授权命名.这允许源服务器或网关区分内部不 明确的URL,例如单个IP地址上有多个主机域名的服务器的根“/”URL. Host = "Host" ":" host [ ":" port ] ; 3.2.2节 一个没有任何追踪端口信息的“主机”暗示使用请求服务的缺省端口(例如,“80”对应HTTP URL).例如,源服务器上对[http://www.w3.org/pub/WWW/]的请求将完全包括: GET /pub/WWW/ HTTP/1.1 Host: www.w3.org 在所有的HTTP/1.1请求信息中客户机必须(MUST)包括Host报头域.如果被请求的URI不包括被请求服务的互联网主机域名,那么Host报头 域必须(MUST)是空值. 一个HTTP/1.1的代理服务器必须(MUST)确保它向前传递的任何报文确实包括代理服务器可识别的请求服务的适当的Host报头域.所有基于互联网 的HTTP/1.1服务器必须(MUST)对任何缺少Host报头域的HTTP/1.1请求报文响应状态代码400(坏的请求). 见5.2和19.6.1.1节和主机关联的其他请求. 14.24 If-Match If-Match报头域是用一种方法使得它是有条件的.由以前从源获得的一个或更多实体的客户机能够校验那些实体中的一个现在包括在If-Match报头 域的一系列联合的实体标签.实体标签在3.11节定义.这种特征的目的是允许用对报头进行最少量处理的方法对高速缓存信息进行有效的修正.它也用来在更新 请求时防止源的错误版本无意识的修改.作为一种特殊情况,“*”匹配任何现有源的实体. If-Match = "If-Match" ":" ( "*" | 1#entity-tag ) 如果任何一个实体标签匹配在对类似GET请求的响应中返回的实体的实体标签,或者如果给出“*”以及对那个源任何现存的实体,那么服务器可以(MAY) 在执行请求的方法就好像If-Match报头域不存在一样. 服务器必须(MUST)用功能强大的比较函数来比较在If-Match中的实体标签. 如果没有一个实体标签匹配,或者给出了“*”而没有现有的实体,服务器一定不要(MUST NOT)执行请求的方法,并且返回412响应(预处理失败).当客户机希望防止更新的方法,例如PUT,修改自从客户机上一次找到以后已经改变的源的时 候,这种行为是很有用的. 如果请求将会导致除2XX或412以外的任何状态,没有If-Match报头域,那么If-Match报头必须(MUST)被忽略. "If-Match: *" 的含义是当源服务器(或高速缓存,很可能使用Vary机制,见14.44节)选择的表示法存在时,方法就应该被执行,并且当表示法不存在时,一定不要 (MUST NOT)执行. 想要更新源的请求(例如PUT)可以(MAY)包括If-Match报头域来发出信号如果相应于If-Match值的实体(单个实体标签)不再是源的表示 法请求方法应订不能(MUST NOT)得到应用.这允许用户表明如果源已经改变而他们不知道的话他们不希望请求成功. 例如: If-Match: "xyzzy" If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-Match: * 既有If-Match报头域又有If-None-Match或If-Modified-Since报头域的请求的结果本规范没有定义. 14.25 If-Modified-Since 用一种方法使If-Modified-Since请求报头域被用来使得如果请求的变量自从这个域说明的时间以来没有被修改过,实体将不会从服务器返回;相 反的,将返回304响应(没有修改的)而没有任何报文实体. If-Modified-Since = "If-Modified-Since" ":" HTTP-date 这个域的一个例子是: If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT 有If-Modified-Since报头没有Range报头的GET方法请求只有如果自从If-Modified-Since 报头给定的时间以来认证实体已经被修改过,它才会被传递.决定这个的运算法则包括以下的情况: a)如果请求通常将会导致除状态200之外的任何情况,或者如果传递的If-Modified-Since日期是无效的,响应和对正常的GET的响应完全 一样.比服务器现在的时间晚的日期是无效的. b)如果自从If-Modified-Since日期以来变量已经修改了,响应和对正常GET的完全一样. c)如果自从一个有效的If-Modified-Since日期以来变量没有修改过,服务器应该返回响应304(没修改). 这种特征的目的是允许用对头部最小量的处理来有效的更新高速缓存的信息. 注释:Range请求报头域修改了If-Modified-Since的含义;完整的详细信息见 14.35. 注释:If-Modified-Since的时间是由服务器说明的,它的时钟可能和客户机的不同步. 注释:当处理一个If-Modified-Since报头域的时候,一些服务器使用精确的比较函数而不是稍差的函数,来决定是否发送响应304(没修 改).当给高速缓存确认发送If-Modified-Since报头域时为了得到最好的结果,建议客户机只要可能就采用从先前Last-Modified 报头域收到的精确日期字符串. 注释:如果客户机在If-Modified-Since报头域中用任意的日期代替从Last-Modified报头得到的对同样请求的日期,客户机应该注 意到这个日期是由服务器对时间的理解来解释的事实.由于客户机和服务器之间时间编码的不同,客户机应该考虑时钟不同步和舍入的问题.这包括了如果在第一次 请求的时间和后来请求的If-Modified-Since日期之间文档已经改变而出现竞争的可能性,以及如果If-Modified-Since从客户 机得到的日期没有得到服务器时钟的修正而出现时钟倾斜有关问题的可能性.由于网络反应时间的原因客户机和服务器之间对不同时间基准的修正是最佳的近似. 既有If-Modified-Since报头域又有If-Match或If-Unmodified-Since报头域的请求的结果本规范没有定义. 14.26 “如果不匹配”(If-None-Match) If-None-Match报头区伴随一种使其条件化的算法使用.一个已从源端获得 实体的客户可以校验得出:这些实体没有通过在If-None-Match报头区标明相应实体 标签而流通.此特征的目的是达到最小代价的高效缓存信息刷新.它也可以防止一 些算法无意中修改客户认为不存在而实际存在的资源. 作为特殊情况,特征值“*”匹配资源的任何当前实体. If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag ) 如果任何实体标签与将被用来回复GET请求的实体匹配,或给出“*”且 针对该资源的实体存在,则服务器不能执行被请求的算法,除非由于资源的修改 数据不能匹配If-Modified-Since报头区提供的相应内容而被要求那样做. 与之相反,如果请求算法是GET或HEAD,服务器应回复304响应,包含有匹配实 体的缓存相关报头区.所有其它算法,服务器必须回复412状态码. 13.3节说明怎样判断两实体标签匹配.弱比较函数只能用于GET或HEAD请求. 如果没有实体标签匹配,则服务器将执行被请求的算法只当If-None-Match 报头区不存在,但必须同时也忽略请求中的If-Modified-Since报头区.即,如果没 有实体标签匹配则不能回复304响应. 如果没有If-None-Match报头区的请求最终回复非2xx及304响应,则 If-None-Match报头一定要被忽略.(见13.3.4) "If-None-Match: *"的意思是:当源服务器选择的代表(representation) 存在时算法不可用而当七其存在时可用 此特征在防止PUT操作的______时是有用 的. 例: If-None-Match: "xyzzy" If-None-Match: W/"xyzzy" If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz" If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz" If-None-Match: * 含有If-None-Match报头区及If-Match或者If-Unmodified-Since(此后不可 修改)报头区的请求结果在此说明中不做定义 14.27 If-Range 如果客户机在其缓存中有实体的部分拷贝,并希望向缓存中添入整个实体的更新后拷贝,它可以在条件 GET(If-Unmodified-Since 和If-Match两者兼用或只取其一)中使用范围请求报头域.然而,若由于实体已被修改而导致条件不满足,客户机就需要再次发出获取当前整个实体正文的 请求. If-Range允许客户机“拦截”第二次请求. 简要说来,其含义为“若实体未改变,请发送我缺少的部分给我;否则,发给我整个实体”. 若客户机不具备实体的实体标签,但有上次修改日期,它可以在If-Range报头中使用此日期(服务器通过检查一两个字符即可区分合法HTTP日期与任意 形式的实体标签).If-Range报头应只和范围报头一起使用,且在请求不含范围报头或服务器不支持亚范围操作时必须被忽略. 若If-Range报头中给出的实体标签于实体当前的实体标签相吻合,则服务器应使用206(部分内容)应答来指明实体的亚范围. 若实体标签不相符,服务器应使用200(OK)应答返回整个实体. 14.28 If-Unmodified-Since If-Unmodified-Since请求报头域用来使某方法变为条件的.若请求的资源在此域中指定的时间之后即未被修改,则服务器应按If- Unmodified-Since报头不存在的方式执行所请求的操作. 若请求的变量在给定时间之后已被修改,则服务器不得执行所请求的操作,且必须返回412(前提条件不满足)应答. If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-日期 此域的应用实例: If-Unmodified-Since: 星期六, 1994年10月29日 19:43:31 格林威治时间 如果正常情况下(即没有If-Unmodified-Since报头时),请求会得到除了2xx与412状态的结果,则If-Unmodified- Since报头应被忽略. 若指定的日期无效,本域亦被忽略. 本说明未定义一个既有If-Unmodified-Since报头,又有If-None-Match 或If-Modified-Since报头的请求的结果. 14.29 上次修改 上次修改实体报头域指明原服务器认为的变量上次被修改的日期和时间. 上次修改="上次修改"":"HTTP-日期 应用示例如下: 上次修改: 星期二, 1994年11月15日, 12:45:26 格林威治时间 此报头域的确切含义取决于原服务器的处理和原资源的性质. 对文件而言,它可能仅仅指示文件系统上次修改时间.对动态包含各个部分的实体而言,它可能指的是其组成部分的上次修改值中最近的一个. 对数据库网关而言,它可能就是记录的上次更新时间戳.对虚拟对象而言,它可能是上次内部状态改变的时间. 原服务器不得发送迟于服务器生成此报文时间的上次修改日期. 在这种情况下资源的上次修改意味着将来的某一时刻,服务器必须以报文生成日期取代之. 原服务器应尽量在靠近其生成应答日期值的时刻获取上次修改值. 这样接收者可以更准确的估计实体的修改时间,当实体在应答生成时间的前后有所改动时尤为如此. HTTP/1.1服务器应尽可能发送"上次修改"信息. 14.30 位置(Location) 除了应用于关于请求完成或新资源确认的请求,URI位置响应报头域还用于使收件人重发到某个地址.对 201(Created)响应,位置是请求建立的新资源.对3xx响应.Location应当指出服务器的关于资源自动重定向的首选URI.该域的值由单 个绝对的URI组成. Location = "Location" ":" absoluteURI 例如: Location: http://www.w3.org/pub/WWW/People.html 注: Content-Location报头域(14.14节)不同于Location, Content-Location定义了请求附属实体的源地址.因此响应有可能既有Location报头域,也有Content-Location报头 域.看13.10节一些方法的缓存需求. 14.31 最大前向(Max-Forwards) 最大前向请求头域提供一种带有TRACE(9.8节)和OPTION(9.2节)方法的机制以限制那些能够向下一个本地服务器转送请求的代理或网关.当客 户尝试跟踪一个似乎失败或在中间链循环的请求链时,这一点十分有用. Max-Forwards = "Max-Forwards" ":" 1*DIGIT 最大前向值是一个表示剩余的请求转送时间的十进制整数. 每个代理或网关接受包含最大前向头域的TRACE或OPTION请求时必须在转送请求前 Copyright www.cnpaf.net (2007). All Rights Reserved. 检查和修正它的值.如果接收到的值是zero(0),接收者一定不能转送这个请求;相反,它必须像最终接收者一样响应.如果接收到的最大前向值大于0,转 送的消息必须包含一个经过修正的最大前向域,其域值减一. 对本说明书定义的所有其它方法以及任何没有明确将它归作定义的一部分的扩展方法,最大前向头域可以被忽略. 14.32 实用(Pragma) 实用常规头域被用来包含特殊的执行指令,它可沿请求/接受链应用于任何接收端.从协议的观点所有的实用指示了详细的可选行为;不管怎样,一些系统可以被要 求那些行为与指示的相一致. Pragma ="pargma"":"1#pragma-directive Pragma-directive ="no-cache"|extension-pragma Extension-pragma =token["="(token|quoted-dtring)] 当一个非缓存的指示出现在请求的消息中,应用程序必须跟随这个原服务器的请求,甚至这是个正在被请求的缓存的复制.这个实用的指示的语义和非缓存指示 (14.9节)一致,他的定义是为了和http/1.0保持一致.当一个非缓存的请求被送到一个不知道是否支持http/1.1的服务器,客户端必须包括 两个头域. 使用指示必须被代理和网关应用程序过,不管对于那些应用程序有没有意义.因为这些指令可以被请求/应答链上的所有接受者应用.不可能为一个特殊的接收者定 义一个实用,然而,实用指示必须被不相关的接收者忽略. HTTP/1.1高速缓冲器必须把"Pragma:no_cache"当作客户端发送了"cache_control:no-cache".在http中 不会有新的指令定义. 注意:因为Pragma: no-cache的意思并没有作为应答的头域在十几种定义,他不提供可靠的应答中Cache-Control: no-cache的替代. 14.33 代理认证(Proxy-Authenticate) 代理认证的响应头域必须是407响应的一部分.这个域的值由表示认证方案的复杂问题和应用于这个请求URI的代理的参数组成. Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge HTTP访问认证进程如"HTTP认证:基本和分类访问认证"[43]所描述.与www认证不同,代理认证的头域仅仅应用于当前连接,不应该转到下游客 户.但是,中间代理可能需要向下游客户请求获得它自己的证书,有时候看起来这好像代理在转送代理认证头域. 14.34 代理授权 代理授权的请求头域允许客户将它自己(或的使用者)看作和需要认证的代理一样.代理授权的域值由包含用户代理对代理服务器的授权信息和正在被请求的资源界 组成. [译者注]realm:数据库中的一种逻辑子域,它包含了有约定的数据的聚集的全部(具体)值. Proxy-Authorization = "Proxy-Authorization" ":" credentials HTTP访问认证进程如"HTTP认证:基本和分类访问认证"[43]所描述.与授权不同,代理授权的头域仅仅应用于下一个需要认证的外地代理,用的是代 理认证域.当多个代理在链中使用时,代理授权的头域由第一个期待收到证书的外地代理消耗.代理可以从客户请求向下一个代理转发证书,如果那是代理协同认证 给定请求的机制. 14.35 范围 14.35.1 字节范围 既然所有的HTTP实体都以字节序列形式的HTTP消息表示,字节范围的概念对任何HTTP实体都是有意义的.(不过并不是所有的客户和服务器都需要支持 字节范围操作. HTTP里字节范围的详述应用于实体正文(不必和消息体一样)的字节序列. 一个字节范围操作可以确定字节的单一范围,或一个单一实体里的一组范围. 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 Byte-range-spec里的First-byte-pos值给出了一个范围里第一个字节的偏移量. last-byte-pos值给出了这个范围里最后一个字节的偏移量;也就是说,确定的字节位置包含在内.字节偏移量初始值为零. 如果存在last-byte-pos值,它一定大于或等于那个byte-range-spec里的 first-byte-pos,否则byte-range-spec在句法上是非法的.接收者收到包括一个或更多句法非法的byte-range- spec值的byte-range-set时必须忽略包括那个byte-range-set的头域. 如果last-byte-pos值不存在,或者大于或等于实体正文的当前长度,则认为 last-byte-pos等同于一个字节数少于实体正文当前长度的last-byte-pos. 通过选择last-byte-pos,客户能够限制检索字节的数量而不必知道实体的大小. suffix-byte-range-spec用来表示实体正文的后缀,其长度由后缀长度值给出.(也就是说,这种形式规定了实体正文的最后N个字节.) 如果实体短于确定的后缀长度,则使用整个实体正文. 如果一个句法正确的byte-range-set至少包括一个这样的byte-range-spec:它的 first-byte-pos比实体正文的当前长度小,或至少包括一个后缀长度非零的 suffix-byte-range-spec,那么byte-range-set是可以满足的.否则是不可满足的. 如果byte-range-set是不可满足的,服务器应该返回一个带有206状态(局部内容)的响应,其中包括实体正文的可满足范围. byte-ranges-specifier(字节-范围-说明符)值的例子(假定实体正文长度为10000): -- 第一个500字节(字节偏移量0-499,包括0和499): bytes=0-499 -- 第二个500字节(字节偏移量500-999,包括500和999): bytes=500-999 -- 最后500字节(字节偏移量9500-9999,包括9500和9999): bytes=-500 或 bytes=9500- -- 仅仅第一个和最后一个字节(字节0和9999): bytes=0-0,-1 -- 关于第二个500字节(字节偏移量500-999,包括500和999)的几种合法但不规范的叙述: bytes=500-600,601-999 bytes=500-700,601-999 14.35.2 范围检索请求 HTTP检索请求使用有条件或无条件GET方法,可以利用范围请求头来请求实体的一个或更多子范围而不是整个实体,范围请求头部应用于作为请求结果返回的 实体. Range = "Range" ":" ranges-specifier 服务器可以忽落范围头.但是,HTTP/1.1源服务器和中间高速缓存应该在可能的时候支持字节范围,既然范围支持部分失败传输的有效恢复,并且支持对大 实体的部分检索. 如果服务器支持范围头和确定的范围,或范围对实体是合适的: -- 如果GET是以别的方式成功的,无条件GET里范围头的存在修改返回的东西.换句话说,响应携带的是状态代码206(部分内容)而不是200(好). -- 如果GET以别的方式成功且条件为真,有条件GET(一种使用If-Modified-Since和If-None-Match二者之一或全部,或者 If-Unmodified-Since和If-Match二者之一或全部的请求)里范围头的存在修改返回的东西.它并不影响返回的304(未修改)响 应,如果条件为假. 某些情形下,使用Range header(范围头)辅以If-Range header(假设范围头)可能更合适. 如果支持范围的代理收到范围请求,将请求转发到本地服务器,以及收到回复的整个实体,它应该只把请求的范围返回给客户.它应该将接收到的整个响应存储在高 速缓存中,如果这跟它的高速缓存分配方针一致的话. 14.36 参考者(Referer) 参考者(Referer)请求头域允许客户确定获得请求URI的资源地址(URI)-为了服务器的利益.Referer请求头允许服务器生成关于到资源的 反向连接(back-link)的列表,为了兴趣,记录,优化的高速缓存等等.它也允许追踪过时的或错误类型的连接(link)以便维护.如果请求URI 是从一个没有自己的URI的源获得的,如从使用者键盘的输入,那么一定不要发送Referer域. Referer = "Referer" ":" ( absoluteURI | relativeURI ) 例如: Referer: http://www.w3.org/hypertext/DataSources/Overview.html 如果域值是相对URI,它应该理解为与请求URI相关.URI一定不能包括片断.安全考虑请参看15.1.3节. 14.37 稍后重试 稍后重试应答报头域可以和503(服务不可达)应答一起使用,以指示服务对于发出请求的客户机而言预计有多久不可达.本域也可与任何3xx(重新定向)应 答一起用于指示用户代理在重定向请求前被要求等待的最小时间.本域的值可以是应答时间只有的HTTP-日期或整值的秒数(十进制). 稍后重试=“稍后重试”“:”(HTTP-日期|delta-秒) 应用的例子有二: 稍后重试:星期五,1999年12月31 23:59:59 格林威治时间 稍后重试:120 在后一例中,延迟时间为2分钟. 14.38 服务器 服务器应答报头域包含了原服务器用于处理请求的软件信息. 此域可包含多个产品标记(3.8节),以及鉴别服务器与其他重要亚产品的注释.产品标记按它们对于鉴别应用程序的重要性的顺序排列. 服务器=“服务器”:“1*(产品|注释) 例: 服务器:CERN/3.0 libwww/2.17 若应答是通过代理服务器转发的,则代理程序不得修改服务器应答报头域.作为替代,它应添入路由(Via)报头(如14.45节定义). 注:揭示特定的软件版本可能会使服务器易于受到那些针对已知的软件安全漏洞的攻击. 建议服务器实现者将此域作为可设置项. 14.39 TE TE请求报头域指明了它愿意从应答中接收哪种扩展传输编码以及是否愿接收成块传输-代码中的trailer域.其值可由关键字“trailers”,由逗 号隔开的含可选接收参数的扩展传输-代码列表组成. TE = "TE" ":" #( t-codings ) t-codings = "trailers" | (传输-扩展 [接收-参数 ] ) 关键字“trailers”的存在表明客户机愿意接收如3.6.1节中定义的成块传输-代码中的trailer域. 此关键字为传输-代码值而保留,但它本身不代表一种传输-代码. 应用举例: TE: deflate TE: TE: trailers, deflate;q=0.5 TE报头域仅适用于立即连接.所以无论何时HTTP/1.1消息中有TE,连接报头域(参见14.10节)中就必须提供关键字. 服务器利用下述规则,依据TE域来裁定传输-代码是否可被接受: 如果关键字“trailers”在列,则成块传输-代码总被接受. 客户机已代表它自己与下游客户机指出愿接受成块应答中的trailer域.这意味着,可能的话,客户机正申明要么所有下游客户机都愿接收转发应答中的 trailer域,要么它将试图代表下游接收者暂存应答. 注:HTTP/1.1并未定义任何限制块状应答大小,以保证客户机能够暂存整个应答的方法, 若被检验的传输-代码在TE域中有列出,它就可被接受,除非伴有qvalue为0值(如3.9节定义, qvalue 的0值表示“不可接受”). 若多个传输-代码都是可接受的,则可接受传输-代码中qvalue值最高者优先. “成块”传输-代码的qvalue值总是1. 若TE报头域为空,或没有TE报头域,则仅有的传输-代码是“成块”. 无传输-代码的报文总是可接受的. 14.40 追踪者(Trailer) Trailer常规域值指示在trailer消息中有给定的头域设置,此消息用成块传输编码编码的. Trailer = "Trailer" ":" 1#field-name 一个http/1.1消息使用成块传输编码时要包括一个trailer头域,且其不能为空.这样才能让接收者知道trailer中期望得到哪个头域. 如果没有trailer头域存在,trailer不能包括任何头域.在成块传输编码中用到的trailer域的限制看3.6.1节. Trailer头域中列出的消息头域必须不能包括下面的头域: 传输编码 内容长度 Trailer 14.41 传输-编码 传输-编码常规头域指出为了在发送者和接收者之间安全的传输而应用了什么样类型的转换.它不同于内容代码,传输代码是消息而不是实体的属性. Transfer-Encoding = "Transfer-Encoding" ":" 1#transfer-coding 传输代码在3.6节中被定义了.一个例子是: Transfer-Encoding: chunked 如果一个实体应用了多种编码,传输代码必须顺序列出应用的编码.关于代码参数的额外信息有其他的实体头域指定.许多旧的http/1.0应用程序不懂传输 编码头. 14.42 升级(Upgrade) 升级头域允许客户端指定它支持什么样的附加传输协议并想使用如果服务器发现选择这种协议是恰当的话.服务器必须用101(选择协议)升级头域来指示要选择 那个协议. Upgrade = "Upgrade" ":" 1#product 举个例子: Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 升级头域被用来规定一种简单的机制从http/q.q过渡到其他不同性质的协议.它允许客户发出它期望使用另一个协议,比如说稍后的更高版本的http协 议,甚至当前的请求已经使用了 http/1.1协议.通过允许客户端发出一个用更普通的协议的请求来指示服务器它想用更好的协议(这儿得更好的由服务器决定,可能是按照方法的自然性或 被请求的资源)它减轻了两个不同性质的协议之间传输的困难. 升级头域只被用来从存在的传输层协议之上选择应用层协议.升级不能被用来强迫一个协议的改变;它的接受和使用是由服务器自由决定的.协议变换后应用层的通 讯的性能和本性是由新选择的协议决定的,虽然改变协议以后的第一个动作是包含升级头域的原来http请求的应答. 升级头域只应用于直接连接,因此无论升级出现在http/1.1消息的是什么时候,升级的关键字都必须应用于连接的头域中. 升级头域不能被用来指示选择不同连接中的协议.为这个目的,使用301,302,303重定位应答更合适. 这个规范着定义了http协议的名字,它被在3.1节的http版本规则中定义的超文本传输协议家族使用.任何一个记号都可被用来做协议名字,然而,只有 当客户端和服务器用同一个协议关联时才有用. 14.43 用户代理 用户代理请求头包括发出请求的用户代理的信息.这是为了统计学的目的,跟踪违反协议,为了因特定用户代理的限制制作对应响应而自动识别用户代理.用户代理 必须在请求中包括这个域.这个域包括多个指明代理和构成代理的重要组件的产品标记和元素.按惯例,这些产品标记按指明应用程序的重要性的顺序排列. User-Agent = "User-Agent" ":" 1*( product | comment ) 例子: User-Agent: CERN-LineMode/2.15 libwww/2.17b3 14.44 更正(Vary) 更正头域是在响应开始的时候变更完全接收的请求头域设置,而不管高速缓存是否允许用响应回复后续的请求.对于非高速缓存或者旧的响应,更正头域值建议用户 代理用来选择请求的标准. 一个为“*”的更正域意味着高速缓存不能根据后来的请求的请求头判断而不管这个请求是否是恰当请求.高速缓存对更正头域的用法间13.6节. Vary = "Vary" ":" ( "*" | 1#field-name ) 一个HTTP/1.1的服务器的任何能缓存的响应必须包括一个更正头域,这是服务器驱动商议的科目.这样做高速缓存呢能恰当的解释下一个关于那个资源的请 求同时通知用户代理需要对那个资源商议.一个服务器可以在非缓存的响应中包括更正头域,这是服务器驱动商议的科目,既然这可以提供用户代理在响应的时候响 应的变化的有用信息. 一个更正头域由一张头域的表组成,响应按一个选择的法则从其中选出,这个法则在选择最恰当的响应的时候只考虑列出的请求头域.一个高速缓存会假定下一个请 求的选择会和列出的头域的值一样. 此给定头域的名字不受这个说明书定义的标准请求头域的规范所限制.域名是对缓存不敏感的. 一个值为没有定义的“*”表明对请求头没有限制(例如,网络客户端的地址),作为选择响应表述的规则.“*”值一定不能由代理服务器产生;它只可以由源服 务器产生. 14.45 路由(Via) 路有常规头域必须被网关和代理服务起来指示中间的协议和关于请求的使用者和服务器之间的接收者及应答的原服务器和 客户端的接收者.它类似于RFC 822[9]的接收域,被用来跟踪消息的去向,避免请求循环,及识别沿请求/应答链个发送者协议的性能. Via = "Via" ":" 1#( received-protocol received-by [ comment ] ) received-protocol = [ protocol-name "/" ] protocol-version protocol-name = token protocol-version = token received-by = ( host [ ":" port ] ) | pseudonym pseudonym = token 接收协议指出沿请求/应答链的每一段后被服务器或客户端接收到的消息的版本.接收协议的版本被加到路由域值中,因此对于所有的接收者来说以前的所有应用程 序的协议能力的信息都保留了. 协议的名字是可以选择的,只要也只有它是HTTP.接收到的域一般是通常的主机和接收服务器或客户端的可选择的端口,然而,如果真实的主机考虑信息的敏感 性,它可能会用假名代替,如果没有指明端口,它被假设成接收协议的默认端口. 多重路由域值应答传递消息中的每一个代理或网关.每一个接收者必须添加上自己的信息,这样结果依照传递的应用程序的顺序范围. 路由头域可能会使用注释来识别接收的代理或网关的软件,用户代理和服务器头域也是如此.然而,所有的路由头域中的注释是可选的,它可以被任何接收的代理服 务器删掉. 举个例子,一个http/1.0的用户代理发送一个叫fred的请求消息给国内的代理,它使用http/1.1来传递请求给在nowhere.com的公 共代理,它把这个请求传递给在wwwlics.uci.edu的原服务器.这个请求被www.ics.uci.edu收到的时候应该有以下的路由头域: Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) 代理和网关被作为一个通过防火墙的入口,在默认情况下,它不能传递防火墙内的主机的名字和端口.这个信息只有在明确允许下才能传播.如果不允许的话,任何 在防火墙后面的主机将被用假名代替. 对于那些要求很强的隐藏内部结构的需求的机构,一个代理可以把有顺序的路由头域和同样的接收协议值组合在单个的条目中.举个例子: Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy 可能退化为 Via: 1.0 ricky, 1.1 mertz, 1.0 lucy 应用程序不能把多个实体组合在一起除非他们都在同一个组织的控制之下同时主机已经用假名代替了.应用程序不能把不同接收协议值的实体组合在一起. 14.46 警告(Warning) 警告常规头域被用来传递没有被回复的消息的状态或转变的信息.这个消息典型的应用是来警告一个消息实体正文的缓存操作或转换缺乏语义的透明性. 应答时警告头域按以下格式发送: 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 <"> 警告文本必须使用自然语言,对于接收应答的使用人来说它基本上时可理解的.这个决定可以基于任何可利用的知识,比如说缓存或使用者的位置,请求中的接收语 言域,应答中的内容语言域,等等.默认的语言是英语,默认的属性设置是ISO-8859-1. 如果属性设置不是使用ISO-8859-1,它必须按RFC 2047[14]中描述的在警告文本中指明. 警告头一般能被应用于任何的消息,然而一些特殊的警告代码对于高速缓存是特殊的,只能应用于应答消息.新的警告头必须加到任何存在的警告头的后面.一个高 速缓存一定不能删掉它接收到的消息的警告头域.然而,如果高速缓存成功的使高速缓存条目有效,它能把符合条目的警告头都删掉除了那些特殊的警告代码.它必 须马上把它接收到的警告头域加到确认应答中.用其他华说,警告头实那些能附加于最近大多数应答的应答. 当多个警告头附加于一个应答,用户代理必须按应答中显示的顺序尽可能多的通知使用者.如果不能通知所有警告的拥护,用户代理必须按这些 HEURISTICS运作: -出现在应答中前面的警告从那些出现在后面手中接过优先权 -符合用户首选性质设置的警告从其它使用相同的警告代码和警告代理但在其他性质设置的警告手中接过优先权. 产生多个警告头的系统必须按用户代理的行为排列它们. 对于注意警告的高速缓存的行为的要求在13.1.2节中规定. 这是通常定义的警告代码的列表,每一个有推荐的英语的警告文本和它意思的描述. 110 应答迟缓 当回复应答迟缓的时候应用 111 重新连接失败 当试图重新连接失败高速缓存返回一个迟缓应答,原因是服务器不可达. 112 分离操作 当高速缓存要有意从其它的网络中分离一段时间. 113 探索终止 高速缓存要选择保鲜的.生存期大于24小时,应答年龄大于24小时. 199 混合警告 警告文本可以包括只能给使用人看的信息.一个系统收到这样的警告必须给使用者看而不能自动处理. 214 转变被应用了 如果中间高速缓存或代理的任何应答的内容编码(如在内容编码头中指定的)或媒体类型(如在内容类型头指定的)或实体正文被改变了则这个警告必须被添加上 去,除非这个警告代码已经出现在应答中. 299 持久混合警告 警告文本可以包括只能给使用人看的信息.一个系统收到这样的警告一定不能自动处理. 如果一个实现用http/1.0或更低的版本发送了一个又一个或多个警告头的消息,发送者必须包括和应答中匹配的每一个警告值和警告数据. 如果一个实现收到一条报文,在这条报文中警告值包括一个警告数据,这个警告数据和行营中的数据值不同,那么这个警告值必须在储藏,传递或使用以前从这条消 息中删掉.这可防止错误储存警告头域)如果因为这个原因所有的警告制度被删掉了,则这个警告头也应该被删掉. 14.47 WWW-认证 401(未授权的)应答报文中必须含有WWW-认证应答报头域. 域值至少包括一个指明了可应用于请求-URI的认证方案与参数的挑战(challenge). WWW-认证=“WWW-认证”“:”1#挑战 HTTP访问认证过程在“HTTP认证:基本与摘要访问认证”[43]中有所描述. 建议用户代理尤其谨慎地解析WWW-认证域值,因为它可能含多个挑战,或在有多个WWW-认证报头域的情况下挑战内容本身即含有由逗号隔开的认证参数列 表. | 2
14 Header Field DefinitionsThis 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. 14.1 AcceptThe 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.
14.2 Accept-CharsetThe 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. 14.3 Accept-EncodingThe 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.
14.4 Accept-LanguageThe 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.
14.5 Accept-Ranges 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. 14.6 Age 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.
14.7 Allow 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.
14.8 Authorization 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" [43]. If a request is
authenticated and a realm specified, the same credentials SHOULD
be valid for all other requests within this realm (assuming that
the authentication scheme itself does not require otherwise, such
as credentials that vary according to a challenge value or using
synchronized clocks).
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.
14.9 Cache-ControlThe Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. Cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response. 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. 14.9.1 What is CacheableBy 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:
14.9.2 What May be Stored by Caches
14.9.3 Modifications of the Basic Expiration MechanismThe 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.
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:
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. 14.9.4 Cache Revalidation and Reload ControlsSometimes 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:
14.9.5 No-Transform Directive
14.9.6 Cache Control ExtensionsThe 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). 14.10 ConnectionThe 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 section 19.6.2. 14.11 Content-EncodingThe 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. 14.12 Content-LanguageThe 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 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. 14.13 Content-LengthThe 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. 14.14 Content-LocationThe 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. 14.15 Content-MD5The Content-MD5 entity-header field, as defined in RFC 1864 [23], is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. (Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.) Content-MD5 = "Content-MD5" ":" md5-digest
md5-digest = 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.
14.16 Content-RangeThe Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied. Range units are defined in section 3.12. 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.
14.17 Content-TypeThe 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. 14.18 DateThe 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 its semantic value. 14.18.1 Clockless Origin Server OperationSome 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). 14.19 ETagThe ETag response-header field provides the current value of the entity tag for the requested variant. The headers used with entity tags are described in sections 14.24, 14.26 and 14.44. The entity tag MAY be used for comparison with other entities from the same resource (see section 13.3.3). ETag = "ETag" ":" entity-tag Examples: ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""
14.20 ExpectThe 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. 14.21 ExpiresThe 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). 14.22 FromThe 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. 14.23 HostThe 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 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. 14.24 If-MatchThe 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. 14.25 If-Modified-SinceThe 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 subsequent request, and the
possibility of clock-skew-related problems if the If-Modified-
Since date is derived from the client's clock without correction
to the server's clock. Corrections for different time bases
between client and server are at best approximate due to network
latency.
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. 14.26 If-None-MatchThe 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 section 13.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. 14.27 If-RangeIf 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. 14.28 If-Unmodified-SinceThe 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. 14.29 Last-ModifiedThe 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. 14.30 LocationThe 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.
14.31 Max-ForwardsThe 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. 14.32 PragmaThe 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
14.33 Proxy-AuthenticateThe 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. 14.34 Proxy-AuthorizationThe 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. 14.35 Range14.35.1 Byte RangesSince 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
14.35.2 Range Retrieval RequestsHTTP 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. 14.36 RefererThe 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. 14.37 Retry-AfterThe 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. 14.38 ServerThe Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (section 3.8) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application. Server = "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.
14.39 TEThe 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. 14.40 TrailerThe 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 14.41 Transfer-EncodingThe 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. 14.42 UpgradeThe 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. 14.43 User-AgentThe 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 14.44 VaryThe 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. 14.45 ViaThe 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. 14.46 WarningThe 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. 14.47 WWW-AuthenticateThe 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. |
