内容协商 (Content Negotiation)

转载 2012年03月25日 21:21:46
大多数响应包含一个实体,此实体包含人类用户能理解的信息。通常,希望提供给用户相应于请求最容易得到的实体。对服务器和缓存来说,不幸的是,并不是所有的用户都对这个最容易得到的实体有喜好,并且并不是所有的用户代理(如web浏览器)都能一致的呈现这些实体。所以,HTTP提供了一些“内容协商”机制 — 当有多个可得的表现形式的时候,对特定的响应选择最好的表现形式的处理过程。

注意:没有称做“格式协商”(译注:“格式”指的是“媒体类型”)的,因为可替换的表现形式可能会同原来的有相同的媒体类型,只是利用了此媒体类型不同的性质,例如一种不同的语言。

任何包含一个实体主体的响应包括错误响应都可能会受协商的支配。

有两种类型的内容协商在HTTP中:服务器驱动协商和代理驱动协商。这两种类型的协商具有正交性并且能被单独使用或联合使用。一个联合使用方法的协商会被叫做透明协商,当缓存利用代理驱动协商的信息的时候,此代理驱动协商的信息被为后续请求提供服务器驱动协商的源服务器提供。

12.1 服务器驱动协商(Server-driven Negotiation)
如果响应的最好的表现形式的选择是通过服务器上的算法来实现,那么这种方式的协商称做服务器驱动协商。选择是基于响应可得的表现形式(根据不同的维度,响应会不同;例如,语言,内容编码,等等)和请求消息里特定的头域或关于请求的其他信息(如:网络客户端的地址)。

服务器驱动协商是有优点的,当从可行的表现形式里进行选择的算法对用户代理进行描述是比较困难的时候(译注:代理驱动协商),或者当服务器期望发送“最好的猜测”给客户端而只通过一个响应(以避免后续请求的回路(一个请求会返回一个响应)延迟如果此“最好的猜测“对用户适合的时候)的时候。为了改善服务器的猜测,用户代理应该包含请求头域(Accept,Accept-Language,Accept-Encoding,等等),这些头域能描述它对响应的喜好。

服务驱动协商有如下缺点:

1. 对服务器不可能确切的决定对用户来说什么是最好的,因为那需要对用户代理和用户对此响应目的的全面理解(如:用户到底想把响应展示到屏幕还是打印到纸上?)。

2. 使用户代理描述请求里的能力是非常无效的(假设只有响应的一小部分有多个表现形式)还有会侵犯用户的隐私。

3. 使源服务器的实现变得复杂,也对为请求产生响应的算法实现变得复杂。

4. 可能会限制公有缓存(public cache)为多个客户请求利用相同响应的能力

HTTP/1.1包含下面的请求头域来使服务器驱动协商启动,这些请求头域描述了用户代理的能力和用户喜好:Accept(14.1节),Accept-Charset(14.2节),Accept-Encoding(14.3节),Accept-Language(14.4节),和User-Agent(14.43节)。然而,一些源服务器并不只局限于这些维度,这些服务器能基于请求的任何方面来让响应不同,这些方面包括请求头域之外的信息或在此规范里没有定义的扩展头域。

Vary头域能被用来表达服务器选择表现形式(representation)利用的参数,表现形式受服务器驱动协商的支配。见14.44节描述了Vary头域如何被服务器的使用,13.6节描述了Vary头域被缓存的使用。

12.2 代理驱动协商 (Agent-driven Negotiation)
对代理驱动协商来说,响应的最好表现形式的选择被用户代理执行,这在接收到源服务器一个初始的响应后。选择是基于响应的一系列可得的表现形式,这些表现形式被包含在初始响应的头域或初始响应的实体主体(entity-body)里,每个表现形式被一个属于自己的URI指定。从这些表现形式中选择可能被自动执行(如果用户代理有能力这样做)或者被用户从超文本连接菜单中手工选择。

代理驱动协商是有优点的,当响应可能会根据一般用途的维度(如:类型,语义,编码)而不同的时候,当源服务器不能通过查看请求而判定用户代理能力的时候,当共有缓存(public cache)被用来分派服务器的承载和减少网络使用的时候。

代理驱动协商也同样存在需要第二次请求而获得最好表现形式的缺点。第二次请求只有当缓存被使用时才是有效率的。另外,此规范没有定义用户代理自动选择表现形式的机制,所以不能防止任何这样的机制被用于HTTP/1.1

HTTP/1.1定义了300(多个选择)和406(不接受的)状态响应,当使用代理驱动协商时服务器不能或不愿意利用服务器驱动协商来提供一个不同的响应的是时候。

12.3 透明协商(Transparent Negotiation)
透明协商是服务器驱动协商和代理驱动协商的结合体。当一个缓存被提供了构成响应的一系列可得的表现形式(就像在代理驱动协商里的响应一样)并且维度的差异能完全被缓存理解,那么此缓存变得有能力代表源服务器为那个资源的后续请求去执行服务器驱动协商。

透明协商的优点在于它能分发源服务器的协商工作并且能移去代理驱动协商的第二次请求的延迟,因为缓存能正确的猜测到合适的响应。

此规范没有定义透明协商的机制,所以,它不能防止任何这样的机制被用于HTTP/1.1。

SpringMVC 4.1 新特性(二)内容协商视图

SpingMVC的内容协商支持三种方式: 使用后缀,如.json、.xml后缀和处理类型的关系可以自己定义前面说的使用Accept头在访问时request请求的参数,比如每次请求request都...
  • w372426096
  • w372426096
  • 2017年11月02日 20:45
  • 120

浏览器缓存和HTTP缓存协商(很清晰)

转自:http://www.cnblogs.com/skynet/archive/2012/11/28/2792503.html 浏览器缓存机制,其实主要就是HTTP协议定义的缓存机制(如: Exp...
  • abc86319253
  • abc86319253
  • 2015年02月12日 18:18
  • 1797

自协商功能原理及工作过程

自协商原理:            自协商是通过一种叫做快速连接脉冲(Fast Link Pulse)的信号实现的,简称FLP。自协商的双方通过FLP来交换数据。        在具备自协商能力的端...
  • daydring
  • daydring
  • 2015年04月14日 10:54
  • 4118

以太网自动协商原理

自协商基本原理    自动协商模式是端口根据另一端设备的连接速度和双工模式,自动把它的速度调节到最高的公共水平,即线路两端能具有的最快速度和双工模式。   自协商功能允许一个网络设备能够将...
  • skyflying2012
  • skyflying2012
  • 2013年12月25日 16:22
  • 9424

HTTPS和密钥协商小结

HTTPSHTTPS使用的TLS协议,主要版本是TLS1.1和TLS1.2,TLS1.3目前还是草案的形式,具体的标准尚未形成。 HTTP当前版本主要是HTTP1.0 HTTP1.1 HTTP协议的...
  • a11211058
  • a11211058
  • 2016年12月12日 15:46
  • 936

SSL/TLS协商过程详解

本文大部分整理自网络,相关文章请见文后参考。 关于证书授权中心CA以及数字证书等概念,请移步 OpenSSL 与 SSL 数字证书概念贴 ,如果你想快速自建CA然后签发数字证书,请移步 基于Open...
  • zhangtaoym
  • zhangtaoym
  • 2017年02月16日 16:06
  • 1766

ssh之密钥和算法协商阶段、认证阶段

ssh的登录过程-版本号协商阶段、密钥和算法协商阶段、认证阶段、会话请求阶段、会话交互阶段 主要讲 密钥和算法协商阶段: 客户请求连接-服务器将对应公钥、生成会话ID发给客户端、客户...
  • u012700515
  • u012700515
  • 2014年08月24日 13:11
  • 1099

SSL密钥协商过程详解

由于非对称加密的速度比较慢,所以它一般用于密钥交换,双方通过公钥算法协商出一份密钥,然后通过对称加密来通信,当然,为了保证数据的完整性,在加密前要先经过HMAC的处理。 SSL缺省只进行...
  • MissLong
  • MissLong
  • 2013年08月01日 09:56
  • 12261

密钥协商基础知识

不同的密钥协商算法TLS-RSA这种算法,客户端指定副主密钥,然后加密传输 TLS-RSA:在这个场景下,PreMasterSecret是由客户端指定的,并用RSA公钥加密发送给服务器。服务器不...
  • a11211058
  • a11211058
  • 2016年12月12日 15:18
  • 1297

PHY以太网自动协商原理

自协商原理:            自协商是通过一种叫做快速连接脉冲(Fast Link Pulse)的信号实现的,简称FLP。自协商的双方通过FLP来交换数据。        在具备自协商能...
  • maopig
  • maopig
  • 2016年10月06日 11:29
  • 4577
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:内容协商 (Content Negotiation)
举报原因:
原因补充:

(最多只允许输入30个字)