HTTP协议 头信息(header field)详解
- 格式:doc
- 大小:241.00 KB
- 文档页数:35
HTTP响应头部HTTP(超文本传输协议)是用于在Web浏览器和Web服务器之间传输数据的协议。
在HTTP请求和响应过程中,头部是重要的组成部分之一,它包含了关于请求或响应的元数据信息。
本文将介绍HTTP响应头部的作用和常见的头部字段。
一、HTTP响应头部的作用HTTP响应头部是服务器在接收到客户端(浏览器)发送的请求后,向客户端返回的一部分响应数据。
它在传输过程中携带了一些元数据信息,用于指示服务器的处理结果、响应的内容类型、缓存控制等。
客户端接收到HTTP响应头部后,根据其中的信息进行相应的处理。
以下是HTTP响应头部的常见字段及其作用。
二、常见的HTTP响应头部字段1. Content-TypeContent-Type字段用于指定返回内容的类型。
它告诉客户端如何解析响应数据。
常见的值包括text/html(HTML文档)、text/css(CSS文件)、application/json(JSON数据)等。
2. Content-LengthContent-Length字段用于指定响应内容的字节数。
客户端可以根据该字段判断响应数据的大小,以便正确接收和处理。
3. ServerServer字段用于指定服务器软件的名称和版本号。
客户端可以根据该字段了解服务器的类型和版本信息。
4. Set-CookieSet-Cookie字段用于指定要在客户端保存的Cookie信息。
服务器通过设置Cookie,可以在客户端与服务器之间保持会话状态。
5. ExpiresExpires字段用于指定响应内容的过期时间。
客户端可以根据该字段来判断是否需要发送新的请求获取最新的内容。
6. LocationLocation字段用于指定重定向的URL。
当服务器需要将客户端重定向到另一个URL时,会在响应头部中设置该字段。
以上是一些常见的HTTP响应头部字段,它们在HTTP协议中被广泛应用于Web开发和网络通信过程中。
三、HTTP响应头部的重要性HTTP响应头部对于客户端和服务器之间的通信至关重要。
HTTP中header头部信息详解如下表:GET向Web服务器请求⼀个⽂件POST向Web服务器发送数据让Web服务器进⾏处理PUT向Web服务器发送数据并存储在Web服务器内部HEAD检查⼀个对象是否存在DELETE从Web服务器上删除⼀个⽂件CONNECT对通道提供⽀持TRACE跟踪到服务器的路径OPTIONS查询Web服务器的性能主要使⽤到“GET”和“POST”。
POST /test/tupian/cm HTTP/1.11. POST:HTTP请求⽅式2. /test/tupian/cm:请求Web服务器的⽬录地址(或者指令)3. HTTP/1.1: URI(Uniform Resource Identifier,统⼀资源标识符)及其版本在Ajax中,对应method属性设置。
说明:请求的web服务器域名地址说明:HTTP客户端运⾏的浏览器类型的详细信息。
通过该头部信息,web服务器可以判断到当前HTTP请求的客户端浏览器类别。
实例:User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-CN; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11说明:指定客户端能够接收的内容类型,内容类型中的先后次序表⽰客户端接收的先后次序。
Accept:text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5在Prototyp(1.5)的Ajax代码封装中,将Accept默认设置为“text/javascript, text/html, application/xml, text/xml, */*”。
这是因为Ajax默认获取服务器返回的Json数据模式。
在Ajax代码中,可以使⽤XMLHttpRequest 对象中setRequestHeader函数⽅法来动态设置这些Header信息。
http协议详解(超详细)1. 基础概念篇1.1 介绍HTTP是Hyper Text Transfer Protocol(超文本传输协议)的缩写。
它的发展是万维网协会(World Wide Web Consortium)和Internet工作小组IETF(Internet Engineering Task Force)合作的结果,(他们)最终发布了一系列的RFC,RFC 1945定义了HTTP/1.0版本。
其中最著名的就是RFC 2616。
RFC 2616定义了今天普遍使用的一个版本——HTTP 1. 1。
HTTP协议(HyperText Transfer Protocol,超文本传输协议)是用于从WWW服务器传输超文本到本地浏览器的传送协议。
它可以使浏览器更加高效,使网络传输减少。
它不仅保证计算机正确快速地传输超文本文档,还确定传输文档中的哪一部分,以及哪部分内容首先显示(如文本先于图形)等。
HTTP是一个应用层协议,由请求和响应构成,是一个标准的客户端服务器模型。
HTTP是一个无状态的协议。
1.2 在TCP/IP协议栈中的位置HTTP协议通常承载于TCP协议之上,有时也承载于TLS或SSL协议层之上,这个时候,就成了我们常说的HTTPS。
如下图所示:默认HTTP的端口号为80,HTTPS的端口号为443。
1.3 HTTP的请求响应模型HTTP协议永远都是客户端发起请求,服务器回送响应。
见下图:这样就限制了使用HTTP协议,无法实现在客户端没有发起请求的时候,服务器将消息推送给客户端。
HTTP协议是一个无状态的协议,同一个客户端的这次请求和上次请求是没有对应关系。
1.4 工作流程一次HTTP操作称为一个事务,其工作过程可分为四步:1)首先客户机与服务器需要建立连接。
只要单击某个超级链接,HTTP的工作开始。
2)建立连接后,客户机发送一个请求给服务器,请求方式的格式为:统一资源标识符(UR L)、协议版本号,后边是MIME信息包括请求修饰符、客户机信息和可能的内容。
HTTP协议简介关于HTTP协议的基本介绍。
HTTP协议是基于TCP/IP协议之上的应⽤层协议,主要⽤于规定互使⽤联⽹中客户端和服务器之间的通信格式,不关⼼具体传输细节,默认80端⼝。
对于Web开发,不管是前端还是后端开发,了解HTTP协议是必备的⼀些基本知识。
发展历程HTTP/0.9于1991年发布,只有⼀个GET命令,返回HTML格式内容。
HTTP/1.0于1996年5⽉发布,增加POST、HEAD命令,传输内容可以说任意格式,不再仅限于HTML,并且报⽂规定了⼀些元数据字段,⽐如字符集、状态码、编码、缓存等。
HTTP/1.1于1997年1⽉发布,增加PUT\PATCH\DELETE等命令,并新增了⼀些功能机制:持久连接(keep-alive可保持长连接,减少重复请求)。
管道机制(pipelining,⼀个TCP连接中客户端可同时发送多个请求)。
Content-Length字段(报⽂内容长度)。
Host字段(⽤于指定服务器域名,可以将请求发往同⼀台服务器的不同站点)。
1.1版本基本完善了HTTP协议,并且⼀直使⽤⾄今仍然是⽬前最流⾏的版本。
SPDY于2009年由⾕歌研发,使⽤多种新特性提⾼HTTP/1.1版本效率不⾼的问题。
作为HTTP/2版本草案,在HTTP/2发布后已停⽌使⽤。
HTTP/2于2015年发布,基于⾕歌的SPDY协议之上进⾏了⼩部分修改。
主要有以下特点:⼆进制协议(HTTP/1.1版本头信息使⽤⽂本格式,数据体可以是⽂本或⼆进制格式,⽽HTTP/2版本则全部使⽤⼆进制格式,⽅便将来扩展)。
多⼯传输(复⽤TCP连接,双向实时通信,客户端服务器可同时发送多个请求和响应,并且不需要按照请求顺序回应,避免队头阻塞问题)。
头信息压缩(HTTP协议是⽆状态的,因此很多请求都需要带上Cookie、User Agent等重复字段,影响效率。
HTTP/2使⽤gzip、compress等算法压缩头信息后,并且在客户端和服务器都维护⼀张头信息表,记录这些字段,从⽽提⾼速度)。
HTTP协议的头部HTTP⾸部字段有四种类型:通⽤⾸部字段,请求⾸部字段,响应⾸部字段,实体⾸部字段。
通⽤⾸部字段:⾸部字段说明Cache-Control控制缓存的⾏为Connection逐跳⾸部、连接的管理Date创建报⽂的⽇期时间Pragma报⽂指令Trailer报⽂末端的⾸部⼀览Transfer-Encoding指定报⽂主体的传输编码⽅式Upgrade升级为其他协议Via代理服务器的相关信息Warning错误通知请求⾸部字段:⾸部字段说明Accept⽤户代理的媒体类型Accept-Charset优先的字符集Accept-Encoding优先的内容编码Accept-Language优先的语⾔Authorization Web认证信息Expect期待服务器的特定⾏为From⽤户的电⼦邮件Host请求资源所在服务器if-Match⽐较实体标记(ETag)if-Modified-Since⽐较资源的更新时间if-None-Match⽐较实体标记(与if-Match相反)if-Range资源未更新时发送实体Byte的范围请求if-Unmodified-Since⽐较资源的更新时间(与if-Modified-Since想法)Max-Forwards最⼤传输逐跳Proxy-Authorization代理服务器要求客户端的认证信息Range实体的字节范围请求Refer对请求中URI的原始获取⽅TE传输编码的优先级User-Agent HTTP客户端的信息响应⾸部字段:⾸部字段说明Accept-Ranges是否接受字节范围请求Age推算资源创建经过时间⾸部字段说明ETag资源匹配信息Location令客户端重定向⾄指定URIProxy-Authenticate代理服务器对客户端的认证信息Retry-After对再次发起请求的时机要求Server HTTP服务器的安装信息Vary代理服务器缓存的管理信息WWW-Authenticate服务器对客户端的认证信息实体⾸部字段:⾸部字段说明Allow资源可⽀持的HTTP⽅法Content-Encoding实体主体适⽤的编码⽅式Content-Language实体主体的⾃然语⾔Content-Length实体主体的⼤⼩Content-Location替代对饮资源的URIContent-MD5实体主体的报⽂摘要Content-Range实体主体的位置范围Content-Type实体主体的媒体类型Expires实体主体过期的⽇期时间Last-Modified资源的最后修改⽇期时间HTTP⾸部字段将定义成缓存代理和⾮缓存代理两种类型:端到端(End-to-end Header):此类中的⾸部字段会转发给请求/响应对应的最终接受⽬标,且必须在由缓存⽣成的响应中,另外规定它必须被转发。
HTTP协议header标头详解本⽂根据RFC2616(HTTP/1.1规范),参考通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。
这两种类型的消息由⼀个起始⾏,⼀个或者多个头域,⼀个只是头域结束的空⾏和可选的消息体组成。
HTTP的头域包括通⽤头,请求头,响应头和实体头四个部分。
每个头域由⼀个域名,冒号(:)和域值三部分组成。
域名是⼤⼩写⽆关的,域值前可以添加任何数量的空格符,头域可以被扩展为多⾏,在每⾏开始处,使⽤⾄少⼀个空格或制表符。
通⽤头域 (通⽤⾸部)通⽤头域包含请求和响应消息都⽀持的头域,提供了与报⽂相关的最基本的信息,通⽤头域包含Connection 允许客户端和服务器指定与请求/响应连接有关的选项Date 提供⽇期和时间标志,说明报⽂是什么时间创建的MIME-Version 给出发送端使⽤的MIME版本Trailer 如果报⽂采⽤了分块传输编码(chunked transfer encoding) ⽅式,就可以⽤这个⾸部列出位于报⽂拖挂(trailer)部分的⾸部集合Transfer-Encoding 告知接收端为了保证报⽂的可靠传输,对报⽂采⽤了什么编码⽅式Upgrade 给出了发送端可能想要"升级"使⽤的新版本和协议Via 显⽰了报⽂经过的中间节点(代理,⽹嘎un)应答头说明Allow服务器⽀持哪些请求⽅法(如GET、POST等)。
Content-Encoding ⽂档的编码(Encode)⽅法。
只有在解码之后才可以得到Content-Type头指定的内容类型。
利⽤gzip压缩⽂档能够显著地减少HTML⽂档的下载时间。
Java的GZIPOutputStream可以很⽅便地进⾏gzip压缩,但只有Unix上的Netscape和Windows上的IE 4、IE 5才⽀持它。
因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader("Accept- Encoding"))检查浏览器是否⽀持gzip,为⽀持gzip的浏览器返回经gzip压缩的HTML页⾯,为其他浏览器返回普通页⾯。
HTTP协议解析-协议结构和HTTP头Web之http协议(三)一、http报文首部http协议中请求报文和响应报文都包括了http首部,这个首部是服务器和客户端处理请求和响应提供所需的信息,是客户端与服务器交互的基础。
http的请求报文由方法、URI、HTTP 版本、HTTP 首部字段等部分构成。
http的响应报文由HTTP 版本、状态码(数字和原因短语)、HTTP 首部字段3 部分构成。
在报文众多的字段当中,HTTP 首部字段包含的信息最为丰富。
首部字段同时存在于请求和响应报文内,并涵盖HTTP 报文相关的内容信息。
二、HTTP 首部字段http首部字段是http报文的构成因素之一,它是客户端与服务器端进行通信的标准。
客户端使用http首部说明需要的报文主体大小,所使用的语言,认证信息等。
服务器端则使用首部告诉客户端,返回的报文主体是什么东西,报文主体的大小等信息。
可以说首部字段是十分重要。
1.首部字段的结构首部字段的结构,通常的情况是由首部字段跟首部字段的值组成。
例如:Content-Type:text\html,也就是首部字段:首部字段值这样子的结构。
另外如果首部字段有多个值是则用都好隔开。
例如:Keep-Alive:timeout=15,max=100 2.首部字段的类型HTTP 首部字段根据实际用途被分为以下4 种类型。
通用首部字段(General Header Fields)请求报文和响应报文两方都会使用的首部。
请求首部字段(Request Header Fields)从客户端向服务器端发送请求报文时使用的首部。
补充了请求的附加内容、客户端信息、响应内容相关优先级等信息。
响应首部字段(Response Header Fields)从服务器端向客户端返回响应报文时使用的首部。
补充了响应的附加内容,也会要求客户端附加额外的内容信息。
实体首部字段(Entity Header Fields)针对请求报文和响应报文的实体部分使用的首部。
HTTP协议的头信息详解HTTP(超文本传输协议)是用于在客户端和服务器之间进行通信的协议。
在HTTP通信中,请求和响应由头信息(header)和主体(body)组成。
头信息提供了关于请求或响应的元数据,用于描述主体中包含的数据、通信的参数、状态等。
HTTP头信息由多个键值对组成,每个键值对表示一个元数据项。
以下是一些常见的HTTP头信息及其解释:1. Accept:指定客户端所能接受的响应内容类型,例如:"text/html"、"application/json"。
2. Content-Type:指定发送给服务器的主体数据的类型,例如:"application/json"。
3. Content-Length:指定发送给服务器的主体数据的长度,用于服务器正确读取数据。
4. User-Agent:指定客户端的相关信息,通常是浏览器或应用程序的名称和版本。
6. Host:指定服务器的域名或IP地址,用于多个虚拟主机共享同一个IP地址的情况。
7. Cookie:指定客户端发送给服务器的cookie信息,用于识别和跟踪会话状态。
8. Set-Cookie:指定服务器发送给客户端的cookie信息,让客户端保存在本地使用。
9. If-Modified-Since:指定客户端所要请求的资源的上次修改时间,用于条件请求。
10. Content-Encoding:指定主体数据的压缩类型,例如:"gzip"、"deflate"。
11. Cache-Control:指定请求或响应的缓存控制策略,例如:"no-cache"、"max-age=3600"。
12. Connection:指定客户端和服务器之间的连接类型,例如:"keep-alive"。
13. Authorization:指定客户端发送给服务器的认证信息,通常用于HTTP身份验证。
phpHTTP协议头解析HTTP(Hypertext Transfer Protocol,超文本传输协议)是一种用于传输超级媒体文档(例如HTML页面、图片或视频文件)的应用层协议。
它是构建互联网的基础之一,几乎所有的网页浏览都是基于HTTP 的。
HTTP协议是一种基于客户端-服务器架构的协议,客户端发送HTTP请求到服务器,服务器根据请求返回相应的资源。
HTTP请求和响应都包含一个协议头(HTTP Headers)部分,用来传递请求和响应的相关信息。
本文将重点探讨PHP中如何解析HTTP协议头的内容。
在PHP中,可以使用超全局变量$_SERVER来访问HTTP请求的相关信息。
$_SERVER是一个包含了诸如头信息、路径信息以及脚本位置等等的数组。
要获取HTTP协议头的内容,可以使用$_SERVER['HTTP_XXX']的形式,其中XXX是相应的协议头字段。
首先,我们可以通过$_SERVER['HTTP_USER_AGENT']获取客户端的User-Agent信息。
User-Agent是一个用于标识客户端的字符串,常见的有浏览器的名称和版本号。
通过解析User-Agent,我们可以判断用户使用的浏览器,以便根据不同的浏览器提供不同的网页布局和功能。
另外,通过$_SERVER['HTTP_REFERER']可以获取HTTP请求的来源页面。
Referer是一个HTTP头字段,用于指示请求的来源页面的URL。
这个信息对于网站的统计分析和追踪用户行为非常有用。
通过分析Referer,我们可以了解用户是从哪个页面链接过来的,从而统计流量来源并做出相应的决策。
除了上述常见的协议头字段外,还有一些其他的协议头字段也是非常重要的。
比如,$_SERVER['HTTP_HOST']可以获取主机名,$_SERVER['HTTP_ACCEPT_LANGUAGE']可以获取客户端接受的语言类型,$_SERVER['HTTP_COOKIE']可以获取客户端发送的Cookie信息等等。
HTTP协议详解HTTP(Hypertext Transfer Protocol)是一种在计算机网络中广泛使用的应用层协议,用于在Web浏览器和Web服务器之间传输超文本(例如HTML)和其他资源。
HTTP是一个无状态的协议,每个请求都是相互独立的,并且服务器不会保留任何关于之前请求的状态信息。
HTTP协议的工作原理可以概括为:客户端发送一个HTTP请求到服务器,服务器响应该请求并返回结果。
这个过程通常是通过TCP/IP协议完成的。
HTTP使用一种称为URL(Uniform Resource Locator)的标准来指定资源的地址。
1. 请求方法(Request Method):客户端向服务器发送请求时,指定要执行的操作的方法。
最常见的方法有GET(获取资源)、POST(提交数据)和HEAD(获取报文首部)。
2. 状态码(Status Code):服务器向客户端返回的响应中,包含一个三位数的状态码,用于表示请求的处理结果。
常见的状态码有200(成功)、404(未找到)和500(服务器内部错误)。
3. 报文首部(Header):在HTTP协议的请求和响应报文中,报文首部包含了一些元数据,用于描述报文的属性和附加信息。
例如,报文头中可能包含Accept、Content-Type和Authorization等字段。
4. 报文主体(Body):HTTP协议请求和响应报文中的主要内容都在报文主体中。
例如,客户端的POST请求中的表单数据和服务器响应的HTML页面都包含在报文主体中。
1.简洁和灵活:HTTP协议的设计目标是简单易用、易实现,因此它的报文格式也非常简洁。
同时,HTTP协议也非常灵活,允许使用不同的传输协议和身份验证机制。
2. 无状态:由于HTTP协议的无状态性,服务器不会保留之前请求的任何状态信息。
这就需要客户端发送每个请求时都包含所有必要的信息。
为了解决这个问题,HTTP引入了Cookie和Session等机制。
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 typeparameters from Accept extension parameters is due to historicalpractice. Although this prevents any media type parameter named"q" from being used with a media range, such an event is believedto be unlikely given the lack of any "q" parameters in the IANAmedia type registry and the rare usage of any media typeparameters in Accept. Future media types are discouraged fromregistering any parameter named "q".The exampleAccept: audio/*; q=0.2, audio/basicSHOULD 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 isAccept: text/plain; q=0.5, text/html,text/x-dvi; q=0.8, text/x-cVerbally, 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=12) text/html3) 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.5would cause the following values to be associated:text/html;level=1 = 1text/html = 0.7text/plain = 0.3image/jpeg = 0.5text/html;level=2 = 0.4text/html;level=3 = 0.7Note: A user agent might be provided with a default set of qualityvalues for certain media ranges. However, unless the user agent isa 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 isAccept-Charset: iso-8859-5, unicode-1-1;q=0.8The 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, gzipAccept-Encoding:Accept-Encoding: *Accept-Encoding: compress;q=0.5, gzip;q=1.0Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0A 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 inthe Accept-Encoding field, then it is acceptable, unless it isaccompanied by a qvalue of 0. (As defined in section 3.9, aqvalue of 0 means "not acceptable.")2. The special "*" symbol in an Accept-Encoding field matches anyavailable content-coding not explicitly listed in the headerfield.3. If multiple content-codings are acceptable, then the acceptablecontent-coding with the highest non-zero qvalue is preferred.4. The "identity" content-coding is always acceptable, unlessspecifically refused because the Accept-Encoding field includes"identity;q=0", or because the field includes "*;q=0" and doesnot explicitly include the "identity" content-coding. If theAccept-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, thencontent-codings commonly understood by HTTP/1.0 clients (i.e.,"gzip" and "compress") are preferred; some older clientsimproperly display messages sent with other content-codings. Theserver might also make this decision based on information aboutthe particular user-agent or client.Note: Most HTTP/1.0 applications do not recognize or obey qvaluesassociated with content-codings. This means that qvalues will notwork 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.7would 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 thatlanguage tags are assigned to languages in such a way that it isalways true that if a user understands a language with a certaintag, then this user will also understand all languages with tagsfor which this tag is a prefix. The prefix rule simply allows theuse 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 serverSHOULD 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 tothe user, we remind implementors of the fact that users are notfamiliar with the details of language matching as described above,and should provide appropriate guidance. As an example, usersmight assume that on selecting "en-gb", they will be served anykind of English document if British English is not available. Auser agent might suggest in such a case to add "en" to get thebest matching behavior.14.5 Accept-RangesThe Accept-Ranges response-header field allows the server toindicate its acceptance of range requests for a resource:Accept-Ranges = "Accept-Ranges" ":" acceptable-rangesacceptable-ranges = 1#range-unit | "none"Origin servers that accept byte-range requests MAY sendAccept-Ranges: bytesbut are not required to do so. Clients MAY generate byte-rangerequests without having received this header for the resourceinvolved. Range units are defined in section 3.12.Servers that do not accept any kind of range request for aresource MAY sendAccept-Ranges: noneto advise the client not to attempt a range request.14.6 AgeThe Age response-header field conveys the sender's estimate of the amount of time since the response (or its revalidation) wasgenerated at the origin server. A cached response is "fresh" ifits age does not exceed its freshness lifetime. Age values arecalculated as specified in section 13.2.3.Age = "Age" ":" age-valueage-value = delta-secondsAge values are non-negative decimal integers, representing time inseconds.If a cache receives a value larger than the largest positiveinteger it can represent, or if any of its age calculationsoverflows, it MUST transmit an Age header with a value of2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST include an Age header field in every response generated from itsown cache. Caches SHOULD use an arithmetic type of at least 31bits of range.14.7 AllowThe Allow entity-header field lists the set of methods supportedby the resource identified by the Request-URI. The purpose of thisfield is strictly to inform the recipient of valid methodsassociated with the resource. An Allow header field MUST bepresent in a 405 (Method Not Allowed) response.Allow = "Allow" ":" #MethodExample of use:Allow: GET, HEAD, PUTThis field cannot prevent a client from trying other methods.However, the indications given by the Allow header field valueSHOULD be followed. The actual set of allowed methods is definedby the origin server at the time of each request.The Allow header field MAY be provided with a PUT request torecommend the methods to be supported by the new or modifiedresource. The server is not required to support these methods and SHOULD include an Allow header in the response giving the actualsupported methods.A proxy MUST NOT modify the Allow header field even if it does notunderstand all the methods specified, since the user agent mighthave other means of communicating with the origin server.14.8 AuthorizationA user agent that wishes to authenticate itself with a server--usually, but not necessarily, after receiving a 401 response--doesso by including an Authorization request-header field with therequest. The Authorization field value consists of credentialscontaining the authentication information of the user agent forthe realm of the resource being requested.Authorization = "Authorization" ":" credentialsHTTP access authentication is described in "HTTP Authentication:Basic and Digest Access Authentication" [43]. If a request isauthenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming thatthe authentication scheme itself does not require otherwise, suchas credentials that vary according to a challenge value or usingsynchronized clocks).When a shared cache (see section 13.7) receives a requestcontaining an Authorization field, it MUST NOT return thecorresponding 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-controldirective, the cache MAY use that response in replying to asubsequent request. But (if the specified maximum age haspassed) a proxy cache MUST first revalidate it with the originserver, using the request-headers from the new request to allowthe origin server to authenticate the new request. (This is thedefined behavior for s-maxage.) If the response includes "s-maxage=0", the proxy MUST always revalidate it before re-usingit.2. If the response includes the "must-revalidate" cache-controldirective, the cache MAY use that response in replying to asubsequent request. But if the response is stale, all cachesMUST first revalidate it with the origin server, using therequest-headers from the new request to allow the origin serverto 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 andmight 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-directivecache-directive = cache-request-directive| cache-response-directivecache-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.6cache-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.6cache-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 bythe origin server.- Restrictions on what may be stored by a cache; these may beimposed by either the origin server or the user agent.- Modifications of the basic expiration mechanism; these may beimposed by either the origin server or the user agent.- Controls over cache revalidation and reload; these may only beimposed 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:publicIndicates that the response MAY be cached by any cache, even if it would normally be non-cacheable or cacheable only within a non- shared cache. (See also Authorization, section 14.8, for additional details.)privateIndicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache. This allows an origin server to state that the specified parts of theresponse are intended for only one user and are not a valid response for requests by other users. A private(non-shared) cache MAY cache the response.Note: This usage of the word private only controls where the response may be cached, and cannot ensure the privacy of the message content.no-cacheIf the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests.If the no-cache directive does specify one or more field-names, then a cache MAY use the response to satisfy a subsequent request, subject to any other restrictions on caching. However, the specified field-name(s) MUST NOT be sent in the response to a subsequent request without successful revalidation with the origin server. This allows an origin server to prevent the re-use of certain header fields in a response, while still allowing caching of the rest of the response.Note: Most HTTP/1.0 caches will not recognize or obey this directive.14.9.2 What May be Stored by Cachesno-storeThe purpose of the no-store directive is to prevent the inadvertent release or retention of sensitive information (for example, on backup tapes). The no-store directive applies to the entire message, and MAY be sent either in a response or in a request. If sent in a request, a cache MUST NOT store any part of either this request or anyresponse to it. If sent in a response, a cache MUST NOT store any part of either this response or the request that elicited it. This directive applies to both non- shared and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.Even when this directive is associated with a response, users might explicitly store such a response outside of the caching system (e.g., with a "Save As" dialog). History buffers MAY store such responses as part of their normal operation.The purpose of this directive is to meet the stated requirements of certain users and service authors who are concerned about accidental releases of information via unanticipated accesses to cache data structures. While the use of this directive might improve privacy in some cases, we caution that it is NOT in any way a reliable or sufficientmechanism for ensuring privacy. In particular, malicious or compromised caches might not recognize or obey this directive, and communications networks might be vulnerable to eavesdropping.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.s-maxageIf a response includes an s-maxage directive, then for a shared cache (but not for a private cache), the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header. The s-maxage directive also implies the semantics of the proxy-revalidate directive (see section 14.9.4),i.e., that the shared cache must not use the entry after it becomes stale to respond to a subsequent request withoutfirst revalidating it with the origin server. The s- maxage directive is always ignored by a private cache.Note that most older caches, not compliant with this specification, do not implement any cache-control directives. An origin server wishing to use a cache-control directive that restricts, but does not prevent, caching by an HTTP/1.1-compliant cache MAY exploit the requirement that the max-age directive overrides the Expires header, and the fact thatpre-HTTP/1.1-compliant caches do not observe the max-age directive.Other directives allow a user agent to modify the basic expiration mechanism. These directives MAY be specified on a request:max-ageIndicates that the client is willing to accept a response whose age is no greater than the specified time in seconds.Unless max- stale directive is also included, the client is not willing to accept a stale response.min-freshIndicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.max-staleIndicates that the client is willing to accept a response that has exceeded its expiration time. If max-stale isassigned a value, then the client is willing to accept a response that has exceeded its expiration time by no morethan the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.If a cache returns a stale response, either because of a max-stale directive on a request, or because the cache is configured to override the expiration time of a response, the cache MUST attach a Warning header to the stale response, using Warning 110 (Response is stale).A cache MAY be configured to return stale responses without validation, but only if this does not conflict with any "MUST"-level requirements concerning cache validation (e.g., a "must-revalidate" cache-control directive).If both the new request and the cached entry include "max-age" directives, then the lesser of the two values is used for determining the freshness of the cached entry for that request.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:End-to-end reloadThe request includes a "no-cache" cache-control directive or, for compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field names MUST NOT be included with the no-cache directive in a request. The server MUST NOT usea cached copy when responding to such a request.Specific end-to-end revalidationThe request includes a "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request includes acache-validating conditional with the client's current validator.Unspecified end-to-end revalidationThe request includes "max-age=0" cache-control directive, which forces each cache along the path to the origin server to revalidate its own entry, if any, with the next cache or server. The initial request does not include a cache-validatingconditional; the first cache along the path (if any) that holds a cache entry for this resource includes acache-validating conditional with its current validator.max-ageWhen an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validatorcurrently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new entity and cache validator, however, the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the。