作者：王文君,李建蒙
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Web应用安全威胁与防治——基于OWASP Top 10与ESAPI试读：
安全技术大系
Web应用安全威胁与防治
——基于OWASP Top 10与ESAPI
CIP号：第257964号
ISBN：978-7-121-18857-2
中图分类：TP393.408
关键词：互联网络-安全技术
北京,2013/01,电子工业出版社
版次：1
印次：1
价格：69.00
印数：4000册
印张：30
字数：600
开本：787×980 1/16
语种：中文摘要
本书是一本讲解Web应用中最常见的安全风险以及解决方案的实用教材。它以当今公认的安全权威机构OWASP（Open Web Application Security Project）制定的OWASP Top 10为蓝本，介绍了十项最严重的Web应用程序安全风险，并利用ESAPI（Enterprise Security API）提出了解决方案。本书共有五篇，第1篇通过几个故事引领读者进入安全的世界；第2篇是基础知识篇，读者可以了解基本的Web应用安全的技术和知识；第3篇介绍了常用的安全测试和扫描工具；第4篇介绍了各种威胁以及测试和解决方案；第5篇在前几篇的基础上，总结在设计和编码过程中的安全原则。
本书各章以一个生动的小故事或者实例开头，让读者快速了解其中的安全问题，然后分析其产生的原因和测试方法并提出有效的解决方案，最后列出处理相关问题的检查列表，帮助读者在以后的工作和学习中更好地理解和处理类似的问题。读完本书之后，相信读者可以将学过的内容应用到Web应用安全设计、开发、测试中，提高Web应用程序的安全，也可以很有信心地向客户熟练地讲解Web应用安全威胁和攻防，并在自己的事业发展中有更多的收获。
本书适用于Web开发人员、设计人员、测试人员、架构师、项目经理、安全咨询顾问等。本书也可以作为对Web应用安全有兴趣的高校学生的教材，是一本实用的讲解Web应用安全的教材和使用手册。王文君 编著李建蒙 编著贾莉 责任编辑毕宁 其他贡献者侯士卿 封面设计序1
随着社交网络、微博等一系列新型的互联网产品的诞生，尤其是Web 2.0技术的推广，基于Web环境的面向普通终端用户的互联网应用越来越广泛。在企业界，随着企业信息化的不断深入，各种服务于企业的应用都架设在Web平台上。Web业务的迅速发展把越来越多的个人和企业的敏感数据通过Web展现给用户。这引起黑客们的强烈关注，他们跃跃欲试，利用网站操作系统的漏洞和Web服务程序的SQL注入等漏洞得到Web服务器的控制权限，轻则篡改网页内容，重则窃取重要内部数据。更为严重的则是在网页中植入恶意代码，使得网站访问者受到侵害。这些也使得越来越多的用户关注应用层的安全问题，业界对Web应用安全的关注度也逐渐升温。
目前很多业务都依赖于互联网，如网上银行、网络购物、网游等，很多恶意攻击者会对Web服务器进行攻击，想方设法通过各种手段获取他人的个人账户信息以谋取利益。正是因为这样，Web业务平台非常容易遭受攻击。为了防止黑客的攻击，除了对Web服务器做相应的配置外，Web应用程序的设计和开发也需要杜绝黑客攻击的隐患。本书有针对性地面向广大Web应用程序员提供了系统的安全设计原则和编程技巧。
作为应用程序员，你可能非常熟悉你所负责的业务逻辑，你也一定精通几种编程语言和数据库。但是，就我所接触的程序员来说，很少有懂得怎样在编程中避免留下安全漏洞的。对于产品架构师，很多产品在其设计之时没有考虑系统的安全问题，没有相应的安全标准。请仔细阅读本书，本书为你的Web产品提供了一个可行的安全标准，同时也为你提供了系统的针对各种安全漏洞的行之有效的编程技巧。
作者之一的王文君是我领导的惠普软件PPM产品研发团队的安全架构师。他将OWASP Top 10应用于PPM，使之成为该企业级产品的安全标准。事实证明，OWASP Top 10及相应的ESAPI有效地满足了用户对该产品安全方面的苛刻要求。不久前，我们的产品通过了我们的客户之一某国国防部的安全攻击测试。所以，我极力将本书推荐给你。你将会有针对性地在你的程序里满足安全性要求，对于潜在的安全隐患，你将有足够的智慧和手段去解决它。
李维纲
惠普软件部研发团队经理序2
2011年的秋天，我应邀在北京国际会议中心举行的OWASP亚洲峰会上做了《XSS检测防范技术与实例研究》演讲，在介绍存储型和反射型跨站脚本的时候，我写了下面一段小诗：
你点，或者不点，蠕虫就在那里，不增不减。
你看，或者不看，跨站就在那里，不来不去。
默然 相逢
寂静 悲怆
会后，电子工业出版社的毕宁老师找到我，问我是否能写一本关于OWASP Top 10的书籍。根据我自身的经验，现在许多IT软件公司在开发软件的时候都采用了敏捷开发，功能导向非常严重。产品经理在背后催呀催，IT开发者在前面追呀追，很多软件产品根本没有将安全作为一个验收标准，这样导致交付客户使用后，经常会发生一些安全问题，然后再进行修改，成本非常高，当时我就想，如果能写这么一本书，提高广大IT开发者、测试者的安全意识，使得在项目需求分析以及开发的时候就能将安全考虑进去，岂不是很好?于是就爽快地答应了。从北京回来以后，与也参加此次会议的李建蒙先生就这事聊了聊，一拍即合，决定由两人一起创作这本书。
本书结构
本书分5篇，读者可以通过浏览目录来了解全书的大体纲要。
第1篇引子，在这篇里，读者通过阅读4个小故事，可以对常见的网络安全事件有个基本了解，增强从事IT事业的自豪感，甚至可以学着做出我们IT人员的“禅师体”，在笑声中搞定小清新。
第2篇基础篇，万丈高楼平地起，这篇主要介绍了一些最基本的Web应用技术的概念，如http、https、Cookie、Session等，以及一些OWASP的基本知识，如风险评估、Top 10、ESAPI等。
第3篇工具篇，工欲善其事，必先利其器，从事IT安全行业，没有一些得力的小工具是万万不行的。本篇介绍了最常见的Apache Web服务器、各种主流浏览器及调试工具、一些流行的渗透测试工具及扫描工具，最后介绍了一些常见的漏洞学习网站供读者进行学习试验。
第4篇攻防篇，这是本书最主要的内容，根据提出问题、分析问题和解决问题三部曲，详细而全面地介绍了OWASP Top 10，每一章的最后还附有checklist，以便读者方便地进行查询。
第5篇安全设计和编码十大原则，作为本书的结尾部分，这篇主要介绍了我们做安全设计和编码时最常见的十大原则，提纲挈领。
致谢
感谢毕宁老师，正是你的努力，本书才得以与广大读者见面，以后有机会我一定要亲自弹上一首古筝曲向你致谢。
感谢出版社参与本书编审的老师，我想对你们说，一路泥泞，只为山花灿烂。
感谢本书的另一作者李建蒙，我要告诉你，我是如此的幸运能遇到你，与你的合作真心愉快。
感谢我的经理李维纲先生，谢谢你对我的工作的理解和支持，正是你的谆谆教导让我大胆地走出去，因此我才能开阔自己的眼界，才能有本书的诞生，同时也感谢你百忙之中抽空为本书写序。
感谢我的好朋友许屹，在我有小小得意的时候，你能给我中肯的建议让我更冷静地思考，在我失意的时候，你总能出现在我的面前给我最最及时而贴切的安慰让我勇于面对。有友如此，夫复何求?
感谢HP PPM所有的同事们，正是你们如此地信任我和给我这个机会，我才有机会做这些知识积累，才有本书的面世。他们包括但不限于：陈萍、高陈、何强威、汪燕锋、任智超、方逸东、Etienne、夏琴娴、周琴、丁晨、吴留坡、吴韬青、严峰、董欢欢、任君平、赵敏、黄健、李祥青、李文锦、陆纯奇、於良伟、宋立平、黄严，等等（我这里不一一列举所有PPMer名字了）。我想到了两年前我们组去阳澄湖吃蟹的时候，我写下的那个标语：“菊黄蟹肥，阳澄农庄。巅峰之队，我为伊狂。”有的时候我一个人走在路上，想到你们每个人的欢声笑语，想到你们每个人的聪明才智，暗自佩服。我要对你们说，能和你们一起工作是我的荣幸。因为我知道，无论我做什么，我的背后都有你们给我支持。同时也感谢过去在PPM工作过的同事对我的帮助，他们包含但不限于Vikram Matharoo、Sophia Gu、Imran Tusneem、Narayan Mandaleeka、Youjin Zhu、Subir Parulekar、顾兵、Vadim Filanovsky、金央真、陆由、朱启敏、郭亚峰等。
感谢HP Software上海的领导黄晓辉、欧阳杰子、朱征宇、金卫国、蒋镒珍、谢黎等一直以来对我的关心和指导，鼓励我一直进步。
I would like to show my greatest appreciation to Tomer Gershoni，the Chief Information and Security Officer for HP Hybrid&Cloud.I can't say thank you enough for your tremendous support and help in dealing with PPM SaaS security issues.I'm looking forward to going on collaboration in the near future.
I want to express my sincere gratitude to Asaf Barkan，CTO of HP SPM product unit，for providing a very constructive suggestion and guidance to my research about Two Factor Authentication as a Service（2FAaaS），you're definitely the security expert that everyone wants to be.
感谢新浪微博的夏玉明、Success Factor的吴宇、携程旅行网的袁劲松和上海测评中心的何勇亮、网易的沈明星，你们给了我很多有用的建议，和你们聊天真是人生的一大乐事。
感谢黑客老鹰万涛、上海银基胡绍勇、金山软件程冲、上海交大施勇给本书写的书评，你们的鼓励是我继续前进的动力。
感谢OWASP中国的同仁们，正是你们提供了一个如此轻松良好的平台，我才得以有机会写作这本书，他们包含但不限于：陈亮、Rip、宋国徽、袁明坤、付奎、Neil、Ivy、刘永波、Frank、郭涛等。
感谢我的父母，正是他们含辛茹苦地将我养大，教会我做人的道理。
感谢我家里那位最可爱的王洁怡小姑娘，爸爸写书的时候很忙，不能每周都带你出去玩，你也谅解我，其实爸爸最大的希望就是你能健康快乐地成长，你永远在我内心最柔弱的地方。
最后感谢我的妻子，12年前，我们在闵科相遇，我还书生年少，你仍白衣如雪。感谢你多年如一日地对我的照顾、呵护和默默的支持。一生痴绝处，无梦回兰坪。
邮箱：shanda.wang＠gmail.com
微博：http：//weibo.com/sanderwang
Blog：http：//blog.sina.com.cn/app4sec
王文君
2012年7月于上海序3
记得和王文君先生相识还是源于2011年11月北京的OWASP的亚洲峰会，当时，我们都被邀请作为演讲和培训嘉宾，住在同一家酒店的同一层楼上，因而，得以认识。后来有一天，王文君先生联系我说：“要写一本关于安全漏洞方面的书籍，主要是提高入门人员、开发人员以及测试人员的一些安全意识和安全防范意识”。我听到之后，非常高兴。
在这么多年的安全工作中，经常遇到一些开发或者测试人员对安全方面一点也不懂，导致开发的产品问题非常多。我经常在公司内部组织一些培训，主要是培训安全开发流程，以及安全漏洞的正确的防范方法，这样做主要是为了提高公司内部员工的安全开发意识。可是，可能还有很多公司没有这方面的培训，或许还没有安全方面的意识，所以，才导致安全事件频发。不过，随着网络安全事件的发生，越来越多的公司体会到安全的重要性，开始在安全方面投入人力和物力。但是，即使投入再多，没有很好的指导和正确的方法，往往会事倍功半，甚至使得很多工作都成为徒劳。如果有一本可以提高大家安全意识，并且能够为大家提供进一步的正确的防范方法的书，那是更好了。所以，王文君先生联系我时，我非常爽快地答应了一起创作一本这方面的书籍。
花了将近半年的时间，才完成本书的编写，这个过程使得我对所涉及的知识又有了进一步的理解和升华，希望能够给读者带来安全性方面知识的丰富。
将本书献给我的母亲，是她的教导和坚持改变了我的人生，才使得我能够有这样的机会写这本书，还要感谢我的妻子，虽然她有孕在身，仍然坚持支持和鼓励我完成此书。
感谢我的好朋友新浪微博安全专家夏玉明先生，给了我不少很好的建议。最后还要感谢王文君先生，虽然在OWASP只是一面之缘，却能够想起与我一起合作完成这本书。
邮箱：jianmeng.jimmy＠gmail.com
微博：http：//weibo.com/devsecurity
李建蒙
2012年7月于合肥第1篇 引子故事一：家有一IT，如有一宝
我的爱人是做销售的，每天晚上回家都要上网填写一个系统，若不填的话会扣奖金。有一天，她还是照常填写好了，等要提交的时候，忽然出现一个对话框，如下：
可问题是，她仔细地检查了填写的日期，并没错，遂求助于我。我看了看，第一反应就是：这个提交是在客户端做校验的，那是相当不可靠的，我一定能绕过去这个验证而正确提交。于是找到了这个按钮的那段HTML代码：
并查看了Check_Form函数，函数相当长，这里就不全列举出来了，只贴几行：
但我们知道，只要是客户端进行校验的，就不靠谱。于是我用Chrome打开了这个页面，然后在Console面板上执行了下面的命令：
这里做简单的介绍，MainPanel是Frame的名字，原始页面包括了好几个Frame，然后根据id取得保存按钮这个元素，并且将onclick函数改成return true，即验证永远通过，这样就可以跳过原来客户端的Check_Form函数中那么多的return false的情况了，最后调用保存按钮的click方法进行提交。
Bingo！提交通过！于是本人也获得了一句赞语：家有一IT，如有一宝。
这个故事告诉我们——永远不要在客户端做安全检验！故事二：微博上的蠕虫
我们知道2011年6月份，新浪微博出现了一次比较大的XSS攻击事件。大量用户自动发送诸如：“郭美美事件的一些未注意到的细节”、“建党大业中穿帮的地方”、“让女人心动的100句诗歌”、“这是传说中的神仙眷侣啊”等微博和私信，并自动关注一位名为hellosamy的用户。微博用户中招后会自动向自己的粉丝发送含毒私信和微博，有人点击后会再次中毒，形成恶性循环。
如果我们仔细看一下，会发现原始的微博链接如下图所示。
如果我们对URL进行解码，就会发现这个链接其实就是：
而问题的奥妙就在于那个位于www.2kt.cn主机上的脚本t.js，它的主要代码如下：
➊ 的作用是调用Ajax发送随机消息，当然了，这里预先定义了一些吸引人眼球的消息。
➋ 的作用是follow一个特定的用户hellosamy，它的ID是➌中声明的2201270010。
➍ 的作用是向受害者的好友发私信。
➎ 的作用就是得到受害者的好友列表，它的基本思想是发送一个 GET 请求，然后分析返回的文本，按照一定的正则表达式来获得好友列表。
➏ 是主函数，就是说t.js一旦被加载，则依次触发发信息，加hellosamy为好友，并且向受害者的好友发送私信。
这个故事告诉我们——XSS问题虽然不大，但是，其影响却可以很大！所以，安全无小事！故事三：明文密码
2011年的冬天，好像来得比往年都早一些，那个时候，600万中国程序员都曾注册过的CSDN网站被黑。一瞬间，几乎所有的网站都会提醒用户修改自己的密码，因为很多时候中国用户都会用同一个密码，理由很简单：记住一个，则全部的网站都可以访问了。但这也带来了一个问题，要是你注册的10个网站，有1个网站的密码给泄露了，岂不是所有的网站密码都泄露了?
如果再仔细看这次事件，我们会发现，里面的电子邮件和密码居然都是明文的。任何稍微学过编程知识的人都知道，密码需要利用MD5进行散列以后再进行存储，虽然我们都知道有彩虹表，简单的MD5也并不安全，还需要“加盐”，但这至少比明文存储要强多了。
这个故事告诉我们——网站里的敏感信息需要加密存储。故事四：IT青年VS禅师
老禅师在微博上一直很忙，忙着给有志理科青年指导人生，其中有下面这么一段。
理科青年问禅师：“大师，我很爱我的女朋友，她也有很多优点，但是总有几个缺点让我非常讨厌，有什么方法能让她改变?”
禅师浅笑，答：“方法很简单，不过若想我教你，你需先下山为我找一张只有正面没有背面的纸回来。”
理科青年略一沉吟，掏出一个莫比乌斯带。【注】莫比乌斯带，是一种拓扑学结构，它只有一个面（表面），和一个边界。
鉴于理科青年的一句话毁掉了许多小清新，于是老禅师在自己的门外挂了一个牌子，上面写着“理科青年不得入内”。
话说有一天，一个搞IT的工科青年进来拜见老禅师。
IT青年问禅师：“大师，7年前我开始写Java程序，现在我开始写手机程序，明年老板说我们的应用要搬到SaaS平台，出来一样新东西就要学习一样新东西，我感觉做IT真的是太累了，你说咋办好?”
禅师浅笑，答：“笑着面对，不去埋怨。悠然，随心，不变应万变。你能找到内部构造改变了而外表却丝毫不变的东西吗?”
青年略一沉吟，用ESAPI（Java）写下了下面的代码：【注】上面的程序输入是＂＜script＞alert（123）＜/script＞＂，输出是＂<；script>；alert&＃x28；123&＃x29；<；&＃x2f；script>；＂，虽然不一样，但在HTML页面上显示的却是同一内容。
这个故事告诉我们——我们用ESAPI进行输出编码，除却了峥嵘，用户体验却丝毫未变。
接下来的时间里，就让我们畅游编写安全代码需要知晓的OWASP Top 10和ESAPI这个应用安全的世界吧。第2篇 基础篇
第1章 Web应用技术
第2章 OWASP第1章 Web应用技术
目前较流行的用户Web协议有超文本传输协议（Hyper Text Transport Protocol，HTTP）与用于无线的无线应用协议（Wireless Application Protocol，WAP）。HTTP对应的安全的协议是HTTPS，和无线相关的安全协议有无线传输安全协议（Wireless Transport Layer Security，WTLS）及Wi-Fi网络安全存取协议（Wi-Fi Protected Access，WPA）。
本章着重介绍HTTP/HTTPS协议的一些基本概念，为读者学习本书剩余的章节打下基础。1.1 HTTP简介
超文本传输协议（HyperText Transfer Protocol，HTTP）是互联网上应用最为广泛的一种网络协议。所有的WWW文件都必须遵守这个标准。设计HTTP最初的目的是提供一种发布和接收HTML页面的方法。
HTTP的发展是万维网协会（World Wide Web Consortium）和Internet工作小组（Internet Engineering Task Force）合作的结果，（他们）最终发布了一系列的RFC，其中最著名的就是RFC 2616[1]。
HTTP是一个客户端和服务器端请求和应答的标准（TCP）。客户端是终端用户，服务器端是网站。通过使用Web浏览器、网络爬虫或者其他工具，客户端发起一个到服务器上指定端口（默认端口为80）的HTTP请求。我们称这个客户端为用户代理（user agent）。应答的服务器上存储着一些资源，如HTML文件和图像。我们称这个应答服务器为源服务器（origin server）。在用户代理和源服务器中间可能存在多个中间层，如代理、网关，或者隧道（tunnel）。尽管TCP/IP协议是互联网上最流行的应用，HTTP协议并没有规定必须使用它和基于它支持的层。事实上，HTTP 可以在任何其他互联网协议上，或者在其他网络上实现。HTTP 只假定其下层协议提供可靠的传输，任何能够提供这种保证的协议都可以被其使用。
通常，由HTTP客户端发起一个请求，建立一个到服务器指定端口（默认是80端口，不过其他端口也可以使用）的TCP连接。HTTP服务器则在那个端口监听客户端发送过来的请求。一旦收到请求，服务器向客户端发回一个状态行，如＂HTTP/1.1 200 OK＂，和响应的消息，消息的消息体可能是请求的文件、错误消息、或者其他一些信息。
HTTP使用TCP而不是UDP的原因在于打开一个网页必须传送很多数据，而TCP协议提供传输控制、按顺序组织数据和错误纠正。具体细节请参考“TCP和UDP的不同”。在互联网或其他网络上，这并不妨碍HTTP应用在其他协议的顶端。HTTP仅仅期望可靠的传输，任何提供这种保证的协议都可以使用。
通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。
HTTP是一种通用的、不分状态（stateless）的协议，除了诸如名称服务和分布对象管理系统之类的超文本用途外，还可以通过扩展它的请求方式、错误代码和报头来完成许多任务。HTTP的一个特点是数据表示方式的典型性和可协商性允许独立于传输数据而建立系统。在1990年WWW全球信息刚刚起步的时候HTTP就得到了应用。HTTP的第一个版本叫做HTTP 0.9，是一种为互联网原始数据传输服务的简单协议。由RFC 1945定义的HTTP 1.0进一步完善了这个协议。它允许消息以类似MIME的格式传送，包括有关数据传输的维护信息和关于请求/应答的句法修正。但是，HTTP 1.0没有充分考虑到分层代理，高速缓存的作用以及对稳定连接和虚拟主机的需求。并且随着不完善的进程应用的激增，HTTP 1.0迫切需要一个新的版本，以便使两个通信应用程序能够确定彼此的真实性能。于是HTTP 1.1很快问世，RFC 2616定义了HTTP协议中一个现今被广泛使用的版本——HTTP 1.1。
HTTP也是用于用户代理之间及代理/网关到其他网络系统的通用通信协议，这样的网络系统可能由SMTP、NNTP、FTP、Gopher和WAIS协议支持。这样，HTTP允许不同的应用程序对资源进行基本的超媒体访问。
HTTP是不安全的，且攻击者通过监听和中间人攻击等手段，可以获取网站账户和敏感信息等。所以，很快又推出了HTTPS协议。1.2 HTTPS简介
超文本传输安全协议（Hypertext Transfer Protocol Secure，HTTPS）是超文本传输协议和SSL/TLS的组合，用以提供加密通信及对网络服务器身份的鉴定。HTTPS连接经常被用于万维网上的交易支付和企业信息系统中敏感信息的传输。HTTPS不应与在RFC 2660中定义的安全超文本传输协议（S-HTTP）相混。
网景在1994年创建了HTTPS，并应用在网景导航者浏览器中。最初，HTTPS是与SSL一起使用的，在SSL逐渐演变到TLS时，最新的HTTPS也由在2000年5月公布的RFC 2818正式确定下来。
HTTPS的主要思想是在不安全的网络上创建安全信道，并可在使用适当的加密套件和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护。
HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）。因此，一个到某网站的HTTPS连接可被信任，当且仅当：
1.用户相信他们的浏览器正确实现了HTTPS且安装了正确的证书颁发机构。
2.用户相信证书颁发机构仅信任合法的网站。
3.被访问的网站提供了一个有效的证书，意即它是由一个被信任的证书颁发机构签发的（大部分浏览器会对无效的证书发出警告）。
4.该证书正确地验证了被访问的网站（例如，访问https：//ww.example.com时收到了给“Example Inc.”而不是其他组织的证书）。
5.或者互联网上相关的节点是值得信任的，或者用户相信本协议的加密层（TLS或SSL）不能被窃听者破坏。
与HTTP的URL由“http：//”起始且默认使用端口80不同，HTTPS的URL由“https：//”起始且默认使用端口443。HTTPS报文中的任何东西都被加密，包括所有报头和载荷。除了可能的选择密文攻击之外，一个攻击者所能知道的只有在两者之间有一连接这一事实。虽然最近出现了SSL Beast攻击，但是，它是建立在使用老版本的SSL/TLS协议之上，利用了老版本协议的一个漏洞，如果使用最新版的安全协议，问题就自然解决了。
因为SSL在HTTP之下工作，对上层协议一无所知，所以SSL服务器只能为一个IP地址/端口组合提供一个证书。这就意味着在大部分情况下，使用 HTTPS 的同时支持基于名字的虚拟主机是不很现实的。一种叫SNI（Server Name Indication）的方案通过在加密连接创建前向服务器发送主机名解决了这一问题。Firefox 2、Opera 8和运行在WindowsVista的Internet Explorer 7都加入了对SNI的支持。1.3 URI
URI是Uniform Resource Identifier的简写，是一个用于标识某一互联网资源名称的字符串。URI 允许用户对互联网中的资源通过特定的协议进行交互操作，它包括语法和相关协议的定义。下面是几个②RFC 3986上举的例子，通过这些例子，你可以具体体会一下URI的格式：
HTTP中的URI能够表达为绝对形式或者相对于一些已知的URI的形式，这两种形式是不同的，绝对URI始终由方案名接着冒号开始。关于URI语法和语义的定义信息，可以参考RFC 2396，在这里不做详细介绍。
HTTP协议没有对URI的长度做出任何强制规定。服务器必须能够处理它们服务的任何资源的URI，且应该能够处理长度极大的URI。如果URI超过服务器处理的长度，服务器应该返回414（Request-URI too long）状态。1.3.1 URL
统一资源定位符（URL，Uniform/Universal Resource Locator的缩写）也被称为网页地址，如同在网络上的门牌，是因特网上标准的资源的地址（Address）。它最初是由蒂姆·伯纳斯·李发明，用来作为万维网的地址的。现在它已经被万维网联盟编制为因特网标准RFC 1738。URL用来通过HTTP协议定位网络资源。URL的具体格式如下：
下面是一个典型的URL：
http 是协议，www.example.com是主机名，端口是80，/usermgr/userinfo.do是路径，userid=1是查询。③
应该尽量避免在URL中使用IP地址（可以参考RFC 1900）。在作为访问资源的请求URI时，如果URL中不存在绝对路径，则它必须作为＂/＂。如果代理收到的主机名不是完整的描述的域名，则它可以增加它的域名到收到的主机名中。如果代理收到的是完整资源域名，则代理禁止修改主机名。1.3.2 URI/URL/URN
可能通过以上简单的介绍，你会对URI/URL/URN的区别仍然不是很清楚。RFC 3986中关于三者的一段介绍如下：
通过这段介绍我们可以得知：URI可被视为定位符（URL）、名称（URN）或两者兼备。统一资源名（URN）如同一个人的名称，而统一资源定位符（URL）代表一个人的住址。换言之，URN定义某事物的身份，而URL提供查找该事物的方法。
维基百科也对URI和URL以及URN做出了解释：URI是标识一个互联网资源，并指定对其进行操作或取得该资源的方法的URL，可能通过对主要访问手段的描述，也可能通过网络“位置”进行标识。例如，http：//www.wikipedia.org/这个 URL，标识一个特定资源（首页）并表示该资源的某种形式（例如，以编码字符表示的，首页的 HTML 代码）是可以通过HTTP协议从www.wikipedia.org这个网络主机获得的。URN是基于某命名空间通过名称指定资源的URI。人们可以通过URN来指出某个资源，而无须指出其位置和获得方式。资源无须是基于互联网的。例如，URN urn：isbn：0-395-36341-1 指定标识系统（即国际标准书号ISBN）和某资源在该系统中的唯一表示的URI。它可以允许人们在不指出其位置和获得方式的情况下谈论这本书。
可见，URL和URN都是URI的子集。不过，在平时的工作和生活中用的最多的是URL，也就是把 URI 和 URL 看做是一个事物。如果④你还有兴趣进一步仔细区分三者的话，可以参考RFC 3305，这个标准里描述了三者的具体关系。1.3.3 URI比较
当通过比较两个URI来判断它们是否匹配时，客户端应该对整个URI使用大小写敏感的字节对字节进行比较，除了以下例外：
● 空或者没有给出的端口号与该URI使用的默认端口号相同。
● 比较主机名必须是大小写不敏感的。
● 比较方案名必须是大小写不敏感的。
● 空绝对路径与绝对路径“/”相同。
不在“保留”和“不安全”字符集中的字符与其URL编码相同。例如，下面三个URI是相同的：
http：//example.com：80/～smith/home.html
http：//example.com/%7Esmith/home.html
http：//example.com：80/%7esmith/home.html1.4 HTTP消息
HTTP消息由从客户到服务器的请求和从服务器到客户的回答组成。
HTTP-消息=请求|回答；HTTP/1.1 消息
请求和回答的消息是用一般的消息格式RFC 822[2]来传输实体的（消息的有效载荷）。这两种消息都是由开始行、零或者更多的头域（也叫做头）、象征头结束的空行（譬如说一个只有回车字符的行）组成，有时可能会有一个信息体。
一般的消息=开始行*（消息头CRLF）CRLF[消息的内容]
开始行=请求行|状态行
为了健壮性，服务器必须在期望收到请求行的地方忽略任何接收到的空行。换句话说，如果服务器在读一条信息开始的协议流时先收到了CRLF，它必须忽略这个CRLF。一般一个有问题的HTTP 1.0客户端在POST请求后会产生额外的CRLF。在HTTP 1.1中明确描述了HTTP的请求消息既不能以CRLF开始，也不能以CRLF结束。
关于HTTP消息的消息头和消息体的定义，可以参考HTTP 1.1的标准文档RFC 2616。下面介绍几个关键属性，以帮助读者对于本书后续章节的理解。1.4.1 HTTP方法
HTTP协议规定了HTTP方法的安全特性和幂等特性，服务提供者的服务器必须为客户端提供这些特性。HTTP方法的安全性和幂等性如表1-1所示。表1-1 HTTP方法安全性和幂等性
1.4.1.1 安全方法
实现者应该意识到他们的软件扮演着用户和Internet交互的角色，也应该让用户意识到他们所做的任何操作有可能对他们自己或者其他人带来预料不到的结果。
特别地，一些惯例已经形成，如GET和HEAD方法不应该有获取资源信息以外的操作，这些方法一般都被认为是安全的。当用户被允许使用其他“非安全”方法（如POST、PUT及DELETE）时，要以特殊的方式使用（通常是按钮而不是超链接），这样可以使得用户意识到可能要负的责任（如一个按钮带来的资金交易），或者被告知正在请求的操作可能是不安全的（如某个文件将被上传或删除）。
自然，不可能保证服务器实现GET请求时不产生副作用，特别是对于一些动态资源来说，已经请求的内容可能和实际的服务器端存储的内容不一致。
1.4.1.2 幂等方法
在介绍幂等方法之前，先介绍一下幂等。
一元运算，x为某集合内的任意数，f为运算子，如果满足f（x）=f（f（x）），那么我们称f运算为具有幂等性（idempotent）。比如在实数集中，绝对值运算就是一个例子：abs（a）=abs（abs（a））。
二元运算，x为某集合内的任意数，f为运算子，如果满足f（x，x）=x，f运算的前提是两个参数都同为x，那么我们也称f运算为具有幂等性。例如，合集和交集的运算便都是幂等的。
假如在不考虑诸如错误或者过期等问题的情况下，若干次请求的副作用与单次请求相同或者根本没有副作用，那么这些请求方法就能够被视为“幂等”的。方法GET、HEAD、PUT和DELETE都是幂等的。同样根据协议的规定，方法OPTIONS和TRACE不应该有副作用，也应该是幂等的。
假如某个由若干个请求做成的请求序列，产生的结果在重复执行这个请求序列或者其中任何一个或多个请求后仍没有发生变化，则这个请求序列是“幂等”的。但是，可能出现若干个请求组成的请求序列是“非幂等”的，即使这个请求序列中所有执行的请求方法都是幂等的。例如，这个请求序列的结果依赖于某个会在下次执行这个序列的过程中被修改的变量。
假如在同样的一组资源上没有并发的操作，没有副作用的序列操作是幂等的。如果有并发的操作存在，序列操作的结果很有可能不总是相同的。例如，有个并发的操作修改了某个资源的属性，序列操作中有一个操作获得这个资源的信息，根据资源的属性做下一步操作，一旦资源的属性被修改，序列操作的整体结果会完全不同。所以，并发操作的存在会影响序列操作的幂等性。
1.4.1.3 HTTP方法
1.OPTIONS
OPTIONS方法描述了在请求URI确定的请求/应答过程中通信选项信息的请求，返回服务器针对特定资源所支持的HTTP请求方法。该方法允许客户机判断与某个资源相关的选项或者与服务器能力相关的选项，而不需要对资源采取任何操作或者发起一个对资源的获取请求。
如果OPTIONS请求包括一个实体（用来指示内容长度Content-Length或传输码Transfer-Encoding的存在），接着媒体类型应该由一个内容类型域（Content-Type）来确定。虽然目前对这样的消息体没有定义任何功能，未来HTTP的扩展可以使用OPTIONS在服务器上做更多的细节性查询。如果服务器不支持OPTIONS的这种扩展功能，可以丢弃请求消息体。
如果请求URI是一个（“*”），OPTIONS请求通常视图应用于服务器而不是特定的资源。由于服务器的通信选项取决于资源，所以“*”请求只能作为“ping”或者“no-op”。除了允许客户端测试服务器的能力外，它没有任何作用。例如，它可以用来测试一个代理是否支持HTTP1.1。如果请求URI不是一个星号（“*”），OPTIONS请求只能应用于请求资源的通信选项。
应答200应当包括表示服务器实现的和可应用于资源的可选特性，也可能包含HTTP 1.1的扩展特性。如果有响应消息体，应该还包括通信选项的信息。目前，HTTP 1.1没有规定响应消息体的格式。如果不包括响应消息体，响应消息必须包括Content-Length而且它的值是0。
OPTIONS的响应消息是不可以缓存的。
2.GET
GET 方法意味着获取由请求的URI标识的任何信息。如果请求URI引用某个数据处理过程，应该以它产生的数据作为响应消息的实体，而不是过程的源代码文本。
如果请求消息中包括If-Modified-Since、If-Unmodified-Since、If-Match、If-None-Match或者If-Range头，GET方法就变为“条件GET”。“条件GET”只传输符合条件的实体。条件GET方法试图通过允许缓冲的实体而不需要多次请求和传输客户端已经持有的数据来减少非必要的网络资源浪费。
如果GET请求中含有Range头，GET请求就变为“部分GET”，它只获取Range描述的部分。如果客户端已经持有部分信息，通过“部分GET”减少向服务器请求的信息，节约网络资源。
GET的响应消息是可以缓存的。
3.HEAD
除了服务器不能在响应消息中返回消息体，HEAD方法与GET相同。HEAD请求的响应中的HTTP头部中包含的元信息与GET请求发送的响应消息的头相同。HEAD可以用来获取实体的元信息，而不需要传输实体本身。它经常用来测试超文本传输的有效性、可用性和最近的修改。
当响应消息中包含的信息可用于更新以前的缓存的实体时，HEAD的响应消息是可缓存的。如果响应消息中的域值与当前缓冲的实体不同（如可通过Content-Length、Content-MD5、Etag或者Last-
试读结束[说明：试读内容隐藏了图片]