标签归档:http

Play Framework框架概述

有别于其他臃肿的企业级 Java 框架,简洁的 Play 框架提供另外一种选择,它关注于开发者的效率和 RESTful 风格的架构。Play 是 敏捷软件开发的完美伴侣。

Play 框架的目标是让基于 Java 的 web 应用开发变得更加容易,让我们看一下它是怎么做到的。

没有痛苦的 Java 框架

Play 是一个纯 Java 的框架,它让你保持使用你喜欢的开发工具和类库。如果你已经是一个使用 Java 平台的开发者,

那么你不需要切换到另一种语言,其他 IDE 或者其他类库, 而仅仅是切换到一个效率更高的 Java 环境!


修改 bug 后自动重新加载

Java 平台因为较低的开发效率,已经是声名狼藉了,主要的原因就是重复和繁琐的“编译-打包-部署”的周期。

这就是为什么我们重新对这种开发周期进行了思考,并且通过 Play 让开发变得更有效率。

Play 框架自动编译 Java 源代码,然后直接热加载到 JVM 中而不需要重启服务器。你可以编辑代码,框架自动重新加载,然后直接就看到修改后的结果,就像在 LAMP 或者 Rails 环境中一样。

更有趣的是你可以根据自己的喜好,仅仅使用一个简单的文本编辑器进行开发,而不需要使用功能齐备的 Java IDE。

当有错误发生时,框架会尽最大的努力,辨别并显示出错误信息。

Play 甚至对 Java 堆栈跟踪信息进行优化,以便帮助你更容易地解决问题。看看 Java 堆栈跟踪是如何展示模板的执行过程的。


简单的无状态的 MVC 架构

想想,你在一端有一个数据库,另一端是一个浏览器,为什么非要在两者之间存在一个状态呢?

基于有状态和组件式的 Java Web 框架使我们很容易自动保存页面状态,但是这带来了很多其他问题:如果用户打开了第二个窗口时会发生什么?如果用户单击了浏览器的后退按钮呢?

PHP,Ruby on Rails 和 Django 等许多 Web 应用框架促进了 无共享(Share Nothing) 架构的发展。随着浏览器愈来愈强大,现在很容易使用 Ajax,或者离线存储去解决客户端的状态问题。

我们不再需要为了在 web 上重建一个伪造的状态而去 hack HTTP 模型。 无共享(Share Nothing) 的另一方面好处是,可以更加容易地并行地渲染页面的各个部分,更容易地是实现页面局部更新(渐进式增强)。


从 HTTP 到代码的映射

如果你使用过另外一种 Java Web 框架,例如 Servlet API 或者 Struts 框架,那么你已经看到了一个把 HTTP 协议和 Java API 以及一些奇怪的概念关联起来的抽象体系。Play 和它们想的不同,一个 Web 应用框架应该让你可以完全地直接地访问 HTTP 协议,这是 Play 和其他 Java Web 框架的一个根本性区别。

HTTP 协议,请求/响应模式,REST 架构风格, 内容类型(content-type)协商 ,统一资源标识符(URI) 都是 Play 框架涉及的主要概念。

例如,绑定一个 URI 模式到 Java 调用只需要这样一行:

  1. GET    /clients/{id}        Clients.show

如果 Ajax,REST 风格和在页面之间维护前进/后退操作,是你在日常的 web 开发工作中需要面对的问题,那么请给 Play 一个机会吧。


高效的模板引擎

我们很喜欢 JSP 和 表达式语言背后的思想,但是为什么我们需要这么多的配置文件才能创建一个标签库呢?为什么我们不能完全地访问对象模型呢? JSP 有很多的约束,这的确令人沮丧。这就是为什么我们创建了一个自定义的模板系统,灵感来自 JSP ,但是没有它的那些约束。

你,还有其他人,应该已经疲倦了写类似这样的代码:

  1. <%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
  2. <%@ taglib uri="http://java.sun.com/jsp/jstl/functions" prefix="fn" %>
  3. <c:choose>
  4.     <c:when test="${emails.unread != null && fn:size(emails.unread)}">
  5.         You have ${fn:size(emails.unread)} unread email(s)!
  6.     </c:when>
  7.     <c:otherwise>
  8.         You have no unread emails!
  9.     </c:otherwise>
  10. </c:choose>

我们认为,你一定更喜欢这样写:

  1. You have ${emails.unread ?: 'no'} ${emails.unread?.pluralize('email')} !

Play 模板引擎使用的表达式语言是 Groovy ,它的语法和 Java 一致。 Play 主要使用模板引擎来渲染 HTML 内容,不过你同样可以使用它去生成其他内容,例如 email 邮件消息,JSON 等等。


JPA 持久化

Java 持久化接口( Java Persistence API )是一个简洁的 Java 版的 ORM 框架,如果你使用过 JPA ,你会惊讶于它在 Play 框架中变得如此简单。不需要任何配置,Play 会自动启动 JPA 实体管理器,并在代码发生修改时自动地同步。

而且如果你使用 Play 提供的 play.db.jpa.Model 作为超类时,它会帮助你把代码写得更漂亮。来看一下:

  1. public void messages(int page) {
  2.     User connectedUser = User.find("byEmail", connected()).first();
  3.     List<Message> messages = Message.find(
  4.         "user = ? and read = false order by date desc",
  5.         connectedUser
  6.     ).from(page * 10).fetch(10);
  7.     render(connectedUser, messages);
  8. }

测试驱动开发(如果你喜欢)

集成的测试可以让你更容易的去进行测试驱动开发 (Test-Driven Development) ,你可以写下各种类型的测试,从简单的单元测试到完整的 acceptance 测试,然后直接在浏览器中使用 Selenium 运行测试。代码覆盖率也会被考量。


全栈的应用框架

Play 框架的最初灵感是来自于我们自己的 Java 应用。它包含了创建一个现代 Web 应用所需要的所有工具,包含:

  • 支持 JDBC 的关系数据库
  • 基于 Hibernate ( JPA 接口 ) 的对象-关系映射框架( ORM )
  • 集成的缓存支持,易用的分布式缓存系统( memcached )
  • 简单直接的提供 JSON 和 XML 的 Web Service 服务(我们说的是 真正 的 Web Services,而不是 SOAP 之类)
  • 支持使用 OpenID 进行分布式的身份认证
  • 可以将 Web 应用部署到任何地方(应用服务器,GAE ,云服务,等等)
  • 图像处理 API

Play 模块化的架构使你可以把你的 Web 应用和其他很多的模块组合起来。多亏了应用模块( application modules ),利用它你能够以一种非常简单的方式重用你的 Java 代码,模板,静态资源(如 JavaScript 和 CSS 文件)。

原文链接:http://play-framework.herokuapp.com/zh/overview

【编辑推荐】

  1. Play Framework hotswap及源码分析
  2. Play Framework总结性介绍
  3. Play Framework 2.0 RC1发布 Java Web框架
  4. Play Framework介绍:Hello World
  5. Play Framework介绍:主要概念

从0开始学编程(9) – css、html和js简便工具

前面学习了php相关知识,了解html知识,并且简单介绍了数据库概念,但是这些相关知识对于一个熟练的开发人员应该是比较简单的了, 但是对于一个刚刚学习编程的人员可能还是比较模糊,更不能深入了解技术的内涵。

今天介绍一个实用的相关知识可以让开发人员避免学习繁琐的html、css、js等知识。

注意,这个仅仅是对初学者的一个帮助工具, 正在初学阶段是可以这么看的, 但是随着项目的开展这些还是远远不够的, 学习者必须在未来努力掌握html,js以及css的简单概念。

这个技术就是bootstrap,相关简单介绍见下面的文章。

http://www.iigrowing.cn/bootstrap-jian-jie.html

1. 文章中介绍了相关的几个网站, 网站本身是中文的, 方便读者阅读, 请读者认真阅读网站内容,不用考虑是否理解内容,仅仅需要了解网站中讲解了那些内容, 了解了就好, 这样以后项目中需要可以在到网站中查找,然后慢慢体会。

2. 文章中还介绍了基于bootstrap中布局工具, 这个工具是需要重点学习的, 这个工具可以非常方便的 让html的初学这学习网页的布局,更不用了解css等相关知识。并且bootstrap的手机的支持也非常方便。 这个自动布局的工具可以满足一般常用项目了。

3. 文中还介绍了bootstrap的form表单可视化构造工具,这个工具同上面的布局一样是需要重点研究学习的。

有了上面两个可视化工具可以大大方便大家进行html的个开发。

这些东西同php进行相互配合可以大家方便开发。

 

另外补充两个相关的学习视频,如下:

 

Bootstrap 学习视频

http://pan.baidu.com/s/1i3qkSy5

这个视频中讲解的是bootstrap的2.0版本, 同现在的3.x是有些差距的,但是还是有很好的可以供参考的价值。

这个视频要仔细阅读。

 

Css3 学习资料

http://pan.baidu.com/s/1i3qkSy5

Css3的视频我目前还没有看过, 但是还是应该有很好参考价值的。可以简单参考一下。

 

相关文章

从0开始学编程(22)-android开发环境搭建与入门教程

从0开始学编程(21)-Java网络编程入门

从0开始学编程(20)-Java线程入门

从0开始学编程(19)–java流概念入门

从0开始学编程(18)–java快速入门

从0开始学编程(17)–面向对象思想了解

从0开始学编程(16)–数据库加强

从0开始学编程(15)–总结篇-php编程强化巩固

从0开始学编程(14) – Php数据相关操作

从0开始学编程(13) Php获取form表单数据

从0开始学编程(12) 使用 eclipse的 php插件单步调试php程序

从0开始学编程(11) 使用 eclipse的 php插件 调试php程序

从0开始学编程(10) 用例子学习bootstrap的布局

从0开始学编程(9) – css、html和js简便工具

从0开始学编程(8) – 数据库简介

从0开始学编程(7) – 常用网站介绍

从0开始学编程(6)–在多了解一下php都涉及些啥东西

从0开始学编程(5)–方便的php编辑工具notepad++

从0开始学编程(4)–html基础入门

从0开始学编程(3)–学习必备的基础技能

从0开始学编程(2)–学习的方法和目标

从0开始学编程(1)–xampp配置php学习环境

HTTPS介绍

来源:互联网

2.1 HTTPS介绍

先来看HTTPS的概念

wps_clip_image-18181[3][1]

我们一般的http走的是80端口,而https走的是443端口,有什么不一样的地方吗?

很简单,我们拿个telnet命令来作个实验:

telnet127.0.0.1 80,直接就登进了80端口(如果你机器上的Apache开放的话),这样好极了,所有的http中的get, put, post全部可以被我们截获,你的上网帐号,你提交的表单信息全部被别人拦截,就算你对一些信息加了密,对于黑客来说,这些加密被解密只是时间问题,而且一般黑客可以利用云计算,群集计算对你的加密可以进行“硬杀伤”,即穷举算法,利用超大规模集群解密的你的算法会很快,电影里的几十秒解开一个128位的加密不是神话,是真的!!!

因此,我们要让黑客一开始就攻不进来,连门都进不来,何谈拿到我里面的东西,对不对?

wps_clip_image-11259[3][1]

现在我们把我的http通道,变成了https,同时关闭80端口,因此用用户要访问必须经过443端口。好了,我们再来用:

telnet localhost 443

你连telnet都进不进去,因此,你就无法再获取http通道内传输的东西了。因此黑客要进入你的网站先要突破这个https,而https使用的是RSA非对称128位加密,如果是安全交易类甚至会使用RSA 1024位加密算法,除非是世界上最高明的黑客才能突破我们的防线。

2.2 HTTPS的构成

要构成HTTPS,我们需要有一张“根证书”,一张“服务器认证”才能做到一般的https,HTTPS还分成“双向认证”,在双向认证的结构中我们需要3张证书即“根证书”,“服务器认证”,“客户端认证”。为什么需要这么多证书?嘿嘿,下面我们来看HTTPS是怎么构成这个“信任关系链”的。

wps_clip_image-18926[3][1]

ü   证书我们称为CA;

ü   根证书叫Root CA;

上述这个图什么意思?

首先,RootCA是全球的根,这个“树”的根是全球任何IE、FireFox、Safari里的证书库里都有这个RootCA的,因为它们是权威,所以全球的电子证书拿它们做“根”,这些证书比较具有代表性的是:

ü   Verisign

ü   RSA

这两家公司是世界上所有加密算法的“鼻祖”,因此被拜为全球所信任,我们可以在我们的IE中看到这些“根”。

wps_clip_image-27650[3][1]

其此,全球的计算器客户默认在装完系统后,都会带有这些ROOT CA,因此“由ROOT CA签出来的服务器证书将自动被客户端所信任”。

所以,这个信任关系,就此建立。

在HTTPS是SSL的一种,它们间是如何进行加密传输的呢,就是这个“信任关系”,先建立起信任关系,然后再开始数据传输,在加密的世界中“建立信任”就需要用到至少2张证书,即ROOT CA, SERVER CA,我们把这个信任建立的过程称为“Hands Shake”,握手协议。

前面说到了,这个握手分单向和双向,包括上述这个图就是一个单向握手,什么叫单向,什么叫双向呢?我们下面来讲解:

ü   单向握手信任

我们又称它为“包二奶协议”,大家想一下,贪官包二奶和二奶说“你跟着我,我每月给你1万块”,他说的这个话,能不能写下来? 能吗? 当然不能,写下来还得了,将来二奶一不爽把这份白纸黑字的东西交到中纪委还不把这烂货给双规了哈?

所以,二奶单向里信任贪官,这就是二奶协议,即客户端认为我访问的这台服务器“是安全的”,因此客户端可以向服务器发送和提交任何东西。

ü   双向握手信任

我们又称它为“君子协定”,呵呵,从这个词表面上来看就知道这个协议有多牢靠了,首先,它是写在字面上的,其次,双方都签署协议这个信任关系怎么样啊? 非常牢靠!

即客户端信任服务器,因此客户端可以向服务器发送和提交任何东西。同时,服务器也信任客户端,允许该客户端向我发送和提交东西。

wps_clip_image-30195[3][1]

客户端单向信任服务器很简单,只要这个服务器是我客户端信任的顶级根签发出来的证书就行,而服务器如何信任客户端呢?记住下面三句话:

首先,你这个客户端到我这边来登记一下;

其次,我给你签一张证书,你带回家装在你的IE里;

最后,每次访问时因为你的IE里装着我服务器签出的证书,所以你是我的会员,所以我信任你;

2.3 证书与如何生成证书的基本概念

通过上面的概念,我们知道了,如果建立起这个HTTPS的环境我们需要至少一张服务器证书,对不对?而且这张服务器证书是需要由客户端信任的“ROOT”级机构所签发出来的。

所以一般生成证书由以下几个步骤构成:

1.       生成一对不对称密钥,即公钥public key和私钥 private key

2.       用密钥产生请求,同时把我的请求交给ROOT机构

3.       ROOT机构对我提交的请求进行“签名”Sign

这个被签完名后的“请求”就称为证书。

上面多出来了密钥,公钥,私钥三个名词,下面来做解释。

先来看一个真理:

1)密钥,密钥为一对,即一把公钥,一把私钥

2)一把私钥可以对应多把公钥,而这些公钥只可能来源于一把私钥

3)公钥加密,私钥解密

大家想一下,公钥加密,这是“公”就是人人有这把KEY,都可以用来加密,但是能打开我这扇门的因该只有一个人是吧?这就是为什么说“私钥”解密。

wps_clip_image-23684[3][1]

倒过来

私钥“加密”(被称为签名),公钥“解密”(被称为认证)

wps_clip_image-29953[3][1]

把上面这个“真理”倒过来,呵呵,好玩了,因为public key只能用来加密而解密必须是private key,因此公钥是不能加密的,公钥也不能用来解密,那么它们该怎么做?

HP公司是卖打印机的,它有100个代理,都为它销售打印机。

客户来到了某个代理公司,问:你凭什么说你是HP的代理

代理公司说:请看,这是HP公司给我证书

客户问:你的证书不能伪造吗?

代理公司答:请看,下面有一个防伪条形码

于是,客户把这个防伪条形码用手机拍下来,来到HP公司说:这是不是你们的代理?

HP公司说:你等一下! 随后HP公司拿出以前给这家代理公司的公钥,对这个签名做一个“解密”(被称为杂凑算法),也算出来一个防伪条形码,然后拿这个防伪条形码和客户带来的防伪条形码一比较,完全一致,所以HP和客户说:您可以完全相信这家公司,这家公司是我代理的。

这边这个防伪条形码就是代理公司用HP在颁发证书时给它时用HP的私钥的“签名”;

HP公司用为当初给代理商发放证书时同时生成的密钥对里的公钥对这个签个名做一个杂凑算法,然后拿算出来的防伪条形码再和客户带来的这个防伪条形码比对的这个过程被称为“认证”;

一起来看看证书里的防伪条形码吧

wps_clip_image-5802[3][1]

我们把它称为电子“指纹”,一般用的是SHA或者是MD5算法,因为MD5和SHA是不可逆唯一性算法,所以把它比喻成“指纹”再恰当不过了。

2.4 实际开发实验中如何产生证书

实际产生证书时,我们需要生成请求,但不是说我们把请求交给Verisign或者一些信息机构,它们就帮我们签的,这是要收费的,一般签个名:50-500美金不等,有时还分为每年必须去签一次,要不然就会失效。

所以我们在实际开发环境中,为了做实验或者是搭建模拟环境,不可能会去花钱买个证书的,有时我们环境要搭建几套,怎么办?这钱花的没有明堂的。

所以,在实际开发环境中,我们自己来模拟这个ROOTCA,然后用自己模拟出来的ROOTCA去签我们服务器的证书,这个过程就被称为“自签”。

2.5 使用OpenSSL来签证书

OpenSSL就是这么一个自签,加密的命令行工具,它是从UNIX下分离出来的一个项目,但也有FOR WINDOWS平台的,比如说我给你们用的这个OPENSSL,就是For WIN的,但是由于它是从UNIX/LINUX下产生的,因此它内部的配置还是用的是LINUX/UNIX的盘符与路径,需要手动去校正,当然我已经做好了校正,因此直接打了个压缩包放在了FTP上,大家拿下来后解压后就可以直接用了。

如果你们是自己从网上官方网站下载的OPENSSL需要手动去改它的盘符和路径,要不然是用不起来的。

ü   设置环境变量

wps_clip_image-16705[3][1]

把c:\openssl\bin\openssl.cnf设成OPENSSL_CONF这样的一个变量,同时把c:\openssl\bin目录加到你的path里去(根据你们自己的解压后的openssl的实际路径)。

ü   生成根证书所用的密钥

wps_clip_image-24567[3][1]

提示输入密码我们使用:aaaaaa

再次输入确认密码

(密钥,由其是private key是由口令保护的)

去除CA密钥的口令

wps_clip_image-212[3][1]

为什么我们要把好好的口令保护给去除呢?这边不是去除而是代表这个证书在被应用程序启动时不需要显示的提示用户输入口令,要不然我们会出现下面这种情况:

在启动HTTPS协议的服务器时,一般我们点一下service->apache2.x启动,就启动了,但如果这个https所带的证书是没有经过上述这道手续后处理的话,这个服务在启动时会失败,而需要切换成手动命令行启动,就是黑屏!在黑屏状态下,apache2.x服务器启动时会提示你要求:输入口令,这个太麻烦了,一般启动服务器服务的一定是超级管理员,因此一般情况下没必要在启动相关服务时再输入一遍口令了。

ü   生成CA即ROOT CA证书并自签

wps_clip_image-24050[3][1]

网上有很多说法,说是先产生CA的Request请求,再用ca.key去自签,我给大家介绍一条一步到位的产生ca ROOT证书的命令,为了安全,我们在最后加上“-configC:\openssl\bin\openssl.cnf”,以使openssl工具可以找到相应的config文件(有些系统在指定了OPENSSL_CONF环境变量后一般就不需要在命令行里去手工指定这个-config变量了)。

由于我们产生的证书为:X509格式,因此需要按照X509格式填入相关的值。

²  AU-国家家的缩写,如:CHINA=CN,美国=USA,英国=UK,日本=JP

²  State or Province Name-省/洲的缩写或者是全称,如:上海=SH

²  Locality Name-城市的全称或者是缩写,如:上海=SH

²  Organization Name-公司名,如:Cognizant

²  Common Name-要安装这台证书的主机名,证书是和主机名绑定的,如果证书里的主机名和你实际的主机名不符,这张证书就是非法的证书。

我们不能够填IP,一定一定要填主机名即域名www.xxx.com这样的东西,比如说我填的是shnlap93,但我的主机怎么知道shnlap93是指:10.225.106.35或者说是指localhost这台机器呢?

打开C:\Windows\System32\drivers\etc\hosts这个文件,如下:

localhost shnlap93

10.225.106.35 shnlap93

看到了吧?所以当我们使用pint shnlap93时,它是不是就可以知道shnlap93=10.225.106.35啦?

EmailAddress-邮件地址,爱填不填,可以跳过,反正我们是“自签”。

wps_clip_image-9063[3][1]

Look,我们的CA证书生成了,可以双击这张证书,查看信息后关闭它。

目前这张ROOT 证书,只是个自签的产品,因为是自签,一般其它客户端的IE里因此是不会带有这张根证书的。

要其实客户端也能信任这张根证书,我们必须怎么办?

将它安装到我们的IE的信任域里。

ü   将ROOT CA导入客户端的根级信任域,有多少台客户端,每个客户端都要导一边这个证书!

所以说如果我们拥有世界级的根证书该多好啊,电脑上默认就带有我们的证书,因此知道这帮世界级的根证书机构为什么能挣钱了吧?50-500美金签张证书,几秒钟的事,CALL!!!

wps_clip_image-10447[3][1]

点[导入]按钮

wps_clip_image-4782[3][1]

下一步,下一步,此时会有一个弹出框,选“yes(是)”完成导入。

再来打开我们的ca.crt文件

wps_clip_image-13435[3][1]

发现了没有,这张证书是有效的证书了,所以在“证书信息”前原有的一个红叉叉,消失了。

ü   生成Web服务器端证书密钥

我们的root证书有了,现在可以生成Web服务器端的证书了,并且用root ca去签名

wps_clip_image-1991[3][1]

先生成密钥,密码6个a

wps_clip_image-7924[3][1]

去除密码(提示:enter pass phrase for server.key时输入刚才生成密钥时的密码即6个a。

ü   生成Web服务器端证书的签名请求

wps_clip_image-13483[3][1]

生成服务器端证书请求时需要输入server端key的口令,我们为了方便,也用6个a。

ü   用Root CA去对Web服务器的证书请求即csr(certificate request)进行签名认证

wps_clip_image-30335[3][1]

输入y并回车

此时它会提示:

1 out of 1certificate requests certified, commit? [y/n],再 输入y并回车

wps_clip_image-10763[3][1]

Web服务器的server.crt证书生成完毕。

注:

如果在操作时有任何错,必须连同生成的.key,.csr, .crt文件全部删除重头来一遍

我们来看看,这个server.crt文件,双击它。

wps_clip_image-24188[3][1]

首先,我们看到该证书的“证书信息”前没有红色的大叉,然后是证书信息正是我们刚才输入的内容,为什么没有大叉?

因为我们的RootCA根证书装在我们IE的根级信任域里,又因为我们的客户端信任我们的RootCA,因此当我们的客户端打开由RootCA签出来的server.crt时,这根“信任链”被建立了起来,所以客户端自动单向信任我们的server.crt,对不对?

下面我们来做一个实验,把我们的Root CA从我们的根级信任域中删除。

wps_clip_image-25944[3][1]

选中这个shnlap93的根级证书,点[删除],会弹出两次确认框,选“yes”确认删除掉它。

关闭IE,然后我们再次双击我们的server.crt文件,来查看证书内容。

wps_clip_image-28647[3][1]

我们看到了什么?“不能验证该证书。

重新导入我们的Root CA至IE的根级信任域(见将ROOT CA导入客户端的根级信任域)。

再次打开server.crt查看证书内容。

wps_clip_image-4036[3][1]

一切回复正常了。

2.6 为Apache HttpServer布署https协议

ü   用文本编辑器打开httpd.conf文件,找到如下这一行

#Include conf/extra/httpd-ssl.conf

这行默认是被注释掉的,因此请把它放开,修改成如下

Include conf/extra/httpd-ssl.conf

ü   打开D:\tools\httpd\conf\extra\里的httpd-ssl.conf文件

在开头处添加如下这一行语句

#

# This is the Apache server configuration file providing SSL support.

# It contains the configuration directives to instruct the server how to

# serve pages over an https connection. For detailing information about these

# directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html>

#

# Do NOT simply read the instructions in here without understanding

# what they do.  They're here only as hints or reminders.  If you are unsure

# consult the online docs. You have been warned.

#

LoadModule ssl_module modules/mod_ssl.so

然后找到下面这一行

SSLCertificateFile "D:/tools/httpd/

把它改成:

SSLCertificateFile "D:/tools/httpd/cert/server.crt"

再找到下面这一行

SSLCertificateKeyFile "D:/tools/httpd/

把它改成

SSLCertificateKeyFile "D:/tools/httpd/cert/server.key"

然后把我们在我们的Apache HttpServer的安装目录下手工建一个目录叫cert的目录,并把我们在前面生成的server.crt与server.key文件拷入d:\tools\httpd\cert目录内。

在httpd.conf文件中搜索“ServerName”

搜到下面这样的一句

ServerName 10.225.101.35:80

把它改成你的主机名

ServerName shnlap93:80

此处的shnlap93是你的主机名

再继续在httpd.conf文件中搜索“VirtualHost *”

搜到下面这一句

<VirtualHost *>

把它改成

<VirtualHost shnlap93:80>

在D:\tools\httpd\conf\extra\httpd-ssl.conf文件中查找

搜“VirtualHost _default_:443”

然后把位于< VirtualHost _default_:443>段内的头三行改成如下格式

²  确保你的http的发布目录在d:/www

²  确保你的HTTPS的主机名为shnlap93:443(这边的名字和生成证书里的common name必须完全一模一样连大小写都必须一样)

DocumentRoot "D:/www"

ServerName shnlap93:443

ServerAdmin admin@localhost

然后在下一个“</VirtualHost>  ”结束前,填入下面这几行语句

DirectoryIndex index.html index.htm index.jsp index.action

JkMount /*WEB-INF ajp13

JkMount /*j_spring_security_check ajp13

JkMount /*.action ajp13

JkMount /servlet/* ajp13

JkMount /*.jsp ajp13

JkMount /*.do ajp13

JkMount /*.action ajp13

JkMount /*fckeditor/editor/filemanager/connectors/*.* ajp13

JkMount /fckeditor/editor/filemanager/connectors/* ajp13

在重启我们的Apache服务前先Test Configuration一下,如果一切无误,可以重启了。

然后我们来实验一下我们的Web Server的https的效果

wps_clip_image-23234[3][1]

看到没有,这个红圈圈起来的地方,目前是正常的,显示金黄色的一把钥匙。

如果你的Root CA没有装入IE的根级信任域,此时你敲入https://shnlap93/cbbs时,你会被提示说“该证书不被任何”,然后让你点一下“确认”按钮,点完信任后能进入我们的Web应用,但是,原先应该显示“金黄色钥匙”的地方会显示一个红色的圈圈,并且当你查看证书信息时,这个地方也会显示“证书不受信任”,并且显示一个红色的大叉。

2.7 为Tomcat也布署https协议

我们的Apache HttpServer已经走https协议了,不是已经enough了吗?NO,远远不够,如果你没有用到任何App Server即tomcat/weblogic/was那么我们说我们的应用已经走https协议了,但是因为我们的架构是Web Server + App Server,因此,我们的App Server也必须走https协议。

如果只是Web Server走https协议,而App Server没有走https协议,这就叫“假https架构”,是一种极其偷赖和不负责任的做法。

概念同产生Apache的HttpServer的证书一样,只是这边的信任域有点不一样。

Web的信任域就是你的IE里的内容里的证书里的“根级信任域”,App Server的信任域是打不开也不能访问这块地方的,而且App Server的信任域格式也不是crt文件,而是.jks(javakey store的简称)。

下面来做一个tomcat的https布署。

原有ca.crt和ca.key继续有用,因为ROOT CA都是一个,而且必须一定始终是唯一的一个,对吧?

我们直接从server.jks来做起。

说JKS,这东西好玩的很,jks文件其实就是把key文件与crt文件合在一起,以java key store的格式来存储而己。

2.8 生成Tomcat的SSL证书

为Tomcat的server所在的服务器生成一个server.jks文件

很多网上的资料是拿原先的server.crt文件转成keystore文件,其实是不对的,需要单独生成一张server.jks文件。

怎么生成证书?回顾一下上文:

1) 生成KEY

2) 生成证书请求

3) 用CA签名

下面开始使用%JAVA_HOME%\bin目录下的keytool工具来产生证书

ü   生成JKS密钥对,密码使用6个a,alias代表“别名”,CN代表Common Name,必须与主机名完全一致,错了不要怪我自己负责。

keytool -genkey -alias shnlap93X509 -keyalg RSA -keysize 1024 -dname "CN=shnlap93, OU=insurance-dart, O=Cognizant, L=SH, S=SH, C=CN" -keypass aaaaaa -keystore shnlap93.jks -storepass aaaaaa

ü   生成JSK的CSR

keytool -certreq -alias shnlap93X509 -sigalg "MD5withRSA" -file shnlap93.csr -keypass aaaaaa -keystore shnlap93.jks -storepass aaaaaa

此处注意:

Alias名必须和上面一致

密码和上面一致

ü   使用openssl结合ca.crt与ca.key为jsk的csr来签名认证并产生jks格式的crt

openssl x509 -req -in shnlap93.csr -out shnlap93.crt -CA ca.crt  -CAkey ca.key -days 3650 -CAcreateserial -sha1 -trustout -CA ca.crt -CAkey ca.key -days  3650 -CAserial ca.srl -sha1 -trustout

提示yes和no时选yes

于是,我们有了一张符合jks格式的crt证书叫shnlap93.crt文件,来查看它。

wps_clip_image-32374[3][1]

证书上没有红色的大叉,因为我们的Root CA装在我们的IE的根级信任域中,OK,下面来了,生成这个JKS,就是把crt和key合在一起,来了!

ü   生成符合x509格式的jks文件

1)      将Root CA导入jks信任域

keytool -import -alias rootca -trustcacerts -file ca.crt -keystore shnlap93.jks -storepass aaaaaa

前面我说了,jks信任域是读不到IE的根级信任域的,因此要手动把ca.crt文件导入jks的信任域

wps_clip_image-14339[3][1]

1)      现在我们的shnlap93.jks文件中有两个realm(域),一个是:

²  本身的csr(产生的签书请求认证的域,还没被认证,因为认证的内容变成了shnlap93.crt文件了是不是?)

²  刚才步骤中导入的Root CA认证域

那么客户端信任Root CA没有问题,但由于server端本身的信任域还只是处于“请求被签名”的状态,那么客户端如何去信任这个jks文件呢?

答案就是:补链,补这根信任链!

keytool -import -alias  shnlap93X509 -file shnlap93.crt -keystore shnlap93.jks -storepass aaaaaa

wps_clip_image-17745[3][1]

我们不是生成过shnlap93.crt吗?把它导入jks不就是能够把原有的“正在处于请求被签名认证”这个状态改成“已经被Root CA签名认证” 了吗?对吧?

所以,我们用于布署tomcat的ssl证书的jks格式的文件shnlap93.jks已经完整了。

2.9 布署Tomcat上的Https协议

Apache HttpServer走的是443端口,Tomcat走的就是8443端口。

打开tomcat的conf目录下的server.xml,我们来找下面这一段:

<!--

<Connector executor="tomcatThreadPool"

port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

/>

-->

默认情况下,它是被由“<!--  -->”这样的标签给注释起来的,我们把它放开

<!-- enable tomcat ssl -->

<Connector executor="tomcatThreadPool"

port="8080" protocol="HTTP/1.1"

connectionTimeout="20000"

redirectPort="8443"

clientAuth="false" sslProtocol="TLS"

keystoreFile="d:/tomcat2/conf/shnlap93.jks" keystorePass="aaaaaa"

/>

²  clientAuth=”false”

如果该值为”true”就代表要启用双向认证

²  keystoreFile就是我们生成的keystore文件所在的完全路径

²  keystorePass就是我们生成keystore时的password

重启tomcat,输入https://shnlap93:8080/cbbs, 可以看到登录网页,且右上方的SSL连接信息为“金黄色的钥匙”而不是红色大叉,那么一切就成功了。

重启Apache,然后在ie地址栏输入: https://shnlap93/cbbs,用sally/abcdefg,一切成功。

注意:

当启用了https协议后,你在ie地址栏就不能再用localhost了,为什么?因为我们的证书中的CN(Common Name)填入的是主机名,如果你还用:https://localhost,那么你也能正常进入网址,只是多了几步https不被信任的警告框,并且你右上角的ssl连接信息为红色的大叉,对于这样的https连接,如果换成是购物网站,你敢信任吗?

2.10 apache https + tomcat https

²  假https

前面说过,如果你是在Apache上启用了https而没有在tomcat上启用https协议,那么我们在tomcat中布署一个servlet,含一条打印语句: System.out.println(“”+request.getScheme()),那么它将打印出来http。

²  真https

如果我们在Apache上启用了https通时在tomcat上也启用了https,那么我们如果有这样的一条语句:System.out.println(“”+request.getScheme()),它打印出来的将是:https

用tcpTrace记录nignx rewrite后转发的数据,调试wlw发布日志到wordpress的工作过程

原创文章,转载请指明出处并保留原文url地址

前面,我们安装了php的开发环境xampp, 安装了wordpress程序,然后配置了php的调试环境, 以及 用Nginx url重写及NuSphere环境调试windows live writer客户端 等文章通过这些我们基本上打造了一个可以调试的、完善的php调试程序的开发系统。

本文我们要解决的问题是:全面记录nginx的url重写(rewrite)后的数据, 以及windows live writer 在发布文章过程中都发布了那些数据,通过这些数据的分析,了解xml rpc的工作过程。

1. tcpTrace记录数据的工作原理

系统网络结构以及相关组件的配置情况如下:

wps_clip_image-4218[8][1]

存在两台服务器, 192.168.186.162和192.168.186.163

163上部署nginx程序

162上部署tcptrace、xampp、wordpress、PhpED等软件

同时修改162服务器的hosts文件如下

wps_clip_image-22917[3][1]

通过修改了hosts文件, 这样在wlw在发布文章到www.iigrowing.cn时,根据hosts文件中配置的域名, 把数据发送给163的nginx服务器, nginx服务器在内部判断url中是否存在php的调试参数, 若是没有则重写url(添加一个php的调试标志),然后通过nginx的代理功能(proxy_pass)将请求发给162服务器的9999端口, 在9999端口上tcpTrace正在接受用户请求, 接受到请求后将请求信息打印到调试窗口, 然后将请求在转发给后端的apache服务器,apache服务器将php请求转给wordpress。 WordPress在工作过程中, PhpED环境监控着php系统,当发现有请求进入时,就进入调试模式,便于我们调试程序,发现问题。

2. 关于tcptrace

http://www.pocketsoap.com/tcpTrace/

wps_clip_image-11302[3][1]

TcpTrace

I got fed up with installing Java & Apache SOAP just to get tcpTunnelGUI, so here's a native Win32 version, built using Attila (no MFC :) ). It started out as a copy of the Apache tool, but has taken on a life of its own!.

Huh, it does what ?

Basically you use it as a tunnel between your client & server. Start tcptrace.exe and up comes a dialog box asking for local port #, destination server, and destination port # (Ignore the logging options for now) Fill these in, click Ok, and wow are you going to have fun. For example if you are writing a client and testing against a remote server (say www.razorsoft.net ), you can setup

Local Port #         8080

Destination Server   www.razorsoft.net

Destination Port #   80

Now configure your client so that it thinks the server is at localhost:8080. tcpTrace will forward all the traffic from localport:8080 to the remote server (and vica versa), dumping the contents in the process. If you are hosting a server say on port 80 and want to use it, then change your server to run on port 81, and setup

Local Port #         80

Destination Server   localhost

Destination Port #   81

you can now see your incoming traffic.

It should work with all the text based IP protocols, I've been using it with SOAP (port 80) & HTTP (port 80), and I know Peter Drayton has been using it with POP3 (port 110) & SMTP (port 25

3. php数据跟踪环境的基本环境需求

a) Php环境, 选择xampp软件环境,方便安装测试。关于如何利用xampp软件安装php,参见:XAMPP安装及使用概述

b) WordPress系统安装方法参考: WORDPRESS安装

c) Phped调试环境  基于NuSphere环境调试wordpress系统

d) Windows下nginx   Windows XP下Nginx的安装与配置

e) TcpTrace,

4. 配置tcptrace并启动环境

运行tcptrace程序, 显示相关配置窗口, 按照下图进行相关配置

wps_clip_image-11052[3][1]

配置完成后, 点击ok按钮完成相关工作,并且tcptrace程序也已经启动,可以开始工作。

5修改windows下的nginx配置文件

1)进入conf目录, 打开nginx.conf文件,修改配置文件

wps_clip_image-2254[3][1]

修改图中紫色部分的配置为:9999端口, 就是tcptcace要监控的端口

2)启动windows下的nginx系统

wps_clip_image-24952[3][1]

6. 启动192.168.186.162服务器的PhpED环境

wps_clip_image-15798[4][1]

启动后,会启动php调试的监听程序, 如下图

wps_clip_image-1405[3][1]

如监听程序没有启动则需要重新配置php的调试环境

7. 配置192.168.186.162服务器

1)启动windows live writer程序, 配置成如下:

wps_clip_image-11025[3][1]

2) 用户wlw创建新blog文章

wps_clip_image-19526[3][1]

如上图, 写好文章的标题, 及内容, 然后点击发布按钮

3) 观察tcpTrace显示信息

wps_clip_image-22725[4][1]

4) 从tcptrace中记录的, 从windows live writer写出的数据如下

POST /xmlrpc.php?DBGSESSID=413693790766000002;d=1,p=1,c=0& HTTP/1.0

Host: 192.168.186.162:9999

Connection: close

Accept: */*

Accept-Language: zh-CN, en-US, en, *

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Windows Live Writer 1.0)

Content-Type: text/xml

Content-Length: 1647

<?xml version="1.0" encoding="utf-8"?>

<methodCall>

<methodName>metaWeblog.newPost</methodName>

<params>

<param>

<value>

<string>1</string>

</value>

</param>

<param>

<value>

<string>admin</string>

</value>

</param>

<param>

<value>

<string>admin</string>

</value>

</param>

<param>

<value>

<struct>

<member>

<name>title</name>

<value>

<string>tt1</string>

</value>

</member>

<member>

<name>description</name>

<value>

<string><p>content 1234567890&nbsp; </p> <p>abcdefg</p></string>

</value>

</member>

<member>

<name>mt_text_more</name>

<value>

<string />

</value>

</member>

<member>

<name>mt_keywords</name>

<value>

<string />

</value>

</member>

<member>

<name>wp_slug</name>

<value>

<string />

</value>

</member>

<member>

<name>mt_basename</name>

<value>

<string />

</value>

</member>

<member>

<name>wp_password</name>

<value>

<string />

</value>

</member>

<member>

<name>categories</name>

<value>

<array>

<data />

</array>

</value>

</member>

<member>

<name>mt_excerpt</name>

<value>

<string />

</value>

</member>

</struct>

</value>

</param>

<param>

<value>

<boolean>1</boolean>

</value>

</param>

</params>

</methodCall>

WordPress对xmp rpc调用的相应

从数据中我们可以知道一个 典型xml rpc的工作过程, 里面都是xml代码,具体内容大家慢慢分析吧, 比较简单。

5) WordPress的http相应

如下代码是 从tcptrace中获取的相关相应

HTTP/1.1 200 OK

Date: Thu, 25 Apr 2013 03:13:02 GMT

Server: Apache/2.2.14 (Win32) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l mod_autoindex_color PHP/5.3.1 mod_apreq2-20090110/2.7.1 mod_perl/2.0.4 Perl/v5.10.1

X-Powered-By: PHP/5.3.1

Set-Cookie: DBGSESSID= ; path=/; expires=Thu, 01 Jan 1970 00:00:01 GMT; version=1

Set-Cookie: DBGSESSID= ; path=/; version=1

Expires: Thu, 19 Nov 1981 08:52:00 GMT

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Connection: close

Content-Length: 161

Content-Type: text/xml

<?xml version="1.0"?>

<methodResponse>

<params>

<param>

<value>

<string>803</string>

</value>

</param>

</params>

</methodResponse>

8. 查看192.168.186.162的调试环境

由于本次主要是为了检测 xml rpc调用过程中的信息, 因此取消了调试器中的断点,因此程序没有在调试器中中断。

但是调试的日志中还是有相关的记录的如下:

wps_clip_image-12575[4][1]

只是由于没有中断运行因此我们可以不用关心相关过程。

9. 查看其他过程

另外我们也可以监控一下,windows live writer的配置过程, 如下图, 过程比较多,我们就给数据了,大家自己练习吧。

wps_clip_image-1022[4][1]

HTTP协议的头信息详解

来源:互联网

HTTP协议的头信息详解.txt10有了执著,生命旅程上的寂寞可以铺成一片蓝天;有了执著,孤单可以演绎成一排鸿雁;有了执著,欢乐可以绽放成满圆的鲜花。

HTTP协议的头信息详解

在数据挖崛方面有时候会经常分析网页内容,这时候就需要对HTTP协议有一定的了解,下边摘录了网上关于这方面的介绍

HTTP(HyperTextTransferProtocol)是超文本传输协议的缩写,它用于传送WWW方式的数据,关于HTTP 协议的详细内容请参 考RFC2616。HTTP协议采用了请求/响应模型。客户端向服务器发送一个请求,请求头包含请求的方法、URI、协议版本、以及包含请求修饰符、客户 信息和内容的类似于MIME的消息结构。服务器以一个状态行作为响应,相应的内容包括消息协议的版本,成功或者错误编码加上包含服务器信息、实体元信息以 及可能的实体内容。

通常HTTP消息包括客户机向服务器的请求消息和服务器向客户机的响应消息。这两种类型的消息由一个起始行,一个或者多个头域,一个只是头域结束的空行和可 选的消息体组成。HTTP的头域包括通用头,请求头,响应头和实体头四个部分。每个头域由一个域名,冒号(:)和域值三部分组成。域名是大小写无关的,域 值前可以添加任何数量的空格符,头域可以被扩展为多行,在每行开始处,使用至少一个空格或制表符。

通用头域

通用头 域包含请求和响应消息都支持的头域,通用头域包含Cache-Control、 Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via。对通用头域的扩展要求通讯双方都支持此扩 展,如果存在不支持的通用头域,一般将会作为实体头域处理。下面简单介绍几个在UPnP消息中使用的通用头域。

Cache-Control头域

Cache -Control指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置 Cache-Control并不会修改另一个消息处理过程中的缓存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、 max-stale、min-fresh、only-if-cached,响应消息中的指令包括public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age。各个消息中的指令含义如 下:

Public指示响应可被任何缓存区缓存。

Private指示对于单个用户的整个或部分响应消息,不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息,此响应消息对于其他用户的请求无效。

no-cache指示请求或响应消息不能缓存

no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。

max-age指示客户机可以接收生存期不大于指定时间(以秒为单位)的响应。

min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。

max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值,那么客户机可以接收超出超时期指定值之内的响应消息。

Date头域

Date头域表示消息发送的时间,时间的描述格式由rfc822定义。例如,Date:Mon,31Dec200104:25:57GMT。Date描述的时间表示世界标准时,换算成本地时间,需要知道用户所在的时区。

Pragma头域

Pragma头域用来包含实现特定的指令,最常用的是Pragma:no-cache。在HTTP/1.1协议中,它的含义和Cache- Control:no-cache相同。

请求消息

请求消息的第一行为下面的格式:

MethodSPRequest-URISPHTTP-VersionCRLFMethod 表示对于Request-URI完成的方法,这个字段是大小写敏感的,包括OPTIONS、GET、HEAD、POST、PUT、DELETE、 TRACE。方法GET和HEAD应该被所有的通用WEB服务器支持,其他所有方法的实现是可选的。GET方法取回由Request-URI标识的信息。 HEAD方法也是取回由Request-URI标识的信息,只是可以在响应时,不返回消息体。POST方法可以请求服务器接收包含在请求中的实体信息,可 以用于提交表单,向新闻组、BBS、邮件群组和数据库发送消息。

SP表示空格。Request-URI遵循URI格式,在此字段为星 号(*)时,说明请求并不用于某个特定的资源地址,而是用于服务器本身。HTTP- Version表示支持的HTTP版本,例如为HTTP/1.1。CRLF表示换行回车符。请求头域允许客户端向服务器传递关于请求或者关于客户机的附加 信息。请求头域可能包含下列字段Accept、Accept-Charset、Accept- Encoding、Accept-Language、Authorization、From、Host、If-Modified-Since、If- Match、If-None-Match、If-Range、If-Range、If-Unmodified-Since、Max-Forwards、 Proxy-Authorization、Range、Referer、User-Agent。对请求头域的扩展要求通讯双方都支持,如果存在不支持的请 求头域,一般将会作为实体头域处理。

典型的请求消息:

GET http://download.microtool.de:80/somedata.exe

Host: download.microtool.de

Accept:*/*

Pragma: no-cache

Cache-Control: no-cache

Referer: http://download.microtool.de/

User-Agent:Mozilla/4.04[en](Win95;I;Nav)

Range:bytes=554554-

上例第一行表示HTTP客户端(可能是浏览器、下载程序)通过GET方法获得指定URL下的文件。棕色的部分表示请求头域的信息,绿色的部分表示通用头部分。

Host头域

Host头域指定请求资源的Intenet主机和端口号,必须表示请求url的原始服务器或网关的位置。HTTP/1.1请求必须包含主机头域,否则系统会以400状态码返回。

Referer头域

Referer 头域允许客户端指定请求uri的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化cache等。他也允许废除的或错误的连接由于维护的目的被 追踪。如果请求的uri没有自己的uri地址,Referer不能被发送。如果指定的是部分uri地址,则此地址应该是一个相对地址。

Range头域

Range头域可以请求实体的一个或者多个子范围。例如,

表示头500个字节:bytes=0-499

表示第二个500字节:bytes=500-999

表示最后500个字节:bytes=-500

表示500字节以后的范围:bytes=500-

第一个和最后一个字节:bytes=0-0,-1

同时指定几个范围:bytes=500-600,601-999

但是服务器可以忽略此请求头,如果无条件GET包含Range请求头,响应会以状态码206(PartialContent)返回而不是以200 (OK)。

User-Agent头域

User-Agent头域的内容包含发出请求的用户信息。

响应消息

响应消息的第一行为下面的格式:

HTTP-VersionSPStatus-CodeSPReason-PhraseCRLF

HTTP -Version表示支持的HTTP版本,例如为HTTP/1.1。Status- Code是一个三个数字的结果代码。Reason-Phrase给Status-Code提供一个简单的文本描述。Status-Code主要用于机器自 动识别,Reason-Phrase主要用于帮助用户理解。Status-Code的第一个数字定义响应的类别,后两个数字没有分类的作用。第一个数字可 能取5个不同的值:

1xx:信息响应类,表示接收到请求并且继续处理

2xx:处理成功响应类,表示动作被成功接收、理解和接受

3xx:重定向响应类,为了完成指定的动作,必须接受进一步处理

4xx:客户端错误,客户请求包含语法错误或者是不能正确执行

5xx:服务端错误,服务器不能正确执行一个正确的请求

响应头域允许服务器传递不能放在状态行的附加信息,这些域主要描述服务器的信息和 Request-URI进一步的信息。响应头域包含Age、Location、Proxy-Authenticate、Public、Retry- After、Server、Vary、Warning、WWW-Authenticate。对响应头域的扩展要求通讯双方都支持,如果存在不支持的响应头 域,一般将会作为实体头域处理。

典型的响应消息:

HTTP/1.0200OK

Date:Mon,31Dec200104:25:57GMT

Server:Apache/1.3.14(Unix)

Content-type:text/html

Last-modified:Tue,17Apr200106:46:28GMT

Etag:"a030f020ac7c01:1e9f"

Content-length:39725426

Content-range:bytes554554-40279979/40279980

上例第一行表示HTTP服务端响应一个GET方法。棕色的部分表示响应头域的信息,绿色的部分表示通用头部分,红色的部分表示实体头域的信息。

Location响应头

Location响应头用于重定向接收者到一个新URI地址。

Server响应头

Server响应头包含处理请求的原始服务器的软件信息。此域能包含多个产品标识和注释,产品标识一般按照重要性排序。

实体

请求消息和响应消息都可以包含实体信息,实体信息一般由实体头域和实体组成。实体头域包含关于实体的原信息,实体头包括Allow、Content- Base、Content-Encoding、Content-Language、 Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、 Etag、Expires、Last-Modified、extension-header。extension-header允许客户端定义新的实体 头,但是这些域可能无法未接受方识别。实体可以是一个经过编码的字节流,它的编码方式由Content-Encoding或Content-Type定 义,它的长度由Content-Length或Content-Range定义。

Content-Type实体头

Content-Type实体头用于向接收方指示实体的介质类型,指定HEAD方法送到接收方的实体介质类型,或GET方法发送的请求介质类型 Content-Range实体头

Content-Range实体头用于指定整个实体中的一部分的插入位置,他也指示了整个实体的长度。在服务器向客户返回一个部分响应,它必须描述响应覆盖的范围和整个实体长度。一般格式:

Content-Range:bytes-unitSPfirst-byte-pos-last-byte-pos/entity-legth

例如,传送头500个字节次字段的形式:Content-Range:bytes0- 499/1234如果一个http消息包含此节(例如,对范围请求的响应或对一系列范围的重叠请求),Content-Range表示传送的范围, Content-Length表示实际传送的字节数。

Last-modified实体头

应答头 说明

Allow 服务器支持哪些请求方法(如GET、POST等)。

Content-Encoding 文 档的编码(Encode)方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显著地减少HTML文档的 下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩,但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此,Servlet应该通过查看Accept-Encoding头(即request.getHeader("Accept- Encoding"))检查浏览器是否支持gzip,为支持gzip的浏览器返回经gzip压缩的HTML页面,为其他浏览器返回普通页面。

Content-Length 表 示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势,可以把输出文档写入 ByteArrayOutputStram,完成后查看其大小,然后把该值放入Content-Length头,最后通过 byteArrayStream.writeTo(response.getOutputStream()发送内容。

Content-Type 表示后面的文档属于什么MIME类型。Servlet默认为text/plain,但通常需要显式地指定为text/html。由于经常要设置Content-Type,因此HttpServletResponse提供了一个专用的方法setContentTyep。

Date 当前的GMT时间。你可以用setDateHeader来设置这个头以避免转换时间格式的麻烦。

Expires 应该在什么时候认为文档已经过期,从而不再缓存它?

Last-Modified 文 档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期,该请求将被视为一个条件GET,只有改动时间迟于指定时间的文档 才会返回,否则返回一个304(Not Modified)状态。Last-Modified也可用setDateHeader方法来设置。

Location 表示客户应当到哪里去提取文档。Location通常不是直接设置的,而是通过HttpServletResponse的sendRedirect方法,该方法同时设置状态代码为302。

Refresh 表示浏览器应该在多少时间之后刷新文档,以秒计。除了刷新当前文档之外,你还可以通过setHeader("Refresh", "5; URL=http://host/path")让浏览器读取指定的页面。

注 意这种功能通常是通过设置HTML页面HEAD区的<META HTTP-EQUIV="Refresh" CONTENT="5;URL=http://host/path">实现,这是因为,自动刷新或重定向对于那些不能使用CGI或Servlet的 HTML编写者十分重要。但是,对于Servlet来说,直接设置Refresh头更加方便。

注意Refresh的意义是“N秒之后 刷新本页面或访问指定页面”,而不是“每隔N秒刷新本页面或访问指定页面”。因此,连续刷新要求每次都发送一个Refresh头,而发送204状态代码则 可以阻止浏览器继续刷新,不管是使用Refresh头还是<META HTTP-EQUIV="Refresh" ...>。

注意Refresh头不属于HTTP 1.1正式规范的一部分,而是一个扩展,但Netscape和IE都支持它。

Server 服务器名字。Servlet一般不设置这个值,而是由Web服务器自己设置。

Set-Cookie 设置和页面关联的Cookie。Servlet不应使用response.setHeader("Set-Cookie", ...),而是应使用HttpServletResponse提供的专用方法addCookie。参见下文有关Cookie设置的讨论。

WWW-Authenticate 客 户应该在Authorization头中提供什么类型的授权信息?在包含401(Unauthorized)状态行的应答中这个头是必需的。例如, response.setHeader("WWW-Authenticate", "BASIC realm=\"executives\"")。

注意Servlet一般不进行这方面的处理,而是让Web服务器的专门机制来控制受密码保护页面的访问(例如.htaccess)。

(一)初识HTTP消息头

但凡搞WEB开发的人都离不开HTTP(超文本传输协议),而要了解HTTP,除了HTML本身以外,还有一部分不可忽视的就是HTTP消息头。

做过Socket编程的人都知道,当我们设计一个通信协议时,“消息头/消息体”的分割方式是很常用的,消息头告诉对方这个消息是干什么的,消息体告诉对方怎么干。HTTP传输的消息也是这样规定的,每一个HTTP包都分为HTTP头和HTTP体两部分,后者是可选的,而前者是必须的。每当我们打开一个网页,在上面点击右键,选择“查看源文件”,这时看到的HTML代码就是HTTP的消息体,那么消息头又在哪呢?IE浏览器不让我们看到这部分,但我们可以通过截取数据包等方法看到它。

下面就来看一个简单的例子:

首先制作一个非常简单的网页,它的内容只有一行:

<html><body>hello world</body></html>

把它放到WEB服务器上,比如IIS,然后用IE浏览器请求这个页面(http://localhost:8080/simple.htm),当我们请求这个页面时,浏览器实际做了以下四项工作:

1 解析我们输入的地址,从中分解出协议名、主机名、端口、对象路径等部分,对于我们的这个地址,解析得到的结果如下:

协议名:http

主机名:localhost

端口:8080

对象路径:/simple.htm

2 把以上部分结合本机自己的信息,封装成一个HTTP请求数据包

3 使用TCP协议连接到主机的指定端口(localhost, 8080),并发送已封装好的数据包

4 等待服务器返回数据,并解析返回数据,最后显示出来

由截取到的数据包我们不难发现浏览器生成的HTTP数据包的内容如下:

GET /simple.htm HTTP/1.1<CR>

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*<CR>

Accept-Language: zh-cn<CR>

Accept-Encoding: gzip, deflate<CR>

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)<CR>

Host: localhost:8080<CR>

Connection: Keep-Alive<CR>

<CR>

为了显示清楚我把所有的回车的地方都加上了“<CR>”,注意最后还有一个空行加一个回车,这个空行正是HTTP规定的消息头和消息体的分界线,第一个空行以下的内容就是消息体,这个请求数据包是没有消息体的。

消息的第一行“GET”表示我们所使用的HTTP动作,其他可能的还有“POST”等,GET的消息没有消息体,而POST消息是有消息体的,消息体的内容就是要POST的数据。后面/simple.htm就是我们要请求的对象,之后HTTP1.1表示使用的是HTTP1.1协议。

第二行表示我们所用的浏览器能接受的Content-type,三四两行则是语言和编码信息,第五行显示出本机的相关系信息,包括浏览器类型、操作系统信息等,很多网站可以显示出你所使用的浏览器和操作系统版本,就是因为可以从这里获取到这些信息。

第六行表示我们所请求的主机和端口,第七行表示使用Keep-Alive方式,即数据传递完并不立即关闭连接。

服务器接收到这样的数据包以后会根据其内容做相应的处理,例如查找有没有“/simple.htm”这个对象,如果有,根据服务器的设置来决定如何处理,如果是HTM,则不需要什么复杂的处理,直接返回其内容即可。但在直接返回之前,还需要加上HTTP消息头。

服务器发回的完整HTTP消息如下:

HTTP/1.1 200 OK<CR>

Server: Microsoft-IIS/5.1<CR>

X-Powered-By: ASP.NET<CR>

Date: Fri, 03 Mar 2006 06:34:03 GMT<CR>

Content-Type: text/html<CR>

Accept-Ranges: bytes<CR>

Last-Modified: Fri, 03 Mar 2006 06:33:18 GMT<CR>

ETag: "5ca4f75b8c3ec61:9ee"<CR>

Content-Length: 37<CR>

<CR>

<html><body>hello world</body></html>

同样,我用“<CR>”来表示回车。可以看到,这个消息也是用空行切分成消息头和消息体两部分,消息体的部分正是我们前面写好的HTML代码。

消息头第一行“HTTP/1.1”也是表示所使用的协议,后面的“200 OK”是HTTP返回代码,200就表示操作成功,还有其他常见的如404表示对象未找到,500表示服务器错误,403表示不能浏览目录等等。

第二行表示这个服务器使用的WEB服务器软件,这里是IIS 5.1。第三行是ASP.Net的一个附加提示,没什么实际用处。第四行是处理此请求的时间。第五行就是所返回的消息的content-type,浏览器会根据它来决定如何处理消息体里面的内容,例如这里是text/html,那么浏览器就会启用HTML解析器来处理它,如果是image/jpeg,那么就会使用JPEG的解码器来处理。

消息头最后一行“Content-Length”表示消息体的长度,从空行以后的内容算起,以字节为单位,浏览器接收到它所指定的字节数的内容以后就会认为这个消息已经被完整接收了。

?

常见的HTTP返回码

在服务器返回的HTTP消息头里有一个“HTTP/1.1 200 OK”,这里的200是HTTP规定的返回代码,表示请求已经被正常处理完成。浏览器通过这个返回代码就可以知道服务器对所发请求的处理情况是什么,每一种返回代码都有自己的含义。这里列举几种常见的返回码。

1 403 Access Forbidden

如果我们试图请求服务器上一个文件夹,而在WEB服务器上这个文件夹并没有允许对这个文件夹列目录的话,就会返回这个代码。一个完整的403回复可能是这样的:(IIS5.1)

HTTP/1.1 403 Access Forbidden

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 08:57:39 GMT

Connection: close

Content-Type: text/html

Content-Length: 172

?

<html><head><title>Directory Listing Denied</title></head>

<body><h1>Directory Listing Denied</h1>This Virtual Directory does not allow contents to be listed.</body></html>

2 404 Object not found

当我们请求的对象在服务器上并不存在时,就会给出这个返回代码,这可能也是最常见的错误代码了。IIS给出的404消息内容很长,除了消息头以外还有一个完整的说明“为什么会这样”的网页。APACHE服务器的404消息比较简短,如下:

HTTP/1.1 404 Not Found

Date: Mon, 06 Mar 2006 09:03:14 GMT

Server: Apache/2.0.55 (Unix) PHP/5.0.5

Content-Length: 291

Keep-Alive: timeout=15, max=100

Connection: Keep-Alive

Content-Type: text/html; charset=iso-8859-1

?

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

<html><head>

<title>404 Not Found</title>

</head><body>

<h1>Not Found</h1>

<p>The requested URL /notexist was not found on this server.</p>

<hr>

<address>Apache/2.0.55 (Unix) PHP/5.0.5 Server at localhost Port 8080</address>

</body></html>

也许你会问,无论是404还是200,都会在消息体内给出一个说明网页,那么对于客户端来说二者有什么区别呢?一个比较明显的区别在于200是成功请求,浏览器会记录下这个地址,以便下次再访问时可以自动提示该地址,而404是失败请求,浏览器只会显示出返回的页面内容,并不会记录此地址,要再次访问时还需要输入完整的地址。

3 401 Access Denied

当WEB服务器不允许匿名访问,而我们又没有提供正确的用户名/密码时,服务器就会给出这个返回代码。在IIS中,设置IIS的安全属性为不允许匿名访问,此时直接访问的话就会得到以下返回结果:

HTTP/1.1 401 Access Denied

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 09:15:55 GMT

WWW-Authenticate: Negotiate

WWW-Authenticate: NTLM

Connection: close

Content-Length: 3964

Content-Type: text/html

?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html dir=ltr>

……

此时浏览器上让我们输入用户名和密码:

因返回信息中消息体较长,只取前面两行内容。注意,如果是用localhost来访问本机的IIS,因IE可以直接取得当前用户的身份,它会和服务器间直接进行协商,所以不会看到401提示。

当我们在输入了用户名和密码以后,服务器与客户端会再进行两次对话。首先客户端向服务器索取一个公钥,服务器端会返回一个公钥,二者都用BASE64编码,相应的消息如下(编码部分已经做了处理):

GET / HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: 192.168.0.55:8080

Connection: Keep-Alive

Authorization: Negotiate ABCDEFG……

?

HTTP/1.1 401 Access Denied

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 09:20:53 GMT

WWW-Authenticate: Negotiate HIJKLMN……

Content-Length: 3715

Content-Type: text/html

?

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html dir=ltr>

……

客户端拿到公钥之后使用公钥对用户名和密码进行加密码,然后把加密以后的结果重新发给服务器:

GET / HTTP/1.1

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: 192.168.0.55:8080

Connection: Keep-Alive

Authorization: Negotiate OPQRST……

这样,如果验证通过,服务器端就会把请求的内容发送过来了,也就是说禁止匿名访问的网站会经过三次请求才可以看到页面。但因为客户端浏览器已经缓存了公钥,用同一个浏览器窗口再次请求这个网站上的其它页面时就可以直接发送验证信息,从而一次交互就可以完成了。

4 302 Object Moved

用过ASP的人都知道ASP中页面重定向至少有Redirect和Transfer两种方法。二的区别在于Redirect是客户端重定向,而Transfer是服务器端重定向,那么它们具体是如何通过HTTP消息头实现的呢?

先来看一下Transfer的例子:

例如ASP文件1.asp只有一行

<% Server.Transfer "1.htm" %>

HTML文件1.htm也只有一行:

<p>this is 1.htm</p>

如果我们从浏览器里请求1.asp,发送的请求是:

GET /1.asp HTTP/1.1

Accept: */*

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: localhost:8080

Connection: Keep-Alive

Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP

注意请求的文件确实是1.asp,而得到的回应则是:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 12:52:44 GMT

X-Powered-By: ASP.NET

Content-Length: 20

Content-Type: text/html

Cache-control: private

?

<p>this is 1.htm</p>

不难看出,通过Server.Transfer语句服务器端已经做了页面重定向,而客户端对此一无所知,表面上看上去得到的就是1.asp的结果。

如果把1.asp的内容改为:

<% Response.Redirect "1.htm" %>

再次请求1.asp,发送的请求没有变化,得到的回应却变成了:

HTTP/1.1 302 Object moved

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 12:55:57 GMT

X-Powered-By: ASP.NET

Location: 1.htm

Content-Length: 121

Content-Type: text/html

Cache-control: private

?

<head><title>Object moved</title></head>

<body><h1>Object Moved</h1>This object may be found <a HREF="">here</a>.</body>

注意HTTP的返回代码由200变成了302,表示这是一个重定向消息,客户端需要根据消息头中Location字段的值重新发送请求,于是就有了下面一组对话:

GET /1.htm HTTP/1.1

Accept: */*

Accept-Language: zh-cn

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: localhost:8080

Connection: Keep-Alive

If-Modified-Since: Thu, 02 Mar 2006 06:50:13 GMT

If-None-Match: "b224758ec53dc61:9f0"

Cookie: ASPSESSIONIDACCTRTTT=PKKDJOPBAKMAMBNANIPIFDAP

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

X-Powered-By: ASP.NET

Date: Mon, 06 Mar 2006 12:55:57 GMT

Content-Type: text/html

Accept-Ranges: bytes

Last-Modified: Mon, 06 Mar 2006 12:52:32 GMT

ETag: "76d85bd51c41c61:9f0"

Content-Length: 20

?

<p>this is 1.htm</p>

很明显,两种重定向方式虽然看上去结果很像,但在实现原理上有很大的不同。

5 500 Internal Server Error

500号错误发生在服务器程序有错误的时候,例如,ASP程序为

<% if %>

显然这个程序并不完整,于是得到的结果为:

HTTP/1.1 500 Internal Server Error

Server: Microsoft-IIS/5.1

Date: Mon, 06 Mar 2006 12:58:55 GMT

X-Powered-By: ASP.NET

Content-Length: 4301

Content-Type: text/html

Expires: Mon, 06 Mar 2006 12:58:55 GMT

Set-Cookie: ASPSESSIONIDACCTRTTT=ALKDJOPBPPKNPCNOEPCNOOPD; path=/

Cache-control: private

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">

<html dir=ltr>

……

服务器发送了500号错误,并且后面通过HTML的方式说明了错误的原因。

理解HTTP消息头 (三)

(三) 客户端发送的内容

这一次主要来观察HTTP消息头中客户端的请求,从中找到一些有意思的内容。

?

1 HTTP_REFERER

写两个简单的网页:

a.htm:

<a href=b.htm>to page b</a>

b.htm:

haha

内容很简单,就是网页A中有一个到B的链接。把它们放到IIS上,并访问网页A,从中再点击到B的链接,于是看到了B页的“haha”。那么这两次请求有什么不同吗?观察它们所发送的HTTP消息头,最明显的区别就是访问B页时比访问A页时多了一行:

Referer:http://localhost/a.htm

这一行就表示,用户要访问的B页是从A页链接过来的。

服务器端要想取得这个值也是很容易的,以ASP为例,只需要写一句

<% =Request.ServerVariables("HTTP_REFERER") %>

就可以了。

一些网站通过HTTP_REFERER来做安全验证,判断用户是不是从允许的页面链接来的,而不是直接从浏览器上打URL或从其他页面链接过来,这样可以从一定程度上防止网页被做非法使用。但从上述原理来看,想要骗过服务器也并不困难,只要手工构造输入的HTTP消息头就可以了,其他常用的手段还有通过HOSTS文件伪造域名等。

除了超链接以外,还有其他几种方式会导致HTTP_REFERER信息被发送,如:

内联框架:<iframe src=b.asp></iframe>

框架集:<frameset><frame src=b.asp></frameset>

表单提交:<form action=b.asp><input type=submit></form>

SCRIPT引用:<script src=b.asp></script>

CSS引用:<link rel=stylesheet type=text/css href=b.asp>

XML数据岛:<xml src=b.asp></xml>

而以下形式不会发送HTTP_REFERER:

script转向:<script>location.href="b.asp"</script>

script开新窗口:<script>window.open("b.asp");</script>

META转向:<meta http-equiv="refresh" content="0;URL=b.asp">

引入图片:<img src=b.asp>

?

2 COOKIE

COOKIE是大家都非常熟悉的了,通过它可以在客户端保存用户状态,即使用户关闭浏览器也能继续保存。那么客户端与服务器端是如何交换COOKIE信息的呢?没错,也是通过HTTP消息头。

首先写一个简单的ASP网页:

<%

Dim i

i =? Request.Cookies("key")

Response.Write i

Response.Cookies("key") = "haha"

Response.Cookies("key").Expires = #2007-1-1#

%>

第一次访问此网页时,屏幕上一片白,第二次访问时,则会显示出“haha”。通过阅读程序不难发现,屏幕上显示的内容实际上是COOKIE的内容,而第一次访问时还没有设置COOKIE的值,所以不会有显示,第二次显示的是第一次设置的值。那么对应的HTTP消息头应该是什么样的呢?

第一次请求时没什么不同,略过

第一次返回时消息内容多了下面这一行:

Set-Cookie: key=haha; expires=Sun, 31-Dec-2006 16:00:00 GMT; path=/

很明显,key=haha表示键名为“key”的COOKIE的值为“haha”,后面是这则COOKIE的过期时间,因为我用的中文操作系统的时区是东八区,2007年1月1日0点对应的GMT时间就是2006年12月31日16点。

第二次再访问此网页时,发送的内容多了如下一行:

Cookie: key=haha

它的内容就是刚才设的COOKIE的内容。可见,客户端在从服务器端得到COOKIE值以后就保存在硬盘上,再次访问时就会把它发送到服务器。发送时并没有发送过期时间,因为服务器对过期时间并不关心,当COOKIE过期后浏览器就不会再发送它了。

如果使用IE6.0浏览器并且禁用COOKIE功能,可以发现服务器端的set-cookie还是有的,但客户端并不会接受它,也不会发送它。有些网站,特别是在线投票网站通过记录COOKIE防止用户重复投票,破解很简单,只要用IE6浏览器并禁用COOKIE就可以了。也有的网站通过COOKIE值为某值来判断用户是否合法,这种判断也非常容易通过手工构造HTTP消息头来欺骗,当然用HOSTS的方式也是可以欺骗的。

?

3 SESSION

HTTP协议本身是无状态的,服务器和客户端都不保证用户访问期间连接会一直保持,事实上保持连接是HTTP1.1才有的新内容,当客户端发送的消息头中有“Connection: Keep-Alive”时表示客户端浏览器支持保持连接的工作方式,但这个连接也会在一段时间没有请求后自动断开,以节省服务器资源。为了在服务器端维持用户状态,SESSION就被发明出来了,现在各主流的动态网页制做工具都支持SESSION,但支持的方式不完全相同,以下皆以ASP为例。

当用户请求一个ASP网页时,在返回的HTTP消息头中会有一行:

Set-Cookie: ASPSESSIONIDCSQCRTBS=KOIPGIMBCOCBFMOBENDCAKDP; path=/

服务器通过COOKIE的方式告诉客户端你的SESSIONID是多少,在这里是“KOIPGIMBCOCBFMOBENDCAKDP”,并且服务器上保留了和此SESSIONID相关的数据,当同一用户再次发送请求时,还会把这个COOKIE再发送回去,服务器端根据此ID找到此用户的数据,也就实现了服务器端用户状态的保存。所以我们用ASP编程时可以使用“session("name")=user”这样的方式保存用户信息。注意此COOKIE内容里并没有过期时间,这表示这是一个当关闭浏览器时立即过期的COOKIE,它不会被保存到硬盘上。这种工作方式比单纯用COOKIE的方式要安全很多,因为在客户端并没有什么能让我们修改和欺骗的值,唯一的信息就是SESSIONID,而这个ID在浏览器关闭时会立即失效,除非别人能在你浏览网站期间或关闭浏览器后很短时间内知道此ID的值,才能做一些欺骗活动。因为服务器端判断SESSION过期的方式并不是断开连接或关闭浏览器,而是通过用户手工结束SESSION或等待超时,当用户关闭浏览器后的一段时间里SESSION还没有超时,所以这时如果知道了刚才的SESSIONID,还是可以欺骗的。因此最安全的办法还是在离开网站之前手工结束SESSION,很多网站都提供“Logout”功能,它会通过设置SESSION中的值为已退出状态或让SESSION立即过期从而起到安全的目的。

SESSION和COOKIE的方式各有优缺点。SESSION的优点是比较安全,不容易被欺骗,缺点是过期时间短,如果用过在超过过期时间里没有向服务器发送任何信息,就会被认为超过过期了;COOKIE则相反,根据服务器端设置的超时时间,可以长时间保留信息,即使关机再开机也可能保留状态,而安全性自然大打折扣。很多网站都提供两种验证方式相结合,如果用户临时用这台电脑访问此访问则需要输入用户名和密码,不保存COOKIE;如果用户使用的是自己的个人电脑,则可以让网站在自己硬盘上保留COOKIE,以后访问时就不需要重新输入用户名和密码了。

?

4 POST

浏览器访问服务器常用的方式有GET和POST两种,GET方式只发送HTTP消息头,没有消息体,也就是除了要GET的基本信息之外不向服务器提供其他信息,网页表单(FROM)的默认提交方式就是用GET方式,它会把所有向服务器提交的信息都作为URL后面的参数,如a.asp?a=1&b=2这样的方式。而当要提交的数据量很大,或者所提交内容不希望别人直接看到时,应该使用POST方式。POST方式提交的数据是作为HTTP消息体存在的,例如,写一个网页表单:

<form method=post>

<input type=text name=text1>

<input type=submit>

</form>

访问此网页,并在表单中填入一个“haha”,然后提交,可以看到此次提交所发送的信息如下:

POST /form.asp HTTP/1.1

Accept: */*

Referer:http://localhost:8080/form.asp

Accept-Language: zh-cn

Content-Type: application/x-www-form-urlencoded

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: localhost:8080

Content-Length: 10

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP

text1=haha

前面关键字从“GET”变为了“POST”,Content-Type变成了“application/x-www-form-urlencoded”,后面内容并无大变化,只是多了一行:Content-Length: 10,表示提交的内容的长度。空行后面是消息体,内容就是表单中所填的内容。注意此时发送的内容只是“Name=Value”的形式,表单上其他的信息不会被发送,所以想直接从服务器端取得list box中所有的list item是办不到的,除非在提交前用一段script把所有的item内容都连在一起放到一个隐含表单域中。

如果是用表单上传文件,情况就要复杂一些了,首先是表单声明中要加上一句话:enctype=&apos;multipart/form-data&apos;,表示这个表单将提交多段数据,并用HTML:input type=file来声明一个文件提交域。

表单内容如下:

<form method=post enctype=&apos;multipart/form-data&apos;>

<input type=text name=text1>

<input type=file name=file1>

<input type=submit>

</form>

我们为text1输入文字:hehe,为file1选择文件haha.txt,其内容为“ABCDEFG”,然后提交此表单。提交的完全信息为:

POST /form.asp HTTP/1.1

Accept: */*

Referer:http://localhost:8080/form.asp

Accept-Language: zh-cn

Content-Type: multipart/form-data; boundary=---------------------------7d62bf2f9066c

Accept-Encoding: gzip, deflate

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; InfoPath.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)

Host: localhost:8080

Content-Length: 337

Connection: Keep-Alive

Cache-Control: no-cache

Cookie: key=haha; ASPSESSIONIDCSQCRTBS=LOIPGIMBLMNOGCOBOMPJBOKP

-----------------------------7d62bf2f9066c

Content-Disposition: form-data; name="text1"

hehe

-----------------------------7d62bf2f9066c

Content-Disposition: form-data; name="file1"; filename="H:\Documents and Settings\Administrator\桌面\haha.txt"

Content-Type: text/plain

ABCDEFG

-----------------------------7d62bf2f9066c--

?

显然这个提交的信息要比前述的复杂很多。Content-Type变成了“multipart/form-data”,后面还多了一个boundary,此值是为了区分POST的内容的区段用的,只要在内容中遇到了此值,就表示下面要开始一个新的区段了,每个区段的内容相对独立。如果遇到的是此值后面连着两个减号,则表示全部内容到此结束。每个段也分为段头和段体两部分,用空行隔开,每段都有自己的类型和相关信息。如第一区段是text1的值,它的名称是“text1”,值为“hehe”。第二段是文件内容,段首里表明了此文件域的名称“file1”和此文件在用户磁盘上的位置,后面就是文件的内容。

如果我们想要自己写一个上传文件组件来接收HTML表单传送的文件数据,那么最核心的任务就是解析此数据包,从中取得需要的信息。

?

?

?

理解HTTP消息头 (四)

服务器返回的消息

服务器返回的HTTP消息也分为消息头和消息体两部分。前面连载的第二篇里已经介绍了返回消息中常见返回代码的含义。对于非正常的返回代码的处理比较简单,只要照着要求去做就好了,而对于正常的返回代码(200),其处理方式就多种多样了。

1 Content-Type

Content-Type是返回消息中非常重要的内容,它标识出这个返回内容的类型,其值为“主类型/子类型”的格式,例如最常见的就是text/html,它的意思是说返回的内容是文本类型,这个文本又是HTML格式的。原则上浏览器会根据Content-Type来决定如何显示返回的消息体内容。常见的内容类型有:

text/html HTML文本

image/jpeg JPG图片

image/gif GIF图片

application/xml XML文档

audio/x-mpegurl MP3文件列表,如果安装了Winamp,则可以直接把它当面M3U文件来打开

更多的内容类型可以在注册表“HKCR\MIME\Database\Content Type”下看到

对于IE6浏览器来说,如果Content-Type中的类型和实际的消息体类型不一致,那么它会根据内容中的类型来分析实际应该是什么类型,对于JPG、GIF等常用图片格式都可以正确的识别出来,而不管Content-Type中写的是什么。

如果Content-Type中指定的是浏览器可以直接打开的类型,那么浏览器就会直接打开其内容显示出来,如果是被关联到其它应用程序的类型,这时就要查找注册表中关于这种类型的注册情况,如果是允许直接打开而不需要询问的,就会直接调出这个关联的应用程序来打开这个文件,但如果是不允许直接打开的,就会询问是否打开。对于没有关联到任何应用程序的类型,IE浏览器不知道它该如何打开,此时IE6就会把它当成XML来尝试打开。

2 Content-Disposition

如果用AddHeader的方法在HTTP消息头中加入Content-Disposition段,并指定其值为“attachment”,那么无论这个文件是何类型,浏览器都会提示我们下载此文件,因为此时它认为后面的消息体是一个“附件”,不需要由浏览器来处理了。例如,在ASP.Net中写入如下语句:

Response.AddHeader("Content-Disposition: attachment");

请求此页面是得到的结果如:

HTTP/1.1 200 OK

Server: Microsoft-IIS/5.1

Date: Thu, 23 Mar 2006 07:54:53 GMT

Content-Disposition: attachment

Cache-Control: private

Content-Type: text/html; charset=utf-8

……

也就是说,通过AddHeader函数可以为HTTP消息头加入我们自定义的内容。使用这种方法可以强制让浏览器提示下载文件,即使这个文件是我们已知的类型,基于是HTML网页。如果想要让用户下载时提示一个默认的文件名,只需要在前面一句话后加上“filename=文件名”即可。例如:

Response.AddHeader("Content-Disposition: attachment; filename=mypage.htm");

3 Content-Type与Content-Disposition

如果把Content-Type和Content-Disposition结合在一起使用会怎么样呢?

打开一个网页时,浏览器会首先看是否有Content-Disposition: attachment这一项,如果有,无论Content-Type的值是什么,都会提示文件下载。

如果指定了filename,就会提示默认的文件名为此文件名。注意到在IE6中除了“保存”按扭外还有“打开”按扭,此时打开文件的类型是由在filename中指定的文件扩展名决定的,例如让filename=mypic.jpg,浏览器就会查找默认的图片查看器来打开此文件。

如果没有指定filename,那么浏览器就根据Content-Type中的类型来决定文件的类型,例如Content-Type类型为image/gif,那么就会去查找默认的看GIF图片的工具,并且设置此文件的名字为所请求的网页的主名(不带扩展名)加上对应于此文件类弄扩展名,例如请求的mypage.aspx,就会自动变成mypage.gif。如果并没有指定Content-Type值,那么就默认它为“text/html”,并且保存的文件名就是所请求的网页文件名。

但如果没有指定Content-Disposition,那么就和前面关于Content-Type中所讨论的情况是一样的了。

4 Cache

返回消息中的Cache用于指定网页缓存。我们经常可以看到这样的情况,打开一个网页时速度不快,但再次打开时就会快很多,原因是浏览器已经对此页面进行了缓存,那么在同一浏览器窗口中再次打开此页时不会重新从服务器端获取。网页的缓存是由HTTP消息头中的“Cache-control”来控制的,常见的取值有private、no-cache、max-age、must-revalidate等,默认为private。其作用根据不同的重新浏览方式分为以下几种情况:

(1) 打开新窗口

如果指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗口访问时都会重新访问服务器。而如果指定了max-age值,那么在此值内的时间里就不会重新访问服务器,例如:

Cache-control: max-age=5

表示当访问此网页后的5秒内再次访问不会去服务器

(2) 在地址栏回车

如果值为private或must-revalidate(和网上说的不一样),则只有第一次访问时会访问服务器,以后就不再访问。如果值为no-cache,那么每次都会访问。如果值为max-age,则在过期之前不会重复访问。

(3) 按后退按扭

如果值为private、must-revalidate、max-age,则不会重访问,而如果为no-cache,则每次都重复访问

(4) 按刷新按扭

无论为何值,都会重复访问

当指定Cache-control值为“no-cache”时,访问此页面不会在Internet临时文章夹留下页面备份。

另外,通过指定“Expires”值也会影响到缓存。例如,指定Expires值为一个早已过去的时间,那么访问此网时若重复在地址栏按回车,那么每次都会重复访问:

Expires: Fri, 31 Dec 1999 16:00:00 GMT

在ASP中,可以通过Response对象的Expires、ExpiresAbsolute属性控制Expires值;通过Response对象的CacheControl属性控制Cache-control的值,例如:

Response.ExpiresAbsolute = #2000-1-1# &apos; 指定绝对的过期时间,这个时间用的是服务器当地时间,会被自动转换为GMT时间

Response.Expires = 20? &apos; 指定相对的过期时间,以分钟为单位,表示从当前时间起过多少分钟过期。

Response.CacheControl = "no-cache"