图解http（六）（确认访问用户身份的认证and基于http的功能追加协议、构建web内容的技术）

第8章  确认访问用户身份的认证

8.1 何为认证

http使用的认证方式：

BASIC 认证、DIGEST认证、SSL客户端认证、FormBase认证

8.2 BASIC认证

 

步骤 1: 当请求的资源需要 BASIC 认证时,服务器会随状态码 401 Authorization Required,返回带 WWW-Authenticate 首部字段的响应。该字段内包含认证的方式(BASIC) 及 Request-URI 安全域字符串(realm)。

步骤 2: 接收到状态码 401 的客户端为了通过 BASIC 认证,需要将用户 ID 及密码发送给服务器。发送的字符串内容是由用户 ID 和密码构成,两者中间以冒号(:)连接后,再经过 Base64 编码处理。

假设用户 ID 为 guest,密码是 guest,连接起来就会形成 guest:guest 这样的字符串。然后经过 Base64 编码,最后的结果即是 Z3Vlc3Q6Z3Vlc3Q=。把这串字符串写入首部字段 Authorization 后,发送请求。当用户代理为浏览器时,用户仅需输入用户 ID 和密码即可,之后,浏览器会自动完成到 Base64 编码的转换工作。

步骤 3: 接收到包含首部字段 Authorization 请求的服务器,会对认证信息的正确性进行验证。如验证通过,则返回一条包含 Request-URI 资源的响应。

BASIC 认证虽然采用 Base64 编码方式,但这不是加密处理。不需要任何附加信息即可对其解码。换言之,由于明文解码后就是用户 ID 和密码,在 HTTP 等非加密通信的线路上进行 BASIC 认证的过程中,如果被人窃听,被盗的可能性极高。

另外,除此之外想再进行一次 BASIC 认证时,一般的浏览器却无法实现认证注销操作,这也是问题之一。BASIC 认证使用上不够便捷灵活,且达不到多数 Web 网站期望的安全性等级,因此它并不常用。

8.3 DIGEST认证

 

为弥补 BASIC 认证存在的弱点,从 HTTP/1.1 起就有了 DIGEST 认证。 DIGEST 认证同样使用质询 / 响应的方式(challenge/response),但不会像 BASIC 认证那样直接发送明文密码。所谓质询响应方式是指,一开始一方会先发送认证要求给另一方,接着使用从另一方那接收到的质询码计算生成响应码。最后将响应码返回给对方进行认证的方式。

 

因为发送给对方的只是响应摘要及由质询码产生的计算结果,所以比起 BASIC 认证,密码泄露的可能性就降低了。

 

步骤 1: 请求需认证的资源时,服务器会随着状态码 401 Authorization Required,返 回带 WWW-Authenticate 首部字段的响应。该字段内包含质问响应方式认证所需的临时质询码(随机数,nonce)。首部字段 WWW-Authenticate 内必须包含 realm 和 nonce 这两个字段的信息。客户端就是依靠向服务器回送这两个值进行认证的。nonce 是一种每次随返回的 401 响应生成的任意随机字符串。该字符串通常推荐由 Base64 编码的十六进制数的组成形式,但实际内容依赖服务器的具体实现。

步骤 2: 接收到 401 状态码的客户端,返回的响应中包含 DIGEST 认证必须的首部字段 Authorization 信息。首部字段 Authorization 内必须包含 username、realm、nonce、uri 和 response 的字段信息。其中,realm和 nonce 就是之前从服务器接收到的响应中的字段。username 是 realm 限定范围内可进行认证的用户名。uri(digest-uri)即 Request-URI 的值,但考虑到经代理转发后 Request-URI 的值可能被修改,因此事先会复制一份副本保存在 uri 内。response 也可叫做 Request-Digest,存放经过 MD5 运算后的密码字符串,形成响应码。响应中其他的实体请参见第 6 章的请求首部字段 Authorization。另外,有关 Request-Digest 的计算规则较复杂,有兴趣的读者不妨深入学习一下 RFC2617。

步骤 3: 接收到包含首部字段 Authorization 请求的服务器,会确认认证信息的正确性。认证通过后则返回包含 Request-URI 资源的响应。并且这时会在首部字段 Authentication-Info 写入一些认证成功的相关信息。DIGEST 认证提供了高于 BASIC 认证的安全等级,但是和 HTTPS 的客户端认证相比仍旧很弱。DIGEST 认证提供防止密码被窃听的保护机制,但并不存在防止用户伪装的保护机制DIGEST 认证和 BASIC 认证一样,使用上不那么便捷灵活,且仍达不到多数 Web 网站对高度安全等级的追求标准。因此它的适用范围也有所受限。

8.4 SSL客户端认证

 

从使用用户 ID 和密码的认证方式方面来讲,只要二者的内容正确,即可认证是本人的行为。但如果用户 ID和密码被盗,就很有可能被第三者冒充。利用 SSL 客户端认证则可以避免该情况的发生。SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书(在 HTTPS 一章已讲解)认证,服务器可确认访问是否来自已登录的客户端。

8.4.1 SSL客户端认证的认证步骤

 

步骤 1: 接收到需要认证资源的请求,服务器会发送 Certificate Request 报文,要求客户端提供客户端证书。

步骤 2: 用户选择将发送的客户端证书后,客户端会把客户端证书信息以 Client Certificate 报文方式发送给服务器。

步骤 3: 服务器验证客户端证书验证通过后方可领取证书内客户端的公开密钥,然后开始 HTTPS 加密通信。

8.4.2 SSL 客户端认证采用双因素认证

在多数情况下,SSL 客户端认证不会仅依靠证书完成认证,一般会和基于表单认证(稍后讲解)组合形成一种双因素认证(Two-factor authentication)来使用。所谓双因素认证就是指,认证过程中不仅需要密码这一个因素,还需要申请认证者提供其他持有信息,从而作为另一个因素,与其组合使用的认证方式。换言之,第一个认证因素的 SSL 客户端证书用来认证客户端计算机,另一个认证因素的密码则用来确定这是用户本人的行为。通过双因素认证后,就可以确认是用户本人正在使用匹配正确的计算机访问服务器。

8.4.3 SSL 客户端认证必要的费用
使用 SSL 客户端认证需要用到客户端证书。而客户端证书需要支付一定费用才能使用。这里提到的费用是指,从认证机构购买客户端证书的费用,以及服务器运营者为保证自己搭建的认证机构安全运营所产生的费用。每个认证机构颁发客户端证书的费用不尽相同,平摊到一张证书上,一年费用约几万至十几万日元。服务器运营者也可以自己搭建认证机构,但要维持安全运行就会产生相应的费用。

8.5 基于表单验证

8.5.1 认证多半为基于表单认证

 

由于使用上的便利性及安全性问题,HTTP 协议标准提供的 BASIC 认证和 DIGEST 认证几乎不怎么使用。另外,SSL 客户端认证虽然具有高度的安全等级,但因为导入及维持费用等问题,还尚未普及。比如 SSH 和 FTP 协议,服务器与客户端之间的认证是合乎标准规范的,并且满足了最基本的功能需求上的安全使用级别,因此这些协议的认证可以拿来直接使用。但是对于 Web 网站的认证功能,能够满足其安全使用级别的标准规范并不存在,所以只好使用由 Web 应用程序各自实现基于表单的认证方式。不具备共同标准规范的表单认证,在每个 Web 网站上都会有各不相同的实现方式。如果是全面考虑过安全性能而实现的表单认证,那么就能够具备高度的安全等级。但在表单认证的实现中存在问题的 Web 网站也是屡见不鲜。

8.5.2 Session管理和cookie应用

 

基于表单认证的标准规范尚未有定论,一般会使用 Cookie 来管理 Session(会话)。基于表单认证本身是通过服务器端的 Web 应用,将客户端发送过来的用户 ID 和密码与之前登录过的信息做匹配来进行认证的。但鉴于 HTTP 是无状态协议,之前已认证成功的用户状态无法通过协议层面保存下来。即,无法实现状态管理,因此即使当该用户下一次继续访问,也无法区分他与其他的用户。于是我们会使用 Cookie 来管理Session,以弥补 HTTP 协议中不存在的状态管理功能。

步骤 1: 客户端把用户 ID 和密码等登录信息放入报文的实体部分,通常是以 POST 方法把请求发送给服务

器。而这时,会使用 HTTPS 通信来进行 HTML 表单画面的显示和用户输入数据的发送。
步骤 2: 服务器会发放用以识别用户的 Session ID。通过验证从客户端发送过来的登录信息进行身份认证,

然后把用户的认证状态与 Session ID 绑定后记录在服务器端。向客户端返回响应时,会在首部字段 Set-Cookie 内写入 Session ID(如 PHPSESSID=028a8c...)。你可以把 Session ID 想象成一种用以区分不同用户的等位号。然而,如果 Session ID 被第三方盗走,对方就可以伪装成你的身份进行恶意操作了。因此必须防止 SessionID 被盗,或被猜出。为了做到这点,Session ID 应使用难以推测的字符串,且服务器端也需要进行有效期的管理,保证其安全性。另外,为减轻跨站脚本攻击(XSS)造成的损失,建议事先在 Cookie 内加上 httponly 属性。

步骤 3: 客户端接收到从服务器端发来的 Session ID 后,会将其作为 Cookie 保存在本地。下次向服务器发送请求时,浏览器会自动发送 Cookie,所以 Session ID 也随之发送到服务器。服务器端可通过验证接收到的Session ID 识别用户和其认证状态。

第9章  基于http的功能追加协议

虽然 HTTP 协议既简单又简捷,但随着时代的发展,其功能使用上捉襟见肘的疲态已经凸显。本章我们将讲解基于 HTTP 新增的功能的协议。

在建立 HTTP 标准规范时,制订者主要想把 HTTP 当作传输 HTML 文档的协议。随着时代的发展,Web 的用途更具多样性,比如演化成在线购物网站、SNS(Social Networking Service,社交网络服务)、企业或组织内部的各种管理工具,等等。

HTTP 功能上的不足可通过创建一套全新的协议来弥补。可是目前基于 HTTP 的 Web 浏览器的使用环境已遍布全球,因此无法完全抛弃 HTTP。有一些新协议的规则是基于 HTTP 的,并在此基础上添加了新的功能。

9.2 消除http瓶颈的SPDY9.2.1 http的瓶颈

在 Facebook 和 Twitter 等 SNS 网站上,几乎能够实时观察到海量用户公开发布的内容,这也是一种乐趣。当几百、几千万的用户发布内容时,Web 网站为了保存这些新增内容,在很短的时间内就会发生大量的内容更新。为了尽可能实时地显示这些更新的内容,服务器上一有内容更新,就需要直接把那些内容反馈到客户端的界面上。虽然看起来挺简单的,但 HTTP 却无法妥善地处理好这项任务。使用 HTTP 协议探知服务器上是否有内容更新,就必须频繁地从客户端到服务器端进行确认。如果服务器上没有内容更新,那么就会产生徒劳的通信。若想在现有 Web 实现所需的功能,以下这些 HTTP 标准就会成为瓶颈。

i）一条连接上只可发送一个请求。i）请求只能从客户端开始。客户端不可以接收除响应以外的指令。i)

请求 / 响应首部未经压缩就发送。首部信息越多延迟越大。i）发送冗长的首部。每次互相发送相同的首部造成的浪费较多。i）可任意选择数据压缩格式。非强制压缩发送。

Ajax的解决方法

 

Ajax(Asynchronous JavaScript and XML, 异 步 JavaScript 与 XML 技术)是一种有效利用 JavaScript 和DOM(Document Object Model,文档对象模型)的操作,以达到局部 Web 页面替换加载的异步通信手段。和以前的同步通信相比,由于它只更新一部分页面,响应中传输的数据量会因此而减少,这一优点显而易见。Ajax 的核心技术是名为 XMLHttpRequest 的 API,通过 JavaScript 脚本语言的调用就能和服务器进行 HTTP通信。借由这种手段,就能从已加载完毕的 Web 页面上发起请求,只更新局部页面。而利用 Ajax 实时地从服务器获取内容,有可能会导致大量请求产生。另外,Ajax 仍未解决 HTTP 协议本身存在的问题。

 

 

Comet的解决方法

 

一旦服务器端有内容更新了,Comet 不会让请求等待,而是直接给客户端返回响应。这是一种通过延迟应答,模拟实现服务器端向客户端推送(Server Push)的功能。

通常,服务器端接收到请求,在处理完毕后就会立即返回响应,但为了实现推送功能,Comet 会先将响应置于挂起状态,当服务器端有内容更新时,再返回该响应。因此,服务器端一旦有更新,就可以立即反馈给客户端。内容上虽然可以做到实时更新,但为了保留响应,一次连接的持续时间也变长了。期间,为了维持连接会消耗更多的资源。另外,Comet 也仍未解决 HTTP 协议本身存在的问题。

SPDY的目标

 

陆续出现的 Ajax 和 Comet 等提高易用性的技术,一定程度上使 HTTP 得到了改善,但 HTTP 协议本身的限制也令人有些束手无策。为了进行根本性的改善,需要有一些协议层面上的改动。处于持续开发状态中的 SPDY 协议,正是为了在协议级别消除 HTTP 所遭遇的瓶颈。

9.2.2 SPDY的设计和功能

 

SPDY 没有完全改写 HTTP 协议,而是在 TCP/IP 的应用层与运输层之间通过新加会话层的形式运作。同时,考虑到安全性问题,SPDY 规定通信中使用 SSL。

SPDY 以会话层的形式加入,控制对数据的流动,但还是采用 HTTP 建立通信连接。因此,可照常使用HTTP 的 GET 和 POST 等方 法、Cookie 以及 HTTP 报文等。

 

使用 SPDY 后,HTTP 协议额外获得以下功能。

多路复用流

 

通过单一的 TCP 连接,可以无限制处理多个 HTTP 请求。所有请求的处理都在一条 TCP 连接上完成,因此TCP 的处理效率得到提高。

赋予请求优先级

SPDY 不仅可以无限制地并发处理请求,还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时,解决因带宽低而导致响应变慢的问题。

压缩 HTTP 首部

压缩 HTTP 请求和响应的首部。这样一来,通信产生的数据包数量和发送的字节数就更少了。

推送功能

支持服务器主动向客户端推送数据的功能。这样,服务器可直接发送数据,而不必等待客户端的请求。

服务器提示功能

服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在,因此在资源已缓存等情况下,可以避免发送不必要的请求。

9.2.3 SPDY消除web瓶颈了吗

 

希望使用 SPDY 时,Web 的内容端不必做什么特别改动,而 Web 浏览器及 Web 服务器都要为对应 SPDY做出一定程度上的改动。有好几家 Web 浏览器已经针对 SPDY 做出了相应的调整。另外,Web 服务器也进行了实验性质的应用,但把该技术导入实际的 Web 网站却进展不佳。因为 SPDY 基本上只是将单个域名( IP 地址)的通信多路复用,所以当一个 Web 网站上使用多个域名下的资源,改善效果就会受到限制。SPDY 的确是一种可有效消除 HTTP 瓶颈的技术,但很多 Web 网站存在的问题并非仅仅是由 HTTP 瓶颈所导致。对 Web 本身的速度提升,还应该从其他可细致钻研的地方入手,比如改善 Web 内容的编写方式等。

9.3 使用浏览器进行全双工通信的websocket

 

利用 Ajax 和 Comet 技术进行通信可以提升 Web 的浏览速度。但问题在于通信若使用 HTTP 协议,就无法彻底解决瓶颈问题。WebSocket 网络技术正是为解决这些问题而实现的一套新协议及 API。当时筹划将 WebSocket 作为 HTML5 标准的一部分,而现在它却逐渐变成了独立的协议标准。WebSocket通信协议在 2011 年 12 月 11 日,被 RFC 6455 - The WebSocket Protocol 定为标准。

9.3.1 websocket的设计和功能

webSocket，即web浏览器和web服务器之间全双工通信。

9.3.2 websocket协议

 

一旦 Web 服务器与客户端之间建立起 WebSocket 协议的通信连接,之后所有的通信都依靠这个专用协议进行。通信过程中可互相发送 JSON、XML、HTML 或图片等任意格式的数据。由于是建立在 HTTP 基础上的协议,因此连接的发起方仍是客户端,而一旦确立 WebSocket 通信连接,不论服务器还是客户端,任意一方都可直接向对方发送报文。

下面我们列举一下 WebSocket 协议的主要特点。

推送功能：

 

支持由服务器向客户端推送数据的推送功能。这样,服务器可直接发送数据,而不必等待客户端的请求。

减少通信量

 

只要建立起 WebSocket 连接,就希望一直保持连接状态。和 HTTP 相比,不但每次连接时的总开销减少,而且由于 WebSocket 的首部信息很小,通信量也相应减少了。为了实现 WebSocket 通信,在 HTTP 连接建立之后,需要完成一次“握手”(Handshaking)的步骤。

 

WebSocket API

JavaScript 可调用“The WebSocket API”(http://www.w3.org/TR/websockets/,由 W3C 标准制定)内提供的 WebSocket 程序接口,以实现 WebSocket 协议下全双工通信。以下为调用 WebSocket API,每 50ms 发送一次数据的实例。

var socket = new WebSocket('ws://game.example.com:12010/updates'); socket.onopen = function () {
setInterval(function() {
if (socket.bufferedAmount == 0) socket.send(getUpdateData());
}, 50); };

9.4 期盼已久的http2.0

第10章 构建web内容的技术

10.1 html

10.1.1 web内容几乎全由html构建

 

HTML(HyperText Markup Language,超文本标记语言)是为了发送 Web 上的超文本(Hypertext)而开发的标记语言。超文本是一种文档系统,可将文档中任意位置的信息与其他信息(文本或图片等)建立关联,即超链接文本。标记语言是指通过在文档的某部分穿插特别的字符串标签,用来修饰文档的语言。我们把出现在 HTML 文档内的这种特殊字符串叫做 HTML 标签(Tag)。平时我们浏览的 Web 页面几乎全是使用 HTML 写成的。由 HTML 构成的文档经过浏览器的解析、渲染后,呈现出来的结果就是 Web 页面。

10.1.2 html的版本

 

Tim Berners-Lee 提出 HTTP 概念的同时,还提出了 HTML 原型。1993 年在伊利诺伊大学的 NCSA(TheNational Center for Supercomputing Applications,国家超级计算机应用中心)发布了 Mosaic 浏览器(世界首个图形界面浏览器程序),而能够被 Mosaic 解析的 HTML,统一标准后即作为 HTML 1.0 发布。

目前的最新版本是 HTML4.01 标准,1999 年 12 月 W3C(World Wide Web Consortium)组织推荐使用这一版本。下一个版本,预计会在 2014 年左右正式推荐使用 HTML5 标准。

HTML5 标准不仅解决了浏览器之间的兼容性问题,并且可把文本作为数据对待,更容易复用,动画等效果也变得更生动。时至今日,HTML 仍存在较多悬而未决问题。有些浏览器未遵循 HTML 标准实现,或扩展自用标签等,这都反映了 HTML 的标准实际上尚未统一这一现状。

10.1.3 设计应用css

 

CSS(Cascading Style Sheets,层叠样式表)可以指定如何展现 HTML 内的各种元素,属于样式表标准之一。即使是相同的 HTML 文档,通过改变应用的 CSS,用浏览器看到的页面外观也会随之改变。CSS 的理念就是让文档的结构和设计分离,达到解耦的目的。

10.2 动态html

10.2.1 让web页面动起来的动态html

 

所谓动态 HTML(Dynamic HTML),是指使用客户端脚本语言将静态的 HTML 内容变成动态的技术的总称。鼠标单击点开的新闻、Google Maps 等可滚动的地图就用到了动态 HTML。

动态 HTML 技术是通过调用客户端脚本语言 JavaScript,实现对 HTML 的 Web 页面的动态改造。利用DOM(Document Object Model,文档对象模型)可指定欲发生动态变化的 HTML 元素。

10.2.2 更易控制html的dom

 

DOM 是用以操作 HTML 文档和 XML 文档的 API(Application Programming Interface,应用编程接口)。使用 DOM 可以将 HTML 内的元素当作对象操作,如取出元素内的字符串、改变那个 CSS 的属性等,使页面的设计发生改变。

通过调用 JavaScript 等脚本语言对 DOM 的操作,可以以更为简单的方式控制 HTML 的改变。

10.3 web应用

10.3.1 通过web提供功能的web应用

 

Web 应用是指通过 Web 功能提供的应用程序。比如购物网站、网上银行、SNS、BBS、搜索引擎和 e-learning 等。互联网(Internet)或企业内网(Intranet)上遍布各式各样的 Web 应用。

原本应用 HTTP 协议的 Web 的机制就是对客户端发来的请求,返回事前准备好的内容。可随着 Web 越来越普及,仅靠这样的做法已不足以应对所有的需求,更需要引入由程序创建 HTML 内容的做法。

类似这种由程序创建的内容称为动态内容,而事先准备好的内容称为静态内容。Web 应用则作用于动态内容之上。

10.3.2 与web服务器及程序协作的CGI

 

CGI(Common Gateway Interface,通用网关接口)是指 Web 服务器在接收到客户端发送过来的请求后转发

给程序的一组机制。在 CGI 的作用下,程序会对请求内容做出相应的动作,比如创建 HTML 等动态内容。使用 CGI 的程序叫做 CGI 程序,通常是用 Perl、PHP、Ruby 和 C 等编程语言编写而成。

10.3.3 因java而普及的Servlet

 

Servlet 是一种能在服务器上创建动态内容的程序。Servlet是用Java语言实现的一个接口,属于面向企业级 Java(JavaEE,Java Enterprise Edition)的一部分。

之前提及的 CGI,由于每次接到请求,程序都要跟着启动一次。因此一旦访问量过大,Web 服务器要承担相

2当大的负载。而Servlet运行在与Web服务器相同的进程中,因此受到的负载较小 。Servlet的运行环境叫做 Web 容器或 Servlet 容器

Servlet作为解决CGI问题的对抗技术 ,随Java一起得到了普及。

随着 CGI 的普及,每次请求都要启动新 CGI 程序的 CGI 运行机制逐渐变成了性能瓶颈,所以之后 Servlet 和mod_perl 等可直接在 Web 服务器上运行的程序才得以开发、普及。

10.4 数据发布的格式及语言

 

XML(eXtensible Markup Language,可扩展标记语言)是一种可按应用目标进行扩展的通用标记语言。旨在通过使用 XML,使互联网数据共享变得更容易。

XML 和 HTML 都是从标准通用标记语言 SGML(Standard Generalized Markup Language)简化而成。与HTML 相比,它对数据的记录方式做了特殊处理。

下面我们以 HTML 编写的某公司的研讨会议议程为例进行说明。

<html>
<head> <title>T公司研讨会介绍</title> </head>
<body> <h1>T公司研讨会介绍</h1>
<ul>
<li>研讨会编号:TR001 <ul>
<li>Web应用程序脆弱性诊断讲座</li> </ul>
</li> <li>研讨会编号:TR002
<ul> <li>网络系统脆弱性诊断讲座</li>
</ul> </li>
</ul> </body> </html>

用浏览器打开该文档时,就会显示排列的列表内容,但如果这些数据被其他程序读取会发生什么?某些程序

虽然具备可通过识别布局特征取出文本的方法,但这份 HTML 的样式一旦改变,要读取数据内容也就变得相对困难了。可见,为了保持数据的正确读取,HTML 不适合用来记录数据结构。

接着将这份列表以 XML 的形式改写就成了以下的示例。

<研讨会 编号="TR001" 主题="Web应用程序脆弱性诊断讲座"> <类别>安全</类别> <概要>为深入研究Web应用程序脆弱性诊断必要的...</概要>
</研讨会>
<研讨会 编号="TR002" 主题="网络系统脆弱性诊断讲座">
<类别>安全</类别>
<概要>为深入研究网络系统脆弱性诊断必要的...</概要> </研讨会>

XML 和 HTML 一样,使用标签构成树形结构,并且可自定义扩展标签。

从 XML 文档中读取数据比起 HTML 更为简单。由于 XML 的结构基本上都是用标签分割而成的树形结构,因 此通过语法分析器(Parser)的解析功能解析 XML 结构并取出数据元素,可更容易地对数据进行读取。

更容易地复用数据使得 XML 在互联网上被广泛接受。比如,可用在 2 个不同的应用之间的交换数据格式化。

10.4.2 发布更新信息的 RSS/Atom

RSS(简易信息聚合,也叫聚合内容)和 Atom 都是发布新闻或博客日志等更新信息文档的格式的总称。两 者都用到了 XML。

RSS 有以下版本,名称和编写方式也不相同。
RSS 0.9(RDF Site Summary):最初的 RSS 版本。1999 年 3 月由网景通信公司自行开发用于其门户网

站。基础构图创建在初期的 RDF 规格上。
RSS 0.91(Rich Site Summary):在 RSS0.9 的基础上扩展元素,于 1999 年 7 月开发完毕。非 RDF 规

格,使用 XML 方式编写。
RSS 1.0(RDF Site Summary):RSS 规格正处于混乱状态。2000 年 12 月由 RSS-DEV 工作组再次采用

RSS0.9 中使用的 RDF 规格发布。
RSS2.0(Really Simple Syndication):非 RSS1.0 发展路线。增加支持 RSS0.91 的兼容性,2000 年

12 月由 UserLand Software 公司开发完成。 Atom 具有以下两种标准。

Atom 供稿格式(Atom Syndication Format):为发布内容而制定的网站消息来源格式,单讲 Atom 时, 就是指此标准。

Atom 出版协定(Atom Publishing Protocol):为 Web 上内容的新增或修改而制定的协议。 用于订阅博客更新信息的 RSS 阅读器,这种应用几乎支持 RSS 的所有版本以及 Atom。

<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="http://d.hatena.ne.jp/sen-u/rssxsl" type="text/xsl" media="screen"?> <rdf:RDF
xmlns="http://purl.org/rss/1.0/"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/"
xml:lang="ja">
<channel rdf:about="http://d.hatena.ne.jp/sen-u/rss">
<title>兔子的文学日记</title>
<link>http://d.hatena.ne.jp/sen-u/</link>
<description>兔子的文学日记</description>
</channel>
<item rdf:about="http://d.hatena.ne.jp/sen-u/20121215/p1"> <title>[security]提供脆弱性悬赏奖金计划的网站一览</title> <link>http://d.hatena.ne.jp/sen-u/20121215/p1</link>
<description> 正是所谓“是所谓 Bounty Programs”、处理接受Web脆弱性的相关信息,并提供奖金的计划 ...</des <dc:creator>sen-u</dc:creator>
<dc:date>2012-12-15</dc:date>
<dc:subject>security</dc:subject>
</item>

10.4.3 JavaScript 衍生的轻量级易用 JSON
JSON(JavaScript Object Notation)是一种以 JavaScript(ECMAScript)的对象表示法为基础的轻量级数据

标记语言。能够处理的数据类型有 false/null/true/ 对象 / 数组 / 数字 / 字符串,这 7 种类型。 {"name": "Web Application Security", "num": "TR001"}

JSON 让数据更轻更纯粹,并且 JSON 的字符串形式可被 JavaScript 轻易地读入。当初配合 XML 使用的 Ajax 技术也让 JSON 的应用变得更为广泛。另外,其他各种编程语言也提供丰富的库类,以达到轻便操作 JSON 的目的。

有关 JSON 更为翔实的内容请参考 RFC4627“The application/json Media Type for JavaScript Object Notation (JSON)”