本文所指的AsyncHttpClient是指基于Netty的一个开源项目，该项目基于Java8编写，用于简化HTTP客户端的开发。该项目还支持WebSocket协议。

要使用该AsyncHttpClient，引入以下Maven依赖：

<dependency>
   <groupId>org.asynchttpclient</groupId>
   <artifactId>async-http-client</artifactId>
   <version>LATEST_VERSION</version>
</dependency>

AsyncHttpClientConfig cf = new DefaultAsyncHttpClientConfig
    .Builder()
    // 设置代理服务器
    .setProxyServer(new ProxyServer.Builder("127.0.0.1", 8087))
    .build();

// 为客户端提供配置项
AsyncHttpClient http = new DefaultAsyncHttpClient(cf);

ListenableFuture<Response> future =
http.prepareGet( "http://ip:port/path" ).execute( new AsyncCompletionHandler<Response>() {

    @Override
    public Response onCompleted( Response response ) throws Exception {
        String resp = response.getResponseBody();
        return response;
    }

    @Override
    public void onThrowable( Throwable t ) {
        // Something wrong happened.
    }
} );

ListenableFuture是java.util.concurrent.Future的子类型，你可以使用Java8并发框架提供的任何特性，例如：

future.get();   // 阻塞等待处理完毕

// 转换为CompletableFuture
CompletableFuture<Response> promise = future.toCompletableFuture();
promise.exceptionally(t -> { /* 当错误发生时 */  } )
       .thenApply(resp -> { /*  处理请求 */ return resp; });

http.preparePost( "http://ip:port/path" )
    // 添加请求参数
    .addQueryParam( "name", alex )
    .addQueryParam( "feature", "0" )
    .execute()

http.preparePost( "http://ip:port/path" )
    // 上传多个文件
    .addBodyPart( new FilePart( "imageDatas", new ClassPathResource( "alex1.jpg" ).getFile() ) )
    .addBodyPart( new FilePart( "imageDatas", new ClassPathResource( "alex2.jpg" ).getFile() ) )
    .execute()

http.preparePost( "http://192.168.0.89:9090/pems/stpush" )
    .addHeader( "Content-Type", "application/json; charset=utf-8" )
    .setBody( json.getBytes( "utf-8" ) )
    .execute().get();

ByteArrayOutputStream bytes = new ByteArrayOutputStream();
String resp = http.prepareGet( "http://www.example.com/" ).execute( new AsyncHandler<String>() {

    public void onThrowable( Throwable t ) {

    }

    public State onBodyPartReceived( HttpResponseBodyPart bodyPart ) throws Exception {
        // 接收到一个上传文件后
        bytes.write( bodyPart.getBodyPartBytes() );
        return State.CONTINUE;
    }

    public State onStatusReceived( HttpResponseStatus responseStatus ) throws Exception {
        // 仅仅获得响应码
        int statusCode = responseStatus.getStatusCode();
        return State.ABORT;
    }

    public State onHeadersReceived( HttpHeaders headers ) throws Exception {
        // 仅仅接收响应头
        return State.ABORT;
    }

    public String onCompleted() throws Exception {
        // 给出此回调的返回值
        return bytes.toString( "UTF-8" );
    }
} ).get();

WebSocket websocket = http.prepareGet( "http://wsep" )
      .execute( new WebSocketUpgradeHandler.Builder().addWebSocketListener(
              new WebSocketTextListener() {
                  @Override
                  public void onMessage( String message ) {
                      // 接收到消息时的回调
                  }

                  @Override
                  public void onOpen( WebSocket websocket ) {
                      // WebSocket打开时的回调
                      websocket.sendTextMessage( "..." ).sendMessage( "..." );
                  }

                  @Override
                  public void onClose( WebSocket websocket ) {
                      // 关闭时的回调 
                  }

                  @Override
                  public void onError( Throwable t ) {
                  }
              } ).build() ).get();

The post AsyncHttpClient知识集锦 appeared first on 绿色记忆.

1. HTTP是一种请求/应答模式（Request–Response pattern）的应用层协议
2. HTTP基于TCP协议进行传输

URI是一类通用的资源标识符，由两个主要的子集URL和URN构成。 URL（统一资源定位符）用于表示浏览器寻找信息时所需的资源位置。

大多数URL方案（Scheme）的语法格式如下：

[scheme]://[user]:[password]@[host]:[port]/[path];]params]?[query]#[frag]

各部分说明如下：

下面是一些合法URL的例子：

https://blog.gmem.cc
https://blog.gmem.cc:442

ftp://alex:pswd@ftp.gmem.cc/public/readme.txt
ftp://anonymous@ftp.gmem.cc/public/readme.txt

mailto:me@gmem.cc

jdbc:oracle:thin:@//dc.gmem.cc:1521/gmem

file://D:/Programs/Scripts/autoproxy.pac

URL有两种方式：绝对的和相对的URL。相对URL是不完整的，要获取其指向的资源，必须找到其基础URL：

1. 如果HTML文档包含 标签，那么使用该标签指定的URL
2. 如果没有声明上述标签，该HTML文档本身所属的URL将用来分析基础URL

http://gmem.cc/codes/

./index.html

http://gmem.cc/codes/index.html

http://gmem.cc/codes

./index.html

http://gmem.cc/index.html

为安全的处理特殊字符，URL引入了转义语法，转义字符以百分号%开头，后面跟随两位十六进制的数字。常用特殊字符的编码如下：

对于非ASCII字符的URL编码，标准规范没有规定如何处理，因此不同浏览器的实现有所不同，这导致服务器端难以正确的解码URL中包含的字符。对于这些字符，可移植性最好的方法是使用JavaScript将其转换为Unicode编码，函数escape/unescape、encodeURI/decodeURI用于完成Unicode编码处理：

HTTP报文由三个部分组成：

1. 起始行（Start line）：对报文进行简短的描述，分为请求行、响应行两种
2. 首部（Header）：包含若干报文属性。以一个空白行结尾
3. 主体（Entity body）：可选的数据主体部分

其中起始行、首部是逐行的ASCII文本，每行使用\r\n两个连续字符（CRLF）进行终止。主体部分则不同，可以是文本数据，也可以是二进制数据。

每个首部条目具有一定的格式：

[名称]: [空白符][值][CRLF]

HTTP报文分为请求报文、响应报文两类。

请求报文的格式为：

[method] [request-URL] [version]
[headers] 

[entity-body]
[last-content]

响应报文的格式为：

[version] [status] [reason-phrase]
[headers]

[entity-body]
[last-content]

上述格式中各组件的描述如下：

HTTP/[major].[minor]

HTTP方法仅对请求报文有意义。并非所有Web服务器支持所有的方法，Web服务器也可以制定自己的扩展方法。

方法是用来告诉服务器做什么事情的，状态码则用来告诉客户端，发生了什么事情。状态码的分类如下：

常见的状态码如下表：

Connection: Keep-Alive

Keep-Alive: max=5, timeout=120

Date: Tue, 11 Jul 2000 18:23:51 GMT

Trailer: Date

Transfer-Encoding: chunked

Upgrade: HTTP/2.0

Via: HTTP/1.1 Proxy1, HTTP/1.1 Proxy2

Cache-Control: max-age=10

Pragma: no-cache

From: me@gmem.cc

Host: blog.gmem.cc

Referer: www.google.com

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)

Accept: text/html, image/*

Accept-Charset: iso-8859-1

Accept-Encoding: gzip, compress

Accept-Language: en, fr

TE: trailers

Expect: 100-continue

If-Match: entity_tag001

If-Modified-Since: Tue, 11 Jul 2000 18:23:51 GMT

If-None-Match: entity_tag001

If-Range: entity_tag001

If-Unmodified-Since: Tue, 11 Jul 2000 18:23:51 GMT

Range: bytes=100-599

Authorization: [credentials]

Max-Forwards: 3

Age: 2147483648

Retry-After: 60

Server: Microsoft-IIS/5.0

Accept-Ranges: none

Proxy-Authenticate: Basic realm-admin

#该Cookie将发送给任何*.gmem.cc的站点
Set-cookie: JSESSIONID="2c85d5b9"; domain="gmem.cc"
#该Cookie将发送给任何*.gmem.cc下所有的/index/*页面
Set-cookie: JSESSIONID="2c85d5b9"; domain="gmem.cc"; path="/index/"

Allow: GET, HEAD

Location: http://gmem.cc/redirect.php

Content-Encoding: gzip, compress

Content-Language: en

Content-Length: 9990

Content-Location: http://gmem.cc/page.php

Content-MD5: [md5-digest]

Content-Range: 1001-2000/5000

Content-Type: text/html

ETag: b38b9-17dd-367c5dcd

Expires: Tue, 11 Jul 2000 18:23:51 GMT

Last-Modified: Tue, 11 Jul 2000 18:23:51 GMT

1. DNS查找：如果URI对应的主机名在本地DNS缓存中不存在，则需要通过DNS服务器查找，该过程可能消耗几百毫秒——几十秒
2. TCP握手与连接建立：小的HTTP事物可能在TCP连接的建立上花费超过50%的时间
3. 其它与TCP协议本身有关的性能因素

1. 并行连接，如果同时开启多个TCP连接，可能提升HTML页面的加载性能。浏览器通常启用了并行连接，一般几个
2. 持久化连接：在一个HTTP事物结束后，TCP连接不会关闭，直到服务器或者客户端显式的关闭。持久化连接包括：
   1. HTTP/1.0+ keep-alive：实现该特性的客户端通过Connection: Keep-Alive首部请求一条持久化连接。如果服务器支持该请求，则其在响应报文里面也加上Connection: Keep-Alive，否则就表示不支持，客户端将在收到响应后关闭连接
   2. HTTP/1.1 persistent：默认激活，因此除非特别说明，HTTP/1.1的连接默认是持久的。要在事务结束后关闭连接，必须在报文中显式的添加

      Connection: close

       首部。客户端和服务器可以随时关闭空闲连接
3. 管道化连接：HTTP/1.1允许在持久化连接可选的使用请求管道。在响应到达之前，即可将后续的多条请求放入管道，该机制在高延迟网络中，有利于减少环回时间。客户端不应当以管道化方式处理非幂等操作（例如POST），非幂等操作必须等待前一条的响应到达后再次发送

以下几种方式可以用于HTTP的身份识别：

1. 承载用户身份信息的HTTP首部：多种HTTP首部可以用于承载用户身份相关信息。例如From、User-Agent、Referer、Authorization、Cookie等
2. 客户端IP地址跟踪。该方式的缺点：
   1. 只能用于识别机器，而不是用户
   2. 对于动态分配的IP地址，无法使用
   3. 对于位于NAT背后的客户端主机，无法使用
   4. 服务器看到的可能是代理的IP地址，而不是真实客户端
   5. IP欺骗（伪造）：在因特网上很容易发生，因此IP身份验证一般只适用于基于信任的内部网络
3. 用户登录，使用HTTP基本认证来识别用户：HTTP提供了一个原生的质询/响应（challenge/response)框架，服务器可以发出401响应和WWW-Authentication首部，浏览器将弹出登录框，用户输入身份信息后，通过Base64编码存放到Authorization首部，并重发先前的请求
4. 胖URL，在URL中嵌入识别信息：为每个用户生成特点版本的URL
5. Cookie，一种功能强大、高效的持久身份识别技术

 Cookie的相关知识可以参考文章：HTTP知识集锦

HTTPS是最流行的HTTP安全形式，由网景首创，主流浏览器均支持。HTTPS方案的URL以“https”开头。

使用HTTPS时，所有数据在通过网络发送之前，都要经过加密。HTTPS在HTTP（应用层）下面提供一个传输级的安全层，该安全层通过SSL或者其继任者TLS实现，可以认为HTTPS就是在SSL之上传输的HTTP。SSL与TLS非常类似，以下不作区分。

大部分涉及安全处理的编码、解码工作由SSL库完成，HTTPS协议端点只需要将TCP调用转为SSL的I/O调用、再辅以一些配置性的调用即可。

通过HTTPS建立安全Web事务后，现代浏览器会自动获得服务器的数字证书，如果没有数字证书，安全连接就会失败，服务器证书包含很多字段，包括：

1. Web站点的名称和主机名
2. Web站点的公开密钥（公钥）
3. 证书颁发结构的名称
4. 来自证书颁发机构的、对上述公钥的签名

浏览器会对颁发机构进行检查，对于权威的颁发机构，其公钥一般已经被浏览器预装。浏览器可以通过此公钥对签名的有效性进行核实。如果浏览器对颁发机构一无所知，则通常会提示用户，询问其是否信任此颁发机构。

HTTPS将数据发送到TCP层之前，会通过SSL对数据进行加密。基于SSL的安全传输机制的建立过程如下：

1. 客户端连接到服务器的HTTPS端口（默认443），建立TCP连接
2. 客户端和服务器通过SSL握手，初始化SSL层
   1. 交换协议版本号
   2. 选择一个两端都知晓的密码
   3. 对两端的身份进行验证
   4. 生成临时会话密钥，用于通道加密
3. 客户端将HTTP报文发送给SSL层，SSL层将其加密，然后传递给TCP层并通过网络发送出去

HTTP/2 的目的是通过支持完整的请求与响应复用来减少延迟，通过有效压缩 HTTP 标头字段将协议开销降至最低，同时增加对请求优先级和服务器推送的支持。为达成这些目标，HTTP/2 还给我们带来了大量其他协议层面的辅助实现，例如新的流控制、错误处理和升级机制。

HTTP/2 没有改动 HTTP 的应用语义。HTTP 方法、状态代码、URI 和标头字段等核心概念一如往常。不过，HTTP/2 修改了数据格式化（分帧）以及在客户端与服务器间传输的方式。

各主流客户端对HTTP2的支持情况参考：https://caniuse.com/#feat=http2

HTTP/2 所有性能增强的核心在于新的二进制分帧层，它定义了如何封装 HTTP 消息并在客户端与服务器之间传输：

这里所谓的“层”，指的是位于套接字接口与应用可见的高级 HTTP API 之间一个经过优化的新编码机制，HTTP 的语义不受影响，不同的是传输期间的编码方式变了。HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。

新的二进制分帧机制改变了客户端与服务器之间交换数据的方式。 为了说明这个过程，我们需要了解 HTTP/2 的三个概念：

1. 数据流：已建立的连接内的双向字节流，可以承载一条或多条消息
2. 消息：与逻辑请求或响应消息对应的完整的一系列帧
3. 帧：HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流

注意：

1. 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流
2. 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息
3. 每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧
4. 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 头、消息负载
5. 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装

帧是HTTP/2最小通信单元，在一个TCP连接上，同一时刻最多有一个帧在发送。

帧报文的格式（单位bit）：

+-----------------------------------------------+
|                 Length (24)                   |
+---------------+---------------+---------------+
|   Type (8)    |   Flags (8)   |
+-+-------------+---------------+-------------------------------+
|R|                 Stream Identifier (31)                      |
+=+=============================================================+
|                   Frame Payload (0...)                      ...
+---------------------------------------------------------------+

字段说明：

1. Length：帧载荷部分的长度
2. Type： 帧类型。0000 0000为DATA帧，0000 0001为HEADERS帧
3. Flags：不同类型的帧分别设置，特殊标记位。例如HEADERS帧会设置END_HEADERS标记位来提示头传送完毕
4. R：无用
5. Stream Identifier：当前帧所属的流的标识符
6. Frame Payload帧的载荷部分

HTTP/2支持多路复用，每一路就是一个流。流具有标识符，每个帧都指明它所属的流的标识符。

由于HTTP/2支持Server Push，也就是说服务器可以主动创建流。那么客户端和服务器的流ID如何防止冲突？协议规定，服务器使用偶数，客户端使用奇数。

流的状态转换示意图：

+--------+
                        send PP |        | recv PP
                       ,--------|  idle  |--------.
                      /         |        |         \
                     v          +--------+          v
              +----------+          |           +----------+
              |          |          | send H /  |          |
       ,------| reserved |          | recv H    | reserved |------.
       |      | (local)  |          |           | (remote) |      |
       |      +----------+          v           +----------+      |
       |          |             +--------+             |          |
       |          |     recv ES |        | send ES     |          |
       |   send H |     ,-------|  open  |-------.     | recv H   |
       |          |    /        |        |        \    |          |
       |          v   v         +--------+         v   v          |
       |      +----------+          |           +----------+      |
       |      |   half   |          |           |   half   |      |
       |      |  closed  |          | send R /  |  closed  |      |
       |      | (remote) |          | recv R    | (local)  |      |
       |      +----------+          |           +----------+      |
       |           |                |                 |           |
       |           | send ES /      |       recv ES / |           |
       |           | send R /       v        send R / |           |
       |           | recv R     +--------+   recv R   |           |
       | send R /  `----------->|        |<-----------'  send R / |
       | recv R                 | closed |               recv R   |
       `----------------------->|        |<----------------------'
                                +--------+

          send:   endpoint sends this frame
          recv:   endpoint receives this frame

          H:  HEADERS frame (with implied CONTINUATIONs)
          PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
          ES: END_STREAM flag
          R:  RST_STREAM frame

其中：

1. idle：流目前尚未启用
2. open：流目前正在使用
3. closed：流已经使用完成
4. reserved（local）：本地保留，即将要使用但是尚未使用
5. reserved（remote）：远端保留，即将要使用但是未使用
6. half closed（local）：本地半关闭，即将关闭但是尚未关闭
7. half closed（remote）：远端半关闭，即将关闭但是尚未关闭

收到或者发送HEADERS这种类型的帧会使流进入open状态，也就是说，HEADERS一定会建立一个新的流

发送PUSH_PROMISE的那一方会把流保存为reserved（local）的状态，当发送完HEADERS之后会变成half closed（remote）状态

一个典型的HTTP报文包含请求/响应，组成如下：

1. 零或多个HEADERS帧，一个HEADERS帧可能跟着0-N个CONTINUATION帧，以补充单个HEADERS容量不够的情况。大部分情况下一个HEADERS帧就包含了完整的报文头
2. 0-N个DATA数据帧，包含了具体的消息载荷内容
3. 一个HEADERS帧，后面跟随0-N个包含有报尾（Trailer-part）的CONTINUATION帧

HTTP/2服务器可以对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端明确地请求。

所有服务器推送数据流都由 PUSH_PROMISE 帧发起，表明了服务器向客户端推送所述资源的意图，并且需要先于请求推送资源的响应数据传输。

在客户端接收到 PUSH_PROMISE 帧后，它可以根据自身情况（例如有缓存）选择拒绝数据流（通过 RST_STREAM 帧）。

Google的SPDY协议包含名为NPN的TLS扩展，SPDY被HTTP/2取代后，NPN相应的成为ALPN（应用层协议协商）。

客户端在建立 TLS 连接的 Client Hello 握手中，通过 ALPN 扩展列出了自己支持的各种应用层协议，其中HTTP/2 协议名称是 h2。如果服务端支持 HTTP/2，在 Server Hello 中指定 ALPN 的结果为 h2 则协商完成，否则从客户端ALPN的列表中选择一个自己支持的协议。

The post HTTP协议学习笔记 appeared first on 绿色记忆.

Cookies是一种最常使用的客户端存储机制，Cookies由Netscape在1994年提出，用来为HTTP协议引入状态机制。

为了使基于Cookies的状态机制能够工作，Web服务器会在HTTP响应的Set-Cookie头中设置Cookie，保存用户身份、状态信息，而浏览器在下一次发送HTTP请求的时候，会把先前Web服务器设置的Cookie绑定在HTTP请求头中，发送回去。

由于每次HTTP请求都会重复的发送Cookies，所有Cookies不适合存放过大的数据，事实上，大部分浏览器对每个域名可设置Cookies的大小、都有严格限制，通常在数十个、几KB以内。

1. Cookies的Domain可以设置为IP地址，但是不能使用通配符，例如.0.1这样的Domain是非法的
2. Domain：域名至少包含两个点号。域设置为.gmem.cc的Cookie可以让gmem.cc域名下所有网站使用，例如blog.gmem.cc
3. Path：限制使用Cookie的网页目录，路径设置为/wp-admin/的Cookie可以让gmem.cc/wp-admin/下所有子URL对应的网页访问
4. Secure：可以限制Cookie只能通过加密连接（SSL）发送
5. Expires：可以限制Cookie的生存期，如果不设置，那么浏览器关闭后Cookie即消失

所谓源，是指由三元组：协议 + 域名 + 端口确定的唯一网络实体。

通过JavaScript可以修改当前页面的源，但是只能域名为当前域名的超级域名：

document.domain = "gmem.cc";

修改后，同源策略检查结果将受到影响。使用这种技术，可以让位于子域名中的多个网站方便的交互。

原则：

1. 通常允许跨域执行写操作：例如链接、重定向、表单提交
2. 通常允许跨域资源嵌入
3. 通常不允许跨域读操作：例如Ajax请求

其中第一条，为CSRF（跨站请求伪造，Cross-site request forgery）埋下隐患。攻击者可能引导用户访问一个恶意站点，而此恶意站点包含了修改敏感信息的表单，此表单自动跨源发送，伪造用户身份篡改信息。可以使用不可测的CSRF标记来防止跨域写。

第二条，可以嵌入的资源包括：

1. script标签
2. link标签，嵌入css。CSS的跨域需要一个设置正确的Content-Type消息头
3. img标签
4. video、audio标签
5. object、embed、applet插件
6. @font-face引入的字体。某些浏览器要求同源字体
7. frame、iframe。站点可以使用

   X-Frame-Options

    头禁止这类资源嵌入

你可以使用CORS、JsonP等技术允许来进行跨源的资源共享。

JsonP即JSON with Padding，其实与JSON没有直接关系，是一种跨站资源共享的方式。

由于浏览器的同源策略，blog.gmem.cc一般是无法与诸如soulspark.im之类的其它网站进行通信的，但是HTTP的

<script>

假设blog.gmem.cc/postinfo/{postid}提供一个获取文章信息的RESTful服务，其返回值是text/json格式，示例如下：

{
    "post_author" : "alex",
    "post_title"  : "HTTP协议知识集锦"
}

 那么soulspark.im的某个页面如何才能访问并获取某篇文章的信息呢？

如果直接使用Ajax请求访问，同源策略可能导致访问被禁止，那么如果使用

<script>

要支持JsonP，blog.gmem.cc必须改造postinfo服务，允许其传入一个“Padding”参数，该参数由调用者soulspark.im指定，通常是一个JavaScript函数的名称，改造后的postinfo服务的URL示例为：

blog.gmem.cc/postinfo/{postid}?jsonp=decodePost

//decodePost即所谓Padding，由客户端提供的简短字符串，通常就是所谓“回调函数”
decodePost(
    {
        "post_author" : "alex",
        "post_title"  : "HTTP协议知识集锦"
    }
);

这样，soulspark.im就可以调用decodePost()，从而获取文章的信息了。

需要注意的时，

<script>

JsonP允许远端Web服务注入任意JavaScript代码，因此具有很大的安全性风险，如果远端服务器具有安全缺陷，或者响应内容在网络上被篡改，将导致本地Web页面受到威胁。

CORS，即Cross-origin resource sharing（跨来源资源共享）是一份浏览器技术规范。相比起JsonP，它有如下优势：

1. 支持除了GET以外的其它HTTP请求方法
2. 支持使用一般的Ajax（XMLHttpRequest、Fetch）直接获取资源
3. 支持跨源使用Webfont、WebGL贴图、样式表、脚本

所谓跨源，指发起请求的那个网页所在的源（协议 + 域名 + 端口），与请求的目标网页的源不一致。

大部分现代浏览器，包括IE 8+，均支持CORS。

要支持CORS，服务器端必须设置

Access-Control-Allow-Origin

headers.setdefault('Access-Control-Allow-Origin', '*')
"""
上述配置允许任何其它的Domain向服务器发起请求。
把*换成http://soulspark.im，则仅仅允许soulspark.im发起请求
"""

如果服务器不进行设置，客户端在尝试CORS访问时将会报错。 

与CORS有关的响应头包括：

Origin

在浏览器中，Origin头会在需要时，自动的被浏览器设置，JavaScript代码无法干预。因此CORS依赖浏览器的正确行为来工作。

发送CORS的Ajax请求时要想带着Cookie，不但需要服务器同意，客户端也要显式的指定：

var xhr = new XMLHttpRequest();
xhr.withCredentials = true;  // 附带Cookie

启用上述设置时，Access-Control-Allow-Origin不允许指定为*，同时Cookie仍然受到同源策略的限制。

由于CORS依赖于浏览器的行为，因此服务器不能对客户端做假设。

The post HTTP知识集锦 appeared first on 绿色记忆.