内容协商 (Content Negotiation)

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

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

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

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

一、 服务器驱动协商(Server-driven Negotiation)

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

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

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

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

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

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

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

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

Vary头域能被用来表达服务器选择表现形式(representation)利用的参数,表现形式受服务器驱动协商的支配。

  • Accept: Which media types are acceptable for the response, such as “application/json,” “application/xml,” or a custom media type such as "application/vnd.example+xml"
  • Accept-Charset: Which character sets are acceptable, such as UTF-8 or ISO 8859-1.
  • Accept-Encoding: Which content encodings are acceptable, such as gzip.
  • Accept-Language: The preferred natural language, such as “en-us”.

二、代理驱动协商 (Agent-driven Negotiation)

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

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

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

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

三、 透明协商(Transparent Negotiation)

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

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

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

ASP.NET Web API支持内容协商: 客户端和服务器可以一起从API返回的数据,以确定正确的格式. 我们提供了默认的XML支持, JSON的, 和表格的URL编码格式, 你可以扩展这种支持,通过添加自己的格式化, 甚至取代默认内容的谈判策略.

ASP.NET Web API的内容协商具体请看:http://www.asp.net/web-api/overview/formats-and-model-binding/content-negotiation

Different MediaTypeFormatters for same MediaHeaderValue in ASP.NET Web API

ASP.NET Web API: Query string based content formatting

http://code.msdn.microsoft.com/ASPNET-Web-API-File-Upload-a8c0fb0d http://stackoverflow.com/questions/12593001/web-api-model-binding-with-multipart-formdata

http://lonetechie.com/2012/09/23/web-api-generic-mediatypeformatter-for-file-upload/

http://www.dotblogs.com.tw/regionbbs/archive/2010/12/20/implement.http.post.multipart.form.data.aspx

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏逢魔安全实验室

DedeCMS任意用户密码重置漏洞

综述 2018年01月09日,Dedecms官方更新了DedeCMS V5.7 SP2正式版,后续在10日有网友爆出其存在任意用户密码重置漏洞。...

37930
来自专栏架构师之路

应用层/安全层/传输层如何进行协议选型?

系统设计,协议先行。 大部分技术人没有接触协议的设计细节,更多的是使用已有协议进行应用层的编码,例如: (1)使用http作为载体,设计get/post/coo...

43550
来自专栏葡萄城控件技术团队

Winform文件下载之WebClient

最近升级了公司内部使用的一个下载小工具,主要提升了下面几点: 1. 在一些分公司的局域网中,连接不上外网 2. 服务器上的文件更新后,下载到的还是更新前的文件 ...

21750
来自专栏小樱的经验随笔

CTF---安全杂项入门第三题 这是捕获的黑客攻击数据包,Administrator用户的密码在此次攻击中泄露了,你能找到吗?

这是捕获的黑客攻击数据包,Administrator用户的密码在此次攻击中泄露了,你能找到吗?分值:30 来源: 2014sctf 难度:难 参与人数:3918...

43390
来自专栏Android开发实战

Android O 行为变更官方指南

Android O 除了提供诸多新特性和功能外,还对系统和 API 行为做出了各种变更。本文重点介绍您应该了解并在开发应用时加以考虑的一些主要变更。

13320
来自专栏FreeBuf

网站管理软件 – AspxSpy2014 Final

受bin牛委托修改并发布,版权归bin牛所有。 Bug/建议提交:zcgonvh@rootkit.net.cn 祝各位马年大吉,财源滚滚。 免责声明: 本程序只...

40190
来自专栏二次元

新浪微博动态 RSA 分析图文+登录

二、抓包 还是遵从我们上一次的抓包流程,养成良好的习惯,这里就不多做说明。

12300
来自专栏小樱的经验随笔

CTF---安全杂项入门第二题 A记录

A记录分值:20 来源: sammie 难度:中 参与人数:2255人 Get Flag:566人 答题人数:621人 解题通过率:91% 他在看什么视频,...

519140
来自专栏FreeBuf

一款隐藏嵌入式Rookit的DDoS木马分析

该款木马分析文章在2015年由@PETER KÁLNAI 最先发表于AVAST的公开blog中,木马的架构严谨,设计精良,应该是产业化的一部分。接下来我们就来看...

30470
来自专栏Java帮帮-微信公众号-技术文章全总结

2017年3月Java9带来的革新!

? 一:计划 2016-05-26: 功能开发完成 2016-08-11: 执行测试 2016-09-01: 开始减速 2016-10-20: 零错误反弹(注...

25240

扫码关注云+社区

领取腾讯云代金券