HTTP 首部

HTTP 首部

HTTP 报文首部

HTTP 协议的请求和响应报文中必定包含 HTTP 首部。首部内容为客

户端和服务器分别处理请求和响应提供所需要的信息。对于客户端用户来说,这些信息中的大部分内容都无须亲自查看

报文首部由几个字段构成

HTTP 请求报文

在请求中,HTTP 报文由方法、URI、HTTP 版本、HTTP 首部字段等

部分构成。

下面的示例是访问 http://hackr.jp 时,请求报文的首部信息。

GET / HTTP/1.1

Host: hackr.jp

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8

Accept-Language: ja,en-us;q=0.7,en;q=0.3

Accept-Encoding: gzip, deflate

DNT: 1

Connection: keep-alive

If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT

If-None-Match: "45bae1-16a-46d776ac"

Cache-Control: max-age=0

HTTP 响应报文

在响应中,HTTP 报文由 HTTP 版本、状态码(数字和原因短语)、

HTTP 首部字段 3 部分构成。

以下示例是之前请求访问 http://hackr.jp/ 时,返回的响应报文的首部

信息。

HTTP/1.1 304 Not Modified

Date: Thu, 07 Jun 2012 07:21:36 GMT

Server: Apache

Connection: close

Etag: "45bae1-16a-46d776ac"

在报文众多的字段当中,HTTP 首部字段包含的信息最为丰富。首部

字段同时存在于请求和响应报文内,并涵盖 HTTP 报文相关的内容信

息。

因 HTTP 版本或扩展规范的变化,首部字段可支持的字段内容略有不

同。本书主要涉及 HTTP/1.1 及常用的首部字段。

HTTP 首部字段

HTTP 首部字段传递重要信息

HTTP 首部字段是构成 HTTP 报文的要素之一。在客户端与服务器之

间以 HTTP 协议进行通信的过程中,无论是请求还是响应都会使用首

部字段,它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的

语言、认证信息等内容。

HTTP 首部字段结构

HTTP 首部字段是由首部字段名和字段值构成的,中间用冒号“:” 分

隔。

首部字段名: 字段值

例如,在 HTTP 首部中以 Content-Type 这个字段来表示报文主体的 对

象类型。

Content-Type: text/html

就以上述示例来看,首部字段名为 Content-Type,字符串 text/html 是

字段值。

另外,字段值对应单个 HTTP 首部字段可以有多个值,如下所示。

Keep-Alive: timeout=15, max=100

若 HTTP 首部字段重复了会如何

当 HTTP 报文首部中出现了两个或两个以上具有相同首部字段名时

会怎么样?这种情况在规范内尚未明确,根据浏览器内部处理逻辑

的不同,结果可能并不一致。有些浏览器会优先处理第一次出现的

首部字段,而有些则会优先处理最后出现的首部字段。

4 种 HTTP 首部字段类型

HTTP 首部字段根据实际用途被分为以下 4 种类型。

通用首部字段(General Header Fields)

请求报文和响应报文两方都会使用的首部。

请求首部字段(Request Header Fields)

从客户端向服务器端发送请求报文时使用的首部。补充了请求的附加

内容、客户端信息、响应内容相关优先级等信息。

响应首部字段(Response Header Fields)

从服务器端向客户端返回响应报文时使用的首部。补充了响应的附加

内容,也会要求客户端附加额外的内容信息。

实体首部字段(Entity Header Fields)

针对请求报文和响应报文的实体部分使用的首部。补充了资源内容更

新时间等与实体有关的信息。

HTTP/1.1 首部字段一览

HTTP/1.1 规范定义了如下 47 种首部字段。

表 6-2:请求首部字段

非 HTTP/1.1 首部字段

在 HTTP 协议通信交互中使用到的首部字段,不限于 RFC2616 中定

义的 47 种首部字段。还有 Cookie、Set-Cookie 和 Content-Disposition

等在其他 RFC 中定义的首部字段,它们的使用频率也很高。

这些非正式的首部字段统一归纳在 RFC4229 HTTP Header Field

Registrations 中。

End-to-end 首部和 Hop-by-hop 首部

HTTP 首部字段将定义成缓存代理和非缓存代理的行为,分成 2 种类

型。

端到端首部(End-to-end Header)

分在此类别中的首部会转发给请求 / 响应对应的最终接收目标,且必

须保存在由缓存生成的响应中,另外规定它必须被转发。

逐跳首部(Hop-by-hop Header)

分在此类别中的首部只对单次转发有效,会因通过缓存或代理而不再转发。HTTP/1.1 和之后版本中,如果要使用 hop-by-hop 首部,需提

供 Connection 首部字段。

下面列举了 HTTP/1.1 中的逐跳首部字段。除这 8 个首部字段之外,

其他所有字段都属于端到端首部。

Connection

Keep-Alive

Proxy-Authenticate

Proxy-Authorization

Trailer

TE

Transfer-Encoding

Upgrade

HTTP/1.1 通用首部字段

通用首部字段是指,请求报文和响应报文双方都会使用的首部

Cache-Control

通过指定首部字段 Cache-Control 的指令,就能操作缓存的工作机

制。

指令的参数是可选的,多个指令之间通过“,”分隔。首部字段 Cache-

Control 的指令可用于请求及响应时。

Cache-Control: private, max-age=0, no-cache

Cache-Control 指令一览

表示是否能缓存的指令

public 指令

Cache-Control: public

当指定使用 public 指令时,则明确表明其他用户也可利用缓存。

private 指令

Cache-Control: private

当指定 private 指令后,响应只以特定的用户作为对象,这与 public

指令的行为相反。

缓存服务器会对该特定用户提供资源缓存的服务,对于其他用户发送过来的请求,代理服务器则不会返回缓存。

no-cache 指令

Cache-Control: no-cache

使用 no-cache 指令的目的是为了防止从缓存中返回过期的资源。

客户端发送的请求中如果包含 no-cache 指令,则表示客户端将不会接

收缓存过的响应。于是,“中间”的缓存服务器必须把客户端请求转发

给源服务器。

如果服务器返回的响应中包含 no-cache 指令,那么缓存服务器不能对

资源进行缓存。源服务器以后也将不再对缓存服务器请求中提出的资

源有效性进行确认,且禁止其对响应资源进行缓存操作。

Cache-Control: no-cache=Location

由服务器返回的响应中,若报文首部字段 Cache-Control 中对 no-cache

字段名具体指定参数值,那么客户端在接收到这个被指定参数值的首

部字段对应的响应报文后,就不能使用缓存。换言之,无参数值的首

部字段可以使用缓存。只能在响应指令中指定该参数。

控制可执行缓存的对象的指令

no-store 指令

Cache-Control: no-store

当使用 no-store 指令时,暗示请求(和对应的响应)或响应中包含

机密信息。因此,该指令规定缓存不能在本地存储请求或响应的任一部分。

指定缓存期限和认证的指令

s-maxage 指令

Cache-Control: s-maxage=604800(单位 :秒)

s-maxage 指令的功能和 max-age 指令的相同,它们的不同点是 smaxage

指令只适用于供多位用户使用的公共缓存服务器 。也就是

说,对于向同一用户重复返回响应的服务器来说,这个指令没有任何

作用。

另外,当使用 s-maxage 指令后,则直接忽略对 Expires 首部字段及

max-age 指令的处理。

max-age 指令

Cache-Control: max-age=604800(单位:秒)

当客户端发送的请求中包含 max-age 指令时,如果判定缓存资源的缓

存时间数值比指定时间的数值更小,那么客户端就接收缓存的资源。

另外,当指定 max-age 值为 0,那么缓存服务器通常需要将请求转发

给源服务器。

当服务器返回的响应中包含 max-age 指令时,缓存服务器将不对资源

的有效性再作确认,而 max-age 数值代表资源保存为缓存的最长时

间。

应用 HTTP/1.1 版本的缓存服务器遇到同时存在 Expires 首部字段的情

况时,会优先处理 max-age 指令,而忽略掉 Expires 首部字段。而

HTTP/1.0 版本的缓存服务器的情况却相反,max-age 指令会被忽略掉

min-fresh 指令

Cache-Control: min-fresh=60(单位:秒)

min-fresh 指令要求缓存服务器返回至少还未过指定时间的缓存资源。

比如,当指定 min-fresh 为 60 秒后,过了 60 秒的资源都无法作为响

应返回了。

max-stale 指令

Cache-Control: max-stale=3600(单位:秒)

使用 max-stale 可指示缓存资源,即使过期也照常接收。

如果指令未指定参数值,那么无论经过多久,客户端都会接收响应;

如果指令中指定了具体数值,那么即使过期,只要仍处于 max-stale

指定的时间内,仍旧会被客户端接收。

only-if-cached 指令

Cache-Control: only-if-cached

使用 only-if-cached 指令表示客户端仅在缓存服务器本地缓存目标资

源的情况下才会要求其返回。换言之,该指令要求缓存服务器不重新

加载响应,也不会再次确认资源有效性。若发生请求缓存服务器的本

地缓存无响应,则返回状态码 504 Gateway Timeout。

must-revalidate 指令

Cache-Control: must-revalidate

使用 must-revalidate 指令,代理会向源服务器再次验证即将返回的响

应缓存目前是否仍然有效。

若代理无法连通源服务器再次获取有效资源的话,缓存必须给客户端

一条 504(Gateway Timeout)状态码。

另外,使用 must-revalidate 指令会忽略请求的 max-stale 指令(即使已

经在首部使用了 max-stale,也不会再有效果)。

proxy-revalidate 指令

Cache-Control: proxy-revalidate

proxy-revalidate 指令要求所有的缓存服务器在接收到客户端带有该指

令的请求返回响应之前,必须再次验证缓存的有效性。

no-transform 指令

Cache-Control: no-transform

使用 no-transform 指令规定无论是在请求还是响应中,缓存都不能改

变实体主体的媒体类型。这样做可防止缓存或代理压缩图片等类似操作。

Cache-Control 扩展

cache-extension token

Cache-Control: private, community="UCI"

通过 cache-extension 标记(token),可以扩展 Cache-Control 首部字

段内的指令。

如上例,Cache-Control 首部字段本身没有 community 这个指令。借助

extension tokens 实现了该指令的添加。如果缓存服务器不能理解

community 这个新指令,就会直接忽略。因此,extension tokens 仅对

能理解它的缓存服务器来说是有意义的。

Connection

Connection 首部字段具备如下两个作用

控制不再转发给代理的首部字段

Connection: 不再转发的首部字段名

在客户端发送请求和服务器返回响应内,使用 Connection 首部字

段,可控制不再转发给代理的首部字段(即 Hop-by-hop 首

部)。

管理持久连接

Connection: close

       HTTP/1.1 版本的默认连接都是持久连接。为此,客户端会在持

久连接上连续发送请求。当服务器端想明确断开连接时,则指定

Connection 首部字段的值为 Close。

Connection: Keep-Alive

       HTTP/1.1 之前的 HTTP 版本的默认连接都是非持久连接。为

此,如果想在旧版本的 HTTP 协议上维持持续连接,则需要指定

Connection 首部字段的值为 Keep-Alive。


如上图①所示,客户端发送请求给服务器时,服务器端会像上图

②那样加上首部字段 Keep-Alive 及首部字段 Connection 后返回

响应。

Date

首部字段 Date 表明创建 HTTP 报文的日期和时间。

HTTP/1.1 协议使用在 RFC1123 中规定的日期时间的格式,如下 示

例。

Date: Tue, 03 Jul 2012 04:40:59 GMT

之前的 HTTP 协议版本中使用在 RFC850 中定义的格式,如下所示。

Date: Tue, 03-Jul-12 04:40:59 GMT

除此之外,还有一种格式。它与 C 标准库内的 asctime() 函数的输出

格式一致。

Date: Tue Jul 03 04:40:59 2012

Pragma

Pragma 是 HTTP/1.1 之前版本的历史遗留字段,仅作为与 HTTP/1.0

的向后兼容而定义。

规范定义的形式唯一,如下所示。

Pragma: no-cache

该首部字段属于通用首部字段,但只用在客户端发送的请求中。客户

端会要求所有的中间服务器不返回缓存的资源。

所有的中间服务器如果都能以 HTTP/1.1 为基准,那直接采用 Cache-

Control: no-cache 指定缓存的处理方式是最为理想的。但要整体掌握

全部中间服务器使用的 HTTP 协议版本却是不现实的。因此,发送的

请求会同时含有下面两个首部字段。

Cache-Control: no-cache

Pragma: no-cache

Trailer

首部字段 Trailer 会事先说明在报文主体后记录了哪些首部字段。该

首部字段可应用在 HTTP/1.1 版本分块传输编码时。

HTTP/1.1 200 OK

Date: Tue, 03 Jul 2012 04:40:56 GMT

Content-Type: text/html

...

Transfer-Encoding: chunked

Trailer: Expires

...(报文主体)...

0

Expires: Tue, 28 Sep 2004 23:59:59 GMT

以上用例中,指定首部字段 Trailer 的值为 Expires,在报文主体之后

(分块长度 0 之后)出现了首部字段 Expires。

Transfer-Encoding

首部字段 Transfer-Encoding 规定了传输报文主体时采用的编码方式。HTTP/1.1 的传输编码方式仅对分块传输编码有效

HTTP/1.1 200 OK

Date: Tue, 03 Jul 2012 04:40:56 GMT

Cache-Control: public, max-age=604800

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

Expires: Tue, 10 Jul 2012 04:40:56 GMT

X-Frame-Options: DENY

X-XSS-Protection: 1; mode=block

Content-Encoding: gzip

Transfer-Encoding: chunked

Connection: keep-alive

cf0 ←16进制(10进制为3312)

...3312字节分块数据...

392 ←16进制(10进制为914)

...914字节分块数据...

0

以上用例中,正如在首部字段 Transfer-Encoding 中指定的那样,有效

使用分块传输编码,且分别被分成 3312 字节和 914 字节大小的分块

数据。

Upgrade

首部字段 Upgrade 用于检测 HTTP 协议及其他协议是否可使用更高的

版本进行通信,其参数值可以用来指定一个完全不同的通信协议。

上图用例中,首部字段 Upgrade 指定的值为 TLS/1.0。请注意此处两

个字段首部字段的对应关系,Connection 的值被指定为 Upgrade。

Upgrade 首部字段产生作用的 Upgrade 对象仅限于客户端和邻接服务

器之间。因此,使用首部字段 Upgrade 时,还需要额外指定

Connection:Upgrade。

对于附有首部字段 Upgrade 的请求,服务器可用 101 Switching

Protocols 状态码作为响应返回。

Via

使用首部字段 Via 是为了追踪客户端与服务器之间的请求和响应报文

的传输路径。

报文经过代理或网关时,会先在首部字段 Via 中附加该服务器的信

息,然后再进行转发。这个做法和 traceroute 及电子邮件的 Received

首部的工作机制很类似。

首部字段 Via 不仅用于追踪报文的转发,还可避免请求回环的发生。所以必须在经过代理时附加该首部字段内容。

上图用例中,在经过代理服务器 A 时,Via 首部附加了“1.0

gw.hackr.jp (Squid/3.1)”这样的字符串值。行头的 1.0 是指接收请求的服务器上应用的 HTTP 协议版本。接下来经过代理服务器 B 时亦是如

此,在 Via 首部附加服务器信息,也可增加 1 个新的 Via 首部写入服

务器信息。

Via 首部是为了追踪传输路径,所以经常会和 TRACE 方法一起使

用。比如,代理服务器接收到由 TRACE 方法发送过来的请求(其中

Max-Forwards: 0)时,代理服务器就不能再转发该请求了。这种情况

下,代理服务器会将自身的信息附加到 Via 首部后,返回该请求的响

应。

Warning

HTTP/1.1 的 Warning 首部是从 HTTP/1.0 的响应首部(Retry-After)演

变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。

Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03

Warning 首部的格式如下。最后的日期时间部分可省略。

Warning: [警告码][警告的主机:端口号]“[警告内容]”([日期时间])

HTTP/1.1 中定义了 7 种警告。警告码对应的警告内容仅推荐参考。

另外,警告码具备扩展性,今后有可能追加新的警告码

请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段,

用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等

内容。

Accept

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;

Accept 首部字段可通知服务器,用户代理能够处理的媒体类型及媒体

类型的相对优先级。可使用 type/subtype 这种形式,一次指定多种媒

体类型。

下面我们试举几个媒体类型的例子

文本文件

text/html, text/plain, text/css ...

application/xhtml+xml, application/xml ...

图片文件

image/jpeg, image/gif, image/png ...

视频文件

video/mpeg, video/quicktime ...

应用程序使用的二进制文件

application/octet-stream, application/zip ...

比如,如果浏览器不支持 PNG 图片的显示,那 Accept 就不指定

image/png,而指定可处理的 image/gif 和 image/jpeg 等图片类型。

Accept-Charset

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Accept-Charset 首部字段可用来通知服务器用户代理支持的字符集及

字符集的相对优先顺序。另外,可一次性指定多种字符集。与首部字

段 Accept 相同的是可用权重 q 值来表示相对优先级。

该首部字段应用于内容协商机制的服务器驱动协商。

Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding 首部字段用来告知服务器用户代理支持的内容编码及

内容编码的优先级顺序。可一次性指定多种内容编码。

下面试举出几个内容编码的例子。

gzip

       由文件压缩程序 gzip(GNU zip)生成的编码格式

(RFC1952),采用 Lempel-Ziv 算法(LZ77)及 32              位循环冗余

校验(Cyclic Redundancy Check,通称 CRC)。

compress

由 UNIX 文件压缩程序 compress 生成的编码格式,采用 Lempel-

Ziv-Welch 算法(LZW)。

deflate

          组合使用 zlib 格式(RFC1950)及由 deflate 压缩算法

(RFC1951)生成的编码格式。

identity

  不执行压缩或不会变化的默认编码格式

采用权重 q 值来表示相对优先级,这点与首部字段 Accept 相同。另

外,也可使用星号(*)作为通配符,指定任意的编码格式。

Accept-Language

Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3

首部字段 Accept-Language 用来告知服务器用户代理能够处理的自然

语言集(指中文或英文等),以及自然语言集的相对优先级。可一次

指定多种自然语言集。

和 Accept 首部字段一样,按权重值 q 来表示相对优先级。在上述图

例中,客户端在服务器有中文版资源的情况下,会请求其返回中文版

对应的响应,没有中文版时,则请求返回英文版响应。

Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

首部字段 Authorization 是用来告知服务器,用户代理的认证信息(证

书值)。通常,想要通过服务器认证的用户代理会在接收到返回的

401 状态码响应后,把首部字段 Authorization 加入请求中。共用缓存

在接收到含有 Authorization 首部字段的请求时的操作处理会略有差

异。

Expect

Expect: 100-continue

客户端使用首部字段 Expect 来告知服务器,期望出现的某种特定行

为。因服务器无法理解客户端的期望作出回应而发生错误时,会返回

状态码 417 Expectation Failed。

客户端可以利用该首部字段,写明所期望的扩展。虽然 HTTP/1.1 规

范只定义了 100-continue(状态码 100 Continue 之意)。

等待状态码 100 响应的客户端在发生请求时,需要指定 Expect:100-

continue。

From

首部字段 From 用来告知服务器使用用户代理的用户的电子邮件地

址。通常,其使用目的就是为了显示搜索引擎等用户代理的负责人的

电子邮件联系方式。使用代理时,应尽可能包含 From 首部字段(但

可能会因代理不同,将电子邮件地址记录在 User-Agent 首部字段

内)。

Host

图:虚拟主机运行在同一个 IP 上,因此使用首部字段 Host 加以

区分

Host: www.hackr.jp

首部字段 Host 会告知服务器,请求的资源所处的互联网主机名和端

口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请

求内的首部字段。

首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制

有很密切的关联,这是首部字段 Host 必须存在的意义。

请求被发送至服务器时,请求中的主机名会用 IP 地址直接替换解

决。但如果这时,相同的 IP 地址下部署运行着多个域名,那么服务

器就会无法理解究竟是哪个域名对应的请求。因此,就需要使用首部

字段 Host 来明确指出请求的主机名。若服务器未设定主机名,那直

接发送一个空值即可。

If-Match

形如 If-xxx 这种样式的请求首部字段,都可称为条件请求。服务器接

收到附带条件的请求后,只有判断指定条件为真时,才会执行请求。


©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,456评论 5 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,370评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,337评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,583评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,596评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,572评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,936评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,595评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,850评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,601评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,685评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,371评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,951评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,934评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,167评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 43,636评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,411评论 2 342

推荐阅读更多精彩内容