4、HTTP（下）

   】 

HTTP方法

与HTTP服务器的通信遵循一种请求--响应模式

先是接收一个无状态的请求，后面是一个无状态的响应

每个HTTP请求包含两个或三个部分：

1、起始行，包含HTTP方法和要执行这个方法的资源路径

2、一个包含  名-值 字段的首部，可以提供元信息，如认证凭据和请求中首选使用的合适

3、一个 请求主体，包含资源的一个表示（只针对POST和PUT）

主要有4个HTTP方法来标识可以完成的操作：

1、GET：获取一个资源的表示，如果失败完全可以重复执行GET，不用担心有任何问题

　　　　  GET输出通常会缓存，可以通过正确的首部来控制

2、POST：最通用的方法，将资源的一个表示上传到已知的URL的服务器，但是没有指定服务器如何处理这个新提供的资源 

3、PUT：将资源的一个表示上传到已知URL的服务器，没有副作用，有等幂性

　　　　  重复这个方法不用担心它是否失败

　　　　  如果连续两次将同一个文档放在同一个服务器的统一位置，与只放一次，服务器的状态是一样的

4、DELETE：从一个指定URL删除一个资源，没有副作用，也是幂等的

　　　　　　  不确定删除请求是否成功，完全可以再次发送这个请求

不完成提交所有安全操作 应当使用GRT，只有真正提交的操作才使用POST

请求主体

GET方法获取URL所标识的资源的一个表示

用GET从服务器获取的资源的具体位置由路径和查询字符串的不同部分指定

不同的路径和查询字符串如何简单映射到不同资源要由服务器来决定

URL类并不关心这些，只要知道URL就能知道从哪里下载

POST和PUT：客户端除了要提供路径和查询字符串还需要提供资源的表示

资源表示在请求主题中发送，放在首部后面

会按顺序发送：

1、一个起始行，包括方法、路径和查询字符串，以及HTTP版本

2、一个HTTP首部

3、一个空行

4、主体

POST请求向服务器发送表单的数据

主题包含一个Content-Type:application/x-www-form-urlencoded数据

但不只有这一种可能性

一般来说，主体可以包含任意的字节

但是HTTP首部需要包括两个字段来指定主体的性值：

1、Content-length:指定主体中有多少字节

2、Content-type：指定类型为MIME媒体类型

Cookie

网站可以使用一些小文本串在连接存储持久的客户端状态，这些小文本称为cookie

 cookie在请求和响应的HTTP首部

从服务器传递到客户端

在从客户端传回服务器

服务器使用cookie来指示会话ID、购物车内容、登陆凭据等

cookie值可能是一个无意义的字符串

标识某种数据中的一个特定的记录

实际信息存储在那个数据库中

cookie通常并不包含数据，只是指示服务器上的数据

cookie只能是非空白符的ASCII文本，不能包括逗号或者分号

要在浏览器中设置一个cookie

服务器会在HTTP首部中包含一个Set-Cookie首部行

浏览器再次向服务器做出第二个请求

他会在HTTP请求首部行中的Cookie行发回这个cookie

 只要服务器不重用cookie

这会使他在多个无状态的HTTP连接上跟踪各个用户和会话

服务器可以设置多个Cookie

除了简单的name-value对

cookie可以有更多属性来哦内阁制他们的作用域

包括日期、路径、域、端口、版本和安全选项

默认情况下

cookie来自那个服务器就应用于那个服务器

网站也可以指示一个cookie应用于整个子域

而不是整个服务器

 

一些网站把一个域的一个图像或其他内容嵌入到另一个域的一个页面，从而绕过 这个限制

所嵌入内容设置的cookie称为第三方cookie

很多用户会阻塞所有第三方cookie

处于保密的原因

一些Web浏览器也开始默认阻塞这些第三方cookie

Cookie的作用于还受路径限制

所以会返回到服务器上的某些目录，而不是全部

默认作用域是最初的URL和所有子目录

http://www.mrchengs.com/index设置一个cookie

那么这个cookie可以用到http://www.mrchengs.com/index/xxx

但是不能作用于http://www.mrchengs.com/xxxx（除了index)

cookie中的path属性可以改默认作用域

如

此时的user=elharo的cookie只应用于/restricted

请求相同服务器上子树/restricted中的一个文档时

客户端会回显这个cookie

不会在网站的其他目录中使用这个cookie

cookie可以同时包括域和路径

作用于example.com域中任何服务器的/restricted路径

不同的cookie属性的顺序无关紧要

只要全部是使用分号隔开

cookie自己的名和值放在最前即可

客户端把cookie发回i服务器时，路径必须在最前面

Max-Age属性:可以设置cookie经过一定秒数之后过期

而不是在特定的时刻过期

Cookie可能包含敏感信息（口令密钥...)

一些cookie事务应当是安全的

大多数情况下，会使用HTTPS代替HTTP，不论标识什么

每个cookie都有一个没有值的属性secure

 

浏览器应当拒绝非安全通道发送这种cookie

特别强调不能由JS返回

CookieManager

Java 5包括一个抽象类java.net.CookieHandler

定义了存储和获取cookie的一个API

但不包括抽象类的实现，所以有很多工作要做

Java 6进一步做了补充，为CookieHandler增加了一个可以使用具体子类的java.net.CookieManager

默认情况下cookie并不打开

在java存储和返回cookie之前，需要首先启动cookie

这两行代码安装了一个CookManager之后，对于URL类连接的HTTP服务器

Java会存储这些服务器发送的所有cookie

在后续的请求中向这些服务器发回存储的cookie

对于接收哪里发送的cookie还需要慎重

可以通过指定CookiePolicy来指定

预定了3个策略：

下方的代码会阻塞第三方cookie

但是会接收第一方cookie

即：只接受与服务器的发送的Cookie

不能接收Internet上其他服务器发送的cookie

 

 还希望接收更有粒度的控制

接收某些已知域的cookie，不接受其他域的cookie

可以自行实现CookiePolicy节后，并且覆盖shouldAccept()方法

public interface CookiePolicy {

    public static final CookiePolicy ACCEPT_ALL = new CookiePolicy(){
        public boolean shouldAccept(URI uri, HttpCookie cookie) {
            return true;
        }
    };

    public static final CookiePolicy ACCEPT_NONE = new CookiePolicy(){
        public boolean shouldAccept(URI uri, HttpCookie cookie) {
            return false;
        }
    };

    public static final CookiePolicy ACCEPT_ORIGINAL_SERVER  = new CookiePolicy(){
        public boolean shouldAccept(URI uri, HttpCookie cookie) {
            if (uri == null || cookie == null)
                return false;
            return HttpCookie.domainMatches(cookie.getDomain(), uri.getHost());
        }
    };

    public boolean shouldAccept(URI uri, HttpCookie cookie);
}

 实例：

阻塞所有.xxx cookie但接收其他cookie策略

CookieStore

有时需要在本地存放和获取cookie

一个应用退出时可以把cookie存在本地磁盘上

下一次启动时在加载这些

可以使用getCookieStore()方法来获取这个cookie库

CookieManager就在这里保存它的cookie

 CookieStore类可以增加、删除、列出cookie

能控制正常HTTP请求响应流之外发送的cookie

库中的每个cookie都封装在一个HttpCookie对象中

塔公一些方法来检查cookie的属性