一个URL常常需要代表若干不同的资源.例如那种需要以多种语言提供其内容的网站站点.如果某个站点有说法语的和说英语的两种用户,它可能想用这两种语言提供网站站点信息.理想情况下,服务器应当向英语用户发送英文版,向法语用户发送法文版——用户只要访问网站主页就可以得到相应语言的内容. HTTP提供了内容协商方法,允许客户端和服务器作这样的决定.通过这些方法,单一的URL就可以代表不同的资源(比如,同一个网站页面的法语版和英语版),这些不同的版本称为变体.本文将详细介绍内容协商. 一.概述 我们在日常的抓

1 多媒体格式化器 多媒体类型又叫MIME类型,指示了数据的格式.在HTTP协议中多媒体类型描述了消息体的格式.一个多媒体类型包括两个字符串:类型和子类型. 例如: text/html.image/png.application/json.application/pdf. 请求的Content-Type标头指定消息体的格式,指示接收者应如何解析消息体内容. 例如:请求告知服务端请求数据类型为HTML, XHTML, or XML 请求:Accept: text/html,application/

一,内容协商(Content Negotiation) 同一个Web网站可能存在很多份相同内容的页面,比如英文版和中文版的Web页面,它们内容上相同,但是使用语言不同.比如大家进入英文版的google首页和中文版的google首页,页面元素布局一致,但是显示的语言不同. 当浏览器的默认语言为英文或者中文,访问相同URI的Web页面时候,就返回对应的英文或中文的Web页面,这种机制称为内容协商(Content Negotiation). 内容协商机制是指客户端和服务器就响应资源的内容进行交涉,然后

每篇一句 十个光头九个富,最后一个会砍树 前言 不知你在使用Spring Boot时是否对这样一个现象"诧异"过:同一个接口(同一个URL)在接口报错情况下,若你用rest访问,它返回给你的是一个json串:但若你用浏览器访问,它返回给你的是一段html.恰如下面例子(Spring Boot环境~): @RestController @RequestMapping public class HelloController { @GetMapping("/test/error&

每篇一句 在绝对力量面前,一切技巧都是浮云 前言 上文 介绍了Http内容协商的一些概念,以及Spring MVC内置的4种协商方式使用介绍.本文主要针对Spring MVC内容协商方式:从步骤.原理层面理解,最后达到通过自己来扩展协商方式效果. 首先肯定需要介绍的,那必然就是Spring MVC的默认支持的四大协商策略的原理分析喽: ContentNegotiationStrategy 该接口就是Spring MVC实现内容协商的策略接口: // A strategy for resolvin

每篇一句 人生很有意思:首先就得活得长.活得长才能够见自己,再长就可以见众生 前言 在经过 前两篇 文章了解了Spring MVC的内容协商机制之后,相信你已经能够熟练的运用Spring MVC提供的这项能力,配合RESTful发挥它的功效了.这其实也就达到了我们目的的80%,也达到了我书写这块知识点的目的. 为何说是80%呢?因为我认为在前后端完全分离的今天,绝大部分使用场景都是这种情况,完成了覆盖. 为何还有20%呢?因为内容协商不仅仅可以使用在HttpMessage上,还可以使用在View

由于ASP.NET Web API具有与ASP.NET MVC类似的编程方式,再加上目前市面上专门介绍ASP.NET Web API 的书籍少之又少(我们看到的相关内容往往是某本介绍ASP.NET MVC的书籍“额外奉送”的),以至于很多人会觉得ASP.NET Web API仅仅是ASP.NET MVC的一个小小的扩展而已,自身并没有太多“大书特书”的地方.而真实的情况下是:ASP.NET Web API不仅仅具有一个完全独立的消息处理管道,而且这个管道比为ASP.NET MVC设计的管道更为复

前面的话 首部和方法配合工作,共同决定了客户端和服务器能做什么事情.在请求和响应报文中都可以用首部来提供信息,有些首部是某种报文专用的,有些首部则更通用一些.本文将详细介绍HTTP报文中的首部 结构 HTTP首部字段是构成HTTP报文的要素之一.在客户端与服务器之间以HTTP协议进行通信的过程中,无论是请求还是响应都会使用首部字段,它能起到传递额外重要信息的作用.使用首部字段是为了给浏览器和服务器提供报文主体大小.所使用的语言.认证信息等内容 HTTP首部字段是由首部字段名和字段值构成的,中间用

目前国内讲解HTTP协议的书是在太少了,记忆中有两本被誉为经典的书<HTTP权威指南>与<TCP/IP详解,卷1>,但内容晦涩难懂,学习难度较大.其实,HTTP协议并不复杂,理解起来也不会花费太多学习成本,这本书的出现就及时缓解了该问题.对基础及核心部分的深入学习是成为一名专业技术人员的前提,以不变应万变才是立足之本.此外,这本书也是我的2016年度读书计划中的一本,它和<图解TCP/IP>一起作为计算机网络基础部分为我温故知新了一把,谢谢作者和译者,画了这么多图解让我

同源策略(Same Origin Policy)的存在导致了"源"自A的脚本只能操作"同源"页面的DOM,"跨源"操作来源于B的页面将会被拒绝.同源策略以及跨域资源共享在大部分情况下针对的是Ajax请求.同源策略主要限制了通过XMLHttpRequest实现的Ajax请求,如果请求的是一个"异源"地址,浏览器将不允许读取返回的内容.JSONP是一种常用的解决跨域资源共享的解决方案,现在我们利用ASP.NET Web API自身

HTTP基础的简单理解 在了解HTTP协议之前,我们先了解下TCP/IP的参考模型,TCP/IP参考模型分为四层:应用层.传输层.网络层.链路层(数据链路层). 应用层:为不同的网络应用提供所需的服务. 传输层:为应用层实体提供端到端的通信/传输功能,确保数据包的按顺序传送及数据的完整性. 网络层:处理网络上流动的数据包,它所包含的协议涉及到数据包在整个网络上的逻辑传输. 链路层:监控数据交换,处理网络连接的硬件部分. TCP/IP通信传输流如下图所示: HTTP在各层的封装处理: 与HTTP协

正如你看到的,Nancy有两个主要用途. 其中第一项是作为一种通用的基于 REST 框架,可替代 ASP.NET Web API 或其他Rest工具包. 默认情况下,Nancy提供一流的路由和内容协商机制,你在接下来的章节会了解更多.它不只是提供Rest节点,然而,大一部分是它的易用性,让大家更加乐于使用. 许多工具包都声称实现了Rest标准,而实际上它们没有,至少不是正式的W3C标准.虽然未能完全实现REST不是个问题,但是我们也不能贬抑那些符合 W3C 标准的方式. 下面的代码遵循 W3C

本文描述Web API实现内容协商(content negotiation). The HTTP specification (RFC 2616) defines content negotiation as "the process of selecting the best representation for a given response when there are multiple representations available." HTTP中内容协商机制是由以下请求

图解HTTP1.4.2确保可靠性的HTTP协议    按层次分,TCP位于传输层,提供可靠的字节流服务    所谓字节流服务,指为了方便传输,将大块数据分割成以报文为单位的数据包进行管理,而可靠的传输服务是指,能够把数据准确可靠的传给对方.    即TCP协议为了更加容易传送大数据才把数据分割,而且TCP协议能够确认数据最终是否送达到对方    为了确认无误地将数据送达目标处,TCP协议采用三次握手策略.握手过程使用了TCP的标志位,SYN(synchronize)和ACK(acknowledg

请求首部字段 定义:请求首部字段是从客户端到服务器发送请求报文中所使用的字段,里面包含了附加信息.客户端信息以及对响应内容相关的优先级等内容 1.Accept 通知服务器用户代理可处理的媒体类型及媒体类型的相对优先级,可使用type/subtype这种形式,一次指定多种媒体类型 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 q表示权重,默认值为1.0,当服务器提供多种内容时,将会有优先返回权重值最高

WebApi框架中对资源的操作,都是通过其Controller提供的各种方法(GET,POST,PUT,DELET等)来实现,而这些方法的返回信息有以下几种形式: 方法返回类型 HttpResponseMessage void StateCode:204(No Content) HttpResponseMessage 直接返回HttpResponseMessage IHttpActionResult 调用ExecuteAsync方法去创建一个HttpResponseMessage 对象,让后将这

HTTP/1.1与HTTP/1.0的区别 下面主要从几个不同的方面介绍HTTP/1.0与HTTP/1.1之间的差别,当然,更多的内容是放在解释这种差异背后的机制上. 1 可扩展性 可扩展性的一个重要原则:如果HTTP的某个实现接收到了自身未定义的头域,将自动忽略它. Ø  在消息中增加版本号,用于兼容性判断.注意,版本号只能用来判断逐段(hop-by-hop)的兼容性,而无法判断端到端(end-to-end)的兼容性.例如,一台HTTP/1.1的源服务器从使用HTTP/1.1的Proxy那儿接收

HTTP协议及其请求头分析 HTTP协议及其请求头分析   众所周知,Internet的基本协议是TCP/IP协议,目前广泛采用的FTP.Archie Gopher等是建立在TCP/IP协议之上的应用层协议,不同的协议对应着不同的应用.  WWW服务器使用的主要协议是HTTP协议,即超文体传输协议.由于HTTP协议支持的服务不限于WWW,还可以是其它服务,因而HTTP协议允许用 户在统一的界面下,采用不同的协议访问不同的服务,如FTP.Archie.SMTP.NNTP等.另外,HTTP协议还可用

  众所周知,Internet的基本协议是TCP/IP协议,目前广泛采用的FTP.Archie Gopher等是建立在TCP/IP协议之上的应用层协议,不同的协议对应着不同的应用.  WWW服务器使用的主要协议是HTTP协议,即超文体传输协议.由于HTTP协议支持的服务不限于WWW,还可以是其它服务,因而HTTP协议允许用 户在统一的界面下,采用不同的协议访问不同的服务,如FTP.Archie.SMTP.NNTP等.另外,HTTP协议还可用于名字服务器和分布式对象管 理.  HTTP的早期版本为

REST API Design Guidelines V 1.0.201208 Draft 5 Last Updated: 08/31/2012 1       简介 本文档旨在规范REST API的设计和开发. 1.1      REST API目标 REST API允许Newegg内部和外部开发人员通过编程方式访问Newegg系统的各种对象与资源. REST API需最大限度地满足平台无关性. 2       REST基本原则 REST全称“Representational State Tr

有这么一段配置文件 gzip on # 默认值: gzip off # 开启或者关闭gzip模块 gzip_static off; # nginx对于静态文件的处理模块 # 该模块可以读取预先压缩的gz文件,这样可以减少每次请求进行gzip压缩的CPU资源消耗.该模块启用后,nginx首先检查是否存在请求静态文件的gz结尾的文件,如果有则直接返回该gz文件内容.为了要兼容不支持gzip的浏览器,启用gzip_static模块就必须同时保留原始静态文件和gz文件.这样的话,在有大量静态文件的情况下