图解HTTP(三)
本系列是对于《图解HTTP》的知识点整理。
《图解HTTP》出版于2014年,此时的HTTP2协议还未修订完成,故全书只讲解HTTP1.0、HTTP1.1以及会涉及到一点HTTP2.0依赖的协议。
本文涉及第六章的内容。
一、HTTP首部
首部内容为客户端和服务器分别处理请求和响应提供所需要的信息。
HTTP请求报文
在请求报文中,HTTP报文由方法、URI、HTTP版本、HTTP首部字段等部分构成。
HTTP响应报文
在响应报文中,HTTP报文由HTTP版本、状态码(数字和原因短语)、HTTP首部字段等部分组成。
1、HTTP首部字段
首部字段能起到传递额外重要信息的作用。使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。
1.1 HTTP首都字段结构
HTTP首部字段是由首部字段名和字段值构成的,中间用冒号“:”分隔。同时,单个首部字段可以有多个值。
Keep-Alive: timeout=15, max=100
【拓】当字段名重复了,由于这种情况在规范中尚未明确,根据浏览器内部处理逻辑不同,结果可能并不一致。
1.2 4种HTTP首部字段类型
HTTP首部字段根据实际用途被分为以下4种类型。
-
- 通用首部字段,请求报文和响应报文两方都会使用的首部。
- 请求首部字段,请求报文使用的首部,补充了请求的附加内容、客户端信息、响应信息相关优先级等信息。
- 响应首部字段,响应报文使用的首部,补充了响应的附加内容,也会要求客户端附加额外的内容信息。
- 实体首部字段,针对报文实体部分使用的首部。补充了资源内容更新事件等与实体有关的信息。
1.3 HTTP/1.1 首部字段一览
HTTP/1.1规范定义了如下47种首部字段。
1.4 非HTTP/1.1 首部字段
在HTTP协议通信中使用到的首部字段,不限于RFC2616中定义的47种首部字段。还有Cookie、Set-Cookie和Content-Disposition等在其他RFC种定义的首部字段。
这些非正式的首部字段统一归纳在RFC4229 HTTP Header Field Registrations。
1.5 End-to-end首部和Hop-by-hop首部
HTTP首部字段将定义成缓存代理和非缓存代理的行为,分成2种类型。
端到端首部(End-to-end Header)
分在此类别中的首部会转发给请求/响应对应的最终接收目标,且必须保存在由缓存生成的响应中,另外规定它必须被转发。
逐跳首部
分在此类别中的首部只对单次转发有效,会因为通过缓存或代理而不再转发。HTTP/1.1和之后版本中,如果要使用hop-by-hop首部,需提供Connection首部字段。
下面列举了HTTP/1.1中的逐跳首部。除了这8个首部字段之外,其他所有字段都属于端到端首部。
-
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- Trailer
- TE
- Transfer-Encoding
- Upgrade
2、HTTP/1.1 通用首部字段
可以用于请求和响应的首部字段。
2.1 Cache-Control
通过指定首部字段Cache-Control的指令,就能操作缓存的工作机制。
Cache-Control指令一览表如下,分为缓存请求指令和缓存响应指令。
表示能否缓存的指令
public指令和private指令分别是响应对于缓存服务器缓存的限制。public指令缓存服务器能向任一用户提供缓存,private指令缓存服务器只会对特定用户提供资源缓存的服务。
no-cache指令在请求报文和响应报文的表现并不相同。
在请求报文中,no-cache字段名没有具体参数值,表示客户端不接收缓存过的响应,缓存服务器必须把客户端的请求转发给源服务器。
在响应报文中,no-cache字段可以指定具体参数值,服务器端的no-cache表示缓存服务器不能对资源进行缓存,且源服务器不再对缓存服务器请求中提出的资源有效性进行确认,且禁止其对响应资源进行缓存操作。
当响应报文中的no-cache字段指定了具体参数值,则接收到此响应的客户端不能使用客户端本地的缓存。
Cache-Control: no-cache=Location(只能在响应中指定参数值)
控制可执行缓存的对象的指令
no-store指令,该指令规定缓存不能在本地存储请求或响应的任意部分。
【拓】no-cache代表不缓存过期的资源,no-store才是真正地不进行缓存。
指定缓存期限和认证的指令
s-maxage指令
表示从资源缓存时间起到过期的最大时间间隔
Cache-Control: s-maxage=604800(单位:秒)
s-maxage指令的功能和max-age指令的相同,他们的不同是s-maxage只适用于供多为用户使用的公共缓存服务器(代理)。
另外,当使用s-maxage指令后,则直接忽略对Expires首部字段及max-age指令的处理。
max-age指令,当客户端发送的请求包含max-age指令时,缓存服务器会检查缓存时间;当服务端返回的响应中包含max-age指令时,缓存服务器将不对资源的有效性再作确认,而将max-age作为资源保存为缓存的最长时间。
应用HTTP/1.1版本的缓存服务器中,max-age的优先级比Expires首部字段的优先级高;而在应用HTTP/1.0版本的服务器上则情况相反。
min-fresh指令,要求缓存服务器返回从现在到+min-fresh后没有失效的资源。
max-stale指令,可以接收过期的缓存。当该指令未指定参数值时,客户端可以接收过期了无论多久的缓存;当指定了具体数值时,那么即使过期,只要仍处于max-stale指定的时间内客户端仍会接收。
only-if-cache指令,表示客户端仅在缓存服务器本地缓存目标资源的情况下才会要求其返回。换言之,该指令要求缓存服务器不重新加载响应,也不会再次确认资源有效性。若发生请求缓存服务器的本地缓存无响应,则返回状态码504 Gateway Timeout。
must-revalidate指令,要求代理向源服务器再次验证即将返回的响应缓存的有效性。如果出现代理无法连通源服务器再次获取有效缓存的情况,缓存服务器必须返回504。另外,使用must-revalidate指令会忽略max-stale指令。
proxy-revallidate指令,要求所有的缓存服务器在接收到客户端带有该指令的请求后,在返回响应之前必须验证缓存的有效性。
no-transform指令,规定缓存不能改变实体的媒体类型,这样子可以防止缓存或代理压缩图片等类似操作。
Cache-Control扩展
cache-extension token
token [ "=" ( token | quoted-string ) ]
通过cache-extension标记,可以扩展Cache-Control首部字段内的指令。如果缓存服务器不能理解该token,就会直接忽略。extension tokens仅对能理解它们的缓存服务器来说是有意义的。
如下,community就是cache-extension token。
Cache-Control: private, community="UCI"
2.2 Connection
Connection首部字段具有如下两个作用。
-
- 控制不再转发给代理的首部字段
- 管理持久连接
控制代理不再转发的首部字段
Connection: 不再转发的首部字段
管理持久连接
HTTP/1.1版本的默认连接都是持久连接。当服务器端想明确断开连接时,则指定Connection首部字段的值为Close。
HTTP/1.1之前的版本都是默认短连接的。如果想在旧版本的HTTP协议上维持持久连接,则需要指定Connection首部字段的值为Keep-Alive。
如上图,客户端发送Keep-Alive指令后,服务器会返回Keep-Alive字段和Keep-Alive指令。
2.3 Date
首部字段Date表明创建HTTP报文的日期和时间
HTTP/1.1协议使用在RFC1123中规定的日期时间格式。
Date: Tue, 03 Jul 2012 04:40:59 GMT
除此之外还有其他格式。
2.4 Pragma
Pragma首部字段是HTTP/1.1作为与HTTP/1.0的向后兼容而定义的。规范定义的形式唯一。
Pragma: no-cache
该首部字段只能用在客户端发送的请求中。客户端会要求所有的中间服务器不返回缓存的资源。
当所有的中间服务器都能以HTTP/1.1为基准,那直接使用Cache-Control: no-cache是最理想的。但是这却是不显示的,所以发送的请求会包含下面两个首部字段。
Cache-Control: no-cache
Pragma: no-cache
2.5 Trailer
Trailer首部字段会事先说明在报文主体后记录了那些首部字段。
该首部字段可应用在HTTP/1.1版本分块传输编码时。
HTTP/1.1 200 OK Date: Tue, 03 Jul 2012 04:40:56 GMT Content-Type: text/html ... Transfer-Encoding: chunked Trailer: Expires ...(报文主题)... 0 Expires: Tue, 28 Sep 2004 23:59:59 GMT
上述例子中,首部字段Trailer的值为Expires,在报文主体之后(分块长度0之后)出现了首部字段Expires。
2.6 Transfer-Encoding
该字段指定了传输报文主体时采用的编码方式。
HTTP/1.1的传输编码方式仅对分块传输编码有效。
2.7 Upgrade
首部字段Upgrade用于检测HTTP协议及其他协议是否可使用更高的版本进行通信,其参数值可以用来指定一个完全不同的通信协议。
对于附有首部字段Upgrade的请求,服务器可用101 Switching Protocol状态码作为响应返回。
2.8 Via
首部字段Via可以追踪客户端与服务器之间的请求和响应报文的传输路径。
在报文金国代理或网关时,会先在首部字段Via中附加该服务器的信息再进行转发。
为了避免请求回环的发生,必须在经过代理时附加该首部字段。
Via字段值的行头的1.0是表示接受请求的服务器上应用的HTTP协议版本。
2.9 Warning
HTTP/1.1的Warning首部是从HTTP/1.0的响应首部(Retry-After)演变过来的。该首部会告知用户一些与缓存相关的问题的警告。
Warning首部的格式如下。最后的日期时间部分可省略。
除此之外,HTTP/1.1中还定义7中警告状态码。
3、请求首部字段
3.1 Accept
Accept首部字段可通知服务器,用户代理能够处理的媒体类型及媒体类型的相对优先级。可使用type/subtype这种形式,一次指定多种媒体类型。
下面列举了几个媒体类型。
若想给显示的媒体类型增加优先级,则使用q=来额外表示权重值,用分号(;)分隔。
权重值q的范围是0~1,且1为最大值。不指定权重值时,默认q=1.0。
分号前为指定的媒体类型,分号后为优先级q。
可以用通配符(*)。
3.2 Accept-Charset
该首部字段用来通知服务器用户代理支持的字符集及字符集的相对优先级。
该首部字段应用于内容协商机制的服务器驱动协商。
3.3 Accept-Encoding
该首部字段用来告知服务器用户代理支持的内容编码及内容编码的优先级顺序。
下面列举几个内容编码的例子。
3.4 Accept-Language
3.5 Authorization
首部字段Authorization是用来告知服务器,用户代理的认证信息(证书值)。通常,想要通过服务器认证的用户代理会在接收到返回的401状态码响应后,把首部字段Authorization加入到请求中。
共用缓存在接收到含有Authorization首部字段的请求时的操作处理会略有差距。
3.6 Expect
客户端用Expect首部字段来告知服务器,期望出现的某种特定行为。
因服务器无法理解客户端的期望做出回应而发生错误时,会返回状态码417 Expectation Failed。
HTTP/1.1规范只定义了100-continue(状态码100 Continue之意)。
等待状态码100 响应的客户端在发送请求时,需要指定Expect: 100-continue。
3.7 From
首部字段From用来告知服务器使用用户代理的电子邮件地址。通常,其使用目的是为了显示搜索引擎等用户代理的负责人的电子邮件联系方式。使用代理时,应尽可能包含From首部字段(但可能会因为代理不同,将电子邮件地址记录在User-Agent首部字段内)。
3.8 Host
首部字段Host会告知服务器,请求的资源所处的互联网主机名和端口号。Host首部字段在HTTP/1.1规范内是唯一一个必须被包含在请求内的首部字段。
首部字段Host和以单台服务器分配多个域名的虚拟主机的工作机制有密切的关联,这是首部字段Host必须存在的意义。
请求被发送至服务器是,请求中的主机名会用IP地址直接替换解决。但如果这时,相同的IP地址下部署运行着多个域名,就需要使用首部字段Host来明确指出请求的主机名。若服务器未设定主机名,那直接发送一个空值即可。
3.9 if-Match
形如if-xxx这种形式的请求首部字段,都可称为条件请求。服务器接收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。
首部字段if-Match,会告知服务器匹配资源所用的实体标记(ETag)值。这是的服务器无法使用弱ETag值。
只有if-Match字段值和资源的ETag值两者一致时,服务器才会执行请求。反之,则返回状态码412 Precondition Failed的响应。
可以使用星号(*)指定if-Match的值,此时服务器将会武略ETag的值,只要资源存在就处理请求。
3.10 if-Modified-Since
首部字段if-Modified-Since会告知服务器若字段值早于资源的更新时间,则希望处理该请求。如果在if-Modified-Since字段值的日期之后,请求的资源都没有更新过,则返回状态码304 Not Modified的响应。
if-Modified-Since字段用于确认代理或客户端拥有的本地资源的有效性。获取资源的更新日期时间,可以通过确认首部字段Last-Modified的值来确定。
3.11 if-None-Match
只有在if-None-Match的字段值与ETag值不一致时,可处理该请求。与if-Match首部字段的作用相反。
在GET或HEAD方法中使用首部字段if-None-Match可获取最新的资源。因此,这与使用首部字段if-Modified-Since时有些类似。
3.12 if-Range
If-Range字段值若是跟ETag值或更新的日期时间匹配一致,那么就作为范围请求处理。
若不一致,则忽略范围请求,返回全部资源。
if-Range首部字段的优点在于,当if-Range字段值不匹配时,会忽略范围请求返回全部资源。而如果使用if-Match首部字段则需要两次请求,如下。
当服务器中资源更新,那客户端持有资源的一部分也会随之无效,此时,范围请求作为前提则是无效的。这时服务器会暂且以状态码412 Precondition Failed作为响应返回,其目的是催促客户端再次发送请求。
3.13 if-Unmodified-Since
if-Unmodified-Since首部字段和if-modified-Since首部字段的作用相反。它的作用是告知服务器,指定的请求资源只有在字段值内指定的日期时间之后,未发生更新的情况下,才能处理请求。
如果在指定的日期时间之后发生了更新,则以状态码412 Precondition Failed作为响应返回。
3.14 Max-Forwards
通过TRACE方法或OPTIONS方法,发送包含首部字段Max-Forwards的请求时,该字段以十进制整数形式指定可经过的服务器最大数目。
使用HTTP协议通信时,请求可能会经过代理等多台服务器。途中,如果代理服务器发生异常导致请求转发失败,客户端也就等不到服务器返回的响应了。对此,我们无从可知。
可以灵活使用首部字段Max-Forwards,针对上述问题进行调查。
3.15 Proxy-Authorization
接收到代理服务器发来的认证质询时,客户端会发送包含首部字段Proxy-Authorization的请求,以告知代理服务器认证所需要的信息。
这个行为是与客户端和服务器之间的HTTP访问认证相类似的,不同的是认证行为发生在客户端与代理之间。
客户端和服务器之间的认证,使用首部字段Authorization可起到相同作用。
3.16 Range
对于只需要获取部分资源的范围请求,包含首部字段Range即可告知服务器资源的指定范围。
接收到附带Range首部字段请求的服务器,会在处理请求后返回状态码为206 Partial Content的响应。无法处理范围请求时,则会返回状态码200 OK的响应及全部资源。
3.17 Referer
Referer首部字段会告知服务器发起请求的原始资源的URI。
当直接在浏览器的地址栏输入URI,或处于安全性的考虑时,也可以不发送该首部字段。
3.18 TE
首部字段TE会告知服务器客户端能够处理响应的传输编码方式(内容编码)及相对优先级。
首部字段TE还可以指定伴随Trailer字段的分块传输编码的方式。只需要将trailers赋值给该字段值。
3.19 User-Agent
首部字段User-Agent会将创建请求的浏览器和用户代理名称等信息传达给服务器。
由网络爬虫发起请求时,有可能会在字段内添加爬虫作者的电子邮件地址。此外,如果请求经过代理,那么中间也很可能被添加上代理服务器的名称。
4、响应首部字段
4.1 Accept-Ranges
首部字段Accept-Ranges用来告知客户端服务器是否能处理范围请求,以指定获取服务器某个部分的资源。
可以指定的字段值有两种,可处理范围请求时指定其为bytes,反之则指定其为none。
4.2 Age
首部字段Age能告诉客户端,源服务器是在多久前创建了响应。字段值的单位为秒。
若创建该响应的是缓存服务器,Age值是指缓存后的响应再次发起认证到认证完成的时间。代理创建响应时必须加上首部字段Age。
4.3 ETag
首部字段ETag能告知客户端实体标识。它时一种可将资源以字符串形式做唯一标识的方式。服务器会为每份资源分配对应的ETag值。
当资源更新时,ETag值也需要更新。生成ETag值没有统一的算法规则,而仅仅是由服务器来分配。
同份资源更新前后或不同语言版本对应的ETag是不同的,但是URI是相同的。
ETag中由强ETag值和弱ETag值之分。
强ETag值,不论实体发生多么细微的变化都会改变其值。
弱ETag值,只用于提示资源是否相同。只有资源发生根本改变,产生差异才会改变ETag值。弱ETag会在字段值最开始处附加W/。
4.4 Location
使用首部字段Location可以将响应接收方引导至某个与请求URI位置不同的资源。
基本上,该字段会配合3XX:Redirection的响应,提供重定向的URI。
4.5 Proxy-Authenticate
首部字段Proxy-Authenticate会把由代理服务器所要求的认证信息发送给客户端。
它与客户端与服务器之间的HTTP访问认证的行为相似,不同之处在于其认证行为是在客户端和代理之间进行的。
客户端与服务器之间进行认证时,首部字段WWW-Authorization有着相同的作用。
4.6 Retry-After
首部字段Reter-After告知客户端应该在多久之后再次发送请求。主要配合状态码503 Service Unavailable响应,或者3xx Redirect响应一起使用。
字段值额可以指定为具体的日期事件,也可以是创建响应后的秒数。
4.7 Server
首部字段Server告知客户端当前服务器安装的HTTP服务器应用程序的信息。不单单会标出服务器上的软件应用名称,还有可能包括版本号和安装时启用的可选项。
4.8 Vary
首部字段Vary可对缓存进行控制。源服务器会向代理服务器传达关于本地缓存使用方法的命令。
从代理服务器接收到源服务器返回包含Vary指定项的响应之后,若要再进行缓存,仅对请求中含有相同Vary字段值指定的首部字段的值的请求返回缓存。
即使对相同资源发起请求,但由于Vary指定的首部字段不相同,因此必须要从源服务器重新获取资源。
4.9 WWW-Authenticate
首部字段WWW-Authenticate用于HTTP访问认证。他会告知客户端适用于访问请求URI收自定资源的认证方案(Basic或是Digest)和带参数提示的质询(challenge)。状态码401 Unauthorized响应中,肯定带有首部字段WWW-Authenticate。
上述示例中,realm字段的字符串是为了辨别请求URI指定资源所受到的保护策略。
5、实体首部字段
实体首部字段是包含中请求报文和响应报文中的实体部分所使用的首部,用于补充内容的更新事件等与实体相关的信息。
5.1 Allow
首部字段Allow用于通知客户端能够支持Request-URI指定资源的所有HTTP方法。当服务器接收到不支持的HTTP方法时,会以状态码405 Method Not Allowed作为响应返回。于此同时,还会把所有能支持的HTTP方法写入首部字段Allow后返回。
5.2 Content-Encoding
首部字段Content-Encoding会告知客户端服务器对实体的主体部分选用的内容状态编码。
5.3 Content-Language
该首部字段告知客户端,实体主体使用的自然语言(指中英文等语言)。
5.4 Content-Length
该字段表明了实体主体部分的大小(单位是字节)。对实体进行内容编码传输时,不能再使用Content-Length首部字段。
5.5 Content-Location
该首部字段给出与报文主体部分相对于的URI。和首部字段Location不同,Content-Location表示的是保温主体返回资源对应的URI。
比如,对于使用首部字段Accept-Language的服务器驱动型请求,当返回的页面内容与实际请求的对象不同时,首部字段Content-Location内会写明URI。(访问http://www.hackr.jp/返回的对象却是http://www.hackr.jp/index-ja.html等类似情况)
5.6 Content-MD5
首部字段Content-MD5是一串由MD5算法生成的值,其目的在于检测报文主体在传输过程中是否保持完整,以及确认传输到达。
对于报文主体执行MD5算法获得的128位二进制数,再通过Base64编码后将结果写入Content-MD5字段值。由于HTTP首部无法记录二进制值,所以要通过Base64编码处理。
为保证报文的有效性,客户端会再次执行相同的算法,然后将计算出来的值与接收到的Content-MD5的字段值比较。
常用这种方法,对于内容上的偶发性改变是无从查证的,也无法检测出恶意篡改。其中一个原因是,内容如果能被篡改,则意味着MD5也可重新计算然后被篡改。
5.7 Content-Range
针对范围请求,返回响应时使用该首部字段,告知客户端作为响应返回的实体的那个部分符合范围请求。字段值以字节为单位,表示当前发送部分及整个实体大小。
5.8 Content-Type
该字段说明实体主体内对象的媒体类型。和首部字段Accept一样,字段值用type/subtype形式赋值。
参数charset使用iso-8859-1或euc-jp等字符集进行赋值。
5.9 Expires
该首部字段会将资源的失效的日期告知客户端。
缓存服务器接收到带有Expires首部字段的响应后,会以缓存来回应请求。在Expires字段值指定的时间之前,响应的副本会一直被保存着。当超过指定的时间后,缓存服务器会在请求发送过来时,会转向源服务器请求资源。
源服务器不希望缓存服务器对资源缓存时,最好在Expires字段内写入与首部字段Date相同的时间值。
但是,当首部字段Cache-Control有指定max-age指令时,则会忽略Expires。
5.10 Last-Modified
该字段指明资源最终修改的时间。
6、为Cookie服务的首部字段
Cookie的工作机制是用户识别及状态管理。Web网站为了管理用户的状态会通过Web浏览器,把一些数据临时写入用户的计算机内。接着当用户访问该Web网站时,可通过通信方式取回之前存放的Cookie。
调用Cookie时,由于可校验Cookie的有效期,以及发送方的域、路径、协议等信息,所以正规发布的Cookie内的数据不会因来自其他Web站点和攻击者的攻击而泄漏。
6.1 Set-Cookie
当服务器准备管理客户端的状态时,会事先告知各种信息。下面的表格列举了Set-Cookie的字段值。
一旦Cookie从服务器端发送至客户端,服务器端就不存在可以显示删除Cookie的方法。但是可通过覆盖过期的Cookie,实现对客户端Cookie的实质性删除操作。
path属性
用于限制指定Cookie的发送范围的文件目录。不过另有方法可避开这项限制,故对其作为安全机制的效果不能抱有期待。
domain属性
通过指定domain属性指定域名,可以做到与结尾匹配一致。
比如指定example.com后,除了example.com以外,www.example.com或www2.example等都可以发送Cookie。
因此,除了针对具体指定的多个域名发送Cookie之外,不指定domain属性显得更安全。
HttpOnly属性
该属性的主要目的为防止跨站脚本攻击对Cookie的信息窃取。
但是,该属性扩展并非是为了防止XSS而开发的。
6.2 Cookie
首部字段Cookie会告知服务器,当客户端想要获得HTTP状态管理支持时,就会在请求中包含从服务器接收到的Cookie。接收到多个Cookie时,同样可以以多个Cookie形式发送。
7、其他首部字段
HTTP首部字段是可以自行扩展的。下面会介绍一些最为常用的首部字段。
7.1 X-Frame-Options
该首部字段属于HTTP响应首部,用于控制网站内容在其他Web网站的Frame标签内的显示问题。其主要目的是为了防止点击劫持(clickjacking)攻击。
X-Frame-Options有以下两个可指定的字段值。
-
- DENY:拒绝
- SAMEORIGIN:仅同源域名下的页面(Top-level-browsing-context)匹配时许可。(比如,当 指定http://hacke.jp/sample.html页面为SAMEORIGIN时,那么hackr.jp上所有的页面的frame都被允许加载该页面,而example.com等其他域名的页面就不行了)
- ALLOW-FROM<uri>:表示该页面可以在指定来源的frame中显示,当指定的uri为多个时,用逗号分隔。
能在所有Web服务器端预设X-Frame-Options字段值是最理想的状态。
7.2 X-XSS-Protection
该首部字段属于HTTP响应首部,是针对跨站脚本攻击(XSS)的一种策略,用于控制浏览器XSS防护机制的开关。
可指定的字段值如下:
-
- 0:将XSS过滤设置为无效状态
- 1:将XSS过滤设置成有效状态
7.3 DNT
该首部字段属于HTTP请求首部,其中DNT是Do Not Track的简称,意味拒绝个人信息被收集,是表示拒绝被精准广告追踪的一种方法。
可指定的字段值如下:
-
- 0:同意被追踪
- 1:拒绝被追踪
7.4 P3P
首部字段P3P属于HTTP响应首部,通过利用P3P(The Platform for Privacy Preferences,在线隐私偏好平台)技术,可以让Web网站上的个人隐私变成一种仅供程序可理解的形式,以达到保护用户隐私的目的。
要进行P3P的设定,需按以下操作步骤进行。
-
- 创建P3P隐私
- 创建P3P隐私对照文件后,保存命名在/w3c/p3p.xml
- 从P3P隐私中新建Compact policies后,输出到HTTP响应中
有关P3P的详细规范可以参看下方链接。
- The Platform for Privacy Preferences 1.0 ( P3P1.0) Specification
https://www.w3.org/TR/P3P/
关于X-前缀的废除。在以前,通过添加X-前缀区分非标准参数。但是该做法有百害而无一利,因此已停止该做法。然而对于已在使用中的X-前缀来说,不应该要求其变更。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决:字节Trae VS Cursor,谁才是开发者新宠?
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南