Http

叶繁终唯枯
389 阅读26分钟

HTTP请求

HTTP协议，即超文本传输协议（Hypertext transfer protocol）。是一种详情规定了浏览器和万维网（WWW=World Wide Web）服务器之间互相通信的规则，通过因特网传送万维网文档的数据传送协议。

HTTP协议是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示（如文本优先图形）等。

HTTP是一个应用层协议，由请求头构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。

在Internet中所有的传输都是通过TCP/IP进行的。HTTP协议作为TCP/IP模型中应用层的协议也不例外。HTTP协议通常承载于TCP协议之上，有时也承载于TLS或SSL协议层之上，这时候就成了我们常说的HTTPS。

image.png

HTTP默认的端口号为80，HTTPS的端口号为443。

浏览网页是HTTP的主要应用。HTTP是一种协议，只要通信的双方都遵守这个协议，HTTP就能有用武之地。

HTTP 首部字段

HTTP的报文种类

HTTP有两类报文：

  • 请求报文——从客户向服务器发送请求报文。

  • 响应报文——从服务器到客户的回答。

    HTTP的报文结构

    请求报文

    报文由三个部分组成，即开始行（首行）、首部（Header）和实体主体（Body）。在请求报文中，开始行就是请求行。

    • 开始行：

image.png

image.png

image.png

方法

  • HTTP1.0定义了三种请求方法：GET、POST、HEAD。

  • HTTP1.1新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE和CONNECT方法。

    方法描述
    GET请求指定的页面信息，并返回实体主体
    HEAD类式于GET请求，只不过返回的响应中没有具体的内容，用户获取报头
    POST向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
    PUT从客户端向服务器传送的数据取代指定的文档的内容。
    DELETE请求服务器删除指定的页面
    CONNECTHTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。
    OPTIONS允许客户端查看服务器的性能。
    TRACE回显服务器收到的请求，主要用于测试或诊断。
    是对PUT方法的补充，用来对已知资源精心局部更新。

    GET和POST的区别

    GETPOST
    请求方式在HTTP消息主体中发送
    缓存可被缓存不可被缓存
    书签可收藏为书签不可收藏为书签
    历史记录参数保留在浏览器历史中参数不会保存在浏览器历史中
    幂等性幂等非幂等
    • GET和POST都是http请求方式，底层都是TCP/IP协议。通常GET产生一个TCP数据包；POST产生两个TCP数据包（但firefox是发送一个数据包）。

  • 对于GET方式的请求，浏览器胡巴http header和data一并发送出去，服务器响应200（返回数据）表示成功。

    • 对于POST，浏览器先发送header，服务器响应100，浏览器再继续发送data，服务器响应200（返回数据）。

image.png

状态行：报文协议及版本+状态码以及状态描述。

格式为：HTTP-Version Status-Code Reason-Phrase CRLF。其中HTTP-Verison表示服务器HTTP协议的版本；Status-Code表示服务器发回的响应状态代码。Resion-Phrase表示状态代码的文本描述。状态代码由三位数字组成，第一个数字定义了响应的类别，且有5中可能取值。

HTTP状态码

HTTP状态码是用于表示web服务器响应状态的3位数字代码。

状态码说明
0(未初始化)还没有调用send()方法
1XX指示信息——表示请求已接受，继续处理
2XX成功——表示请求已被成功接收、理解、接受。
3XX重定向——要完成请求必须进行更进一步的操作。
4XX客户端错误——请求有语法错误或请求无法实现。
5XX服务器端错误——服务器未能试下合法的请求。

状态码为0原因：

  • 非法的跨域请求
  • 防火墙的过滤拦截
  • 请求本身在代码中被取消了
  • 浏览器的扩展插件导致了这个问题存在

常见状态码：

200——服务器成功返回网页。

404——请求的网页不存在。对于服务器上不存在的网页经常会返回此代码。

401——未授权。请求要求身份验证。对于登录后请求的网页，服务器可能返回此响应。

403——禁止。服务器拒绝请求。

500——服务器内部错误。服务器遇到错误，无法完成请求。

502——错误网关。服务器作为网关或代理，从上游服务器收到无效响应。

503——服务器不可用。服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。

504——网关超时。服务器作为网关或代理，但是没有及时从上游服务器收到请求。

505——HTTP版本不受支持。服务器不支持请求中所用的HTTP协议版本。

**响应头**

和请求头报文的请求头类似，响应头也由键值对组成，每行一对，键和值用英文冒号（:）分割。响应头域允许服务器传递不能放在状态行的附加信息，这些域主要描述服务器信息和Request）URI进一步的信息。

image.png 空行

作为内容分割，表示一下不再是响应头的内容。

响应体

这个是服务器返回给浏览器的响应信息。

image.png

HTTP首部字段传递重要信息

HTTP首部字段是构成HTTP报文的要素之一。在客户端与服务端之间以HTTp协议进行通信的过程中，无论是请求还是响应都会使用首部字段，它能起到传递额外重要信息的作用。

使用首部字段是为了给浏览器和服务器提供报文主体大小、所使用的语言、认证信息等内容。

HTTP首部字段结构

 首段字段名：字段值

例如：在HTTP首部中以Content-Tpye这个字段来表示报文主体的对象类型。另外，字段值对应单个HTTP首部字段可以有多个值。

 Content-Type:text/html
 Kee-Alive:timeout=15,max=100

问：如果HTTP首部字段重复了会怎样？

答：当HTTP报文首部中出现了两个或者两个以上具有相同首部字段名时会怎样，规范中未明确，

HTTP/1.1首部字段

通用首部字段

首部字段名说明
Cache-Control控制缓存的行为
Connection逐跳首部、连接的管理
Data创建报文的日期时间
Pragma报文指令
Trailer报文末端的首部一览
Transfer-Encoding指定报文主体的传输编码方式
Upgrade升级为其他协议
Via代理服务器的相关信息
Warning错误通知

请求首部字段

首部字段名说明
Accept用户代理可处理的媒体类型
Accept-Charset优先的字符集
Accept-Encoding优先的内容编码
Accept-Language优先的语言（自然语言）
AuthorzationWeb认证信息
Expect期待服务器的特定行为
From用户的电子邮箱地址
Host请求资源所在服务器
If-Match比较实体标记（ETag）
If-Modified-Since比较资源的更新时间
If-None-Match比较实体标记（与If-Match相反）
If-Range资源未更新时发送实体Byte的范围请求
If-Unmodified-Since比较资源的更新时间（与If-Modified-Since相反）
Max-Forwards最大传输逐跳数
Proxy-Authorization代理服务器要求客户端的认证信息
Range实体的字节范围请求
Referer请求中URI的原始获取方
TE传输编码的优先级
HTTP客户端程序的信息

响应首部字段

首部字段名说明
Accept-Ranges是否接受字节范围请求
Age推算资源创建经过时间
ETag资源的匹配信息
Location令客户端重定向至URI
Proxy-Authenticate代理服务器对客户端的认证信息
Retry-After对再次发起请求的时机要求
ServerHTTP服务器的安装信息
Vary代理服务器缓存的管理信息
WWW-Authenticate服务器对客户端的认证信息

实体首部字段

首部字段名说明
Allow资源可支持的HTTP方法
Content-Encoding实体主体适用的编码方式
Content-Language实体主体的自然语言
Content-Length实体主体的大小（单位：字节）
Conent-Location代替对应资源的URI
Content-MD5实体主体的报文摘要
Content-Type实体主体的媒体类型
Expires实体主体过期的日期时间
Last-Modified资源的最后修改日期时间

非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 和之后版本中，如果要使用top-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: private, max-age=0, no-cache•

    缓存请求指令

    指令参数说明
    no-cache无强制向资源服务区再次验证
    no-store无不缓存请求或响应的任何内容
    max-age=[秒]必需响应的最大Age值
    max-stale（=[秒]）可省略接受已过期的响应
    min-fresh=[秒]必需期望在指定时间内的响应仍有效
    no-transform无从缓存获取资源
    only-if-cached无从缓存获取资源
    cache-extension-新指令标记

    缓存响应指令

指令参数说明
public无可向任意方提供响应的缓存
private可省略仅向特定用户返回响应
no-cache可省略缓存前必须先确认其有效性
no-transform无代理不可更改媒体类型
must-revalidate无可缓存但必需再向源服务器进行确认
proxy-revalidata无要求中间缓存服务器对缓存的响应有效性再进行确定
max-age=[秒]必需响应的最大Age值
s-maxage=[秒]必需公共缓存服务器响应的最大Age值
cache-extension-新指令标记（token）

Connection

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

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

  • 管理持久连接

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

    在客户端发送请求和服务器返回响应内，使用Connection首部字段，可控制不再转发给代理的首部字段（即Hop-by-hop首部）。

    2、管理持久连接

     Connection: close

    HTTP/1.1版本的默认连接而都是持久连接。为此客户端会在持久连接上连续发送请求。当服务器端想明确断开连接时，则指定Connection首部字段的值为Close。

     Connection: Keep-Alive　

    HTTP/1.1之前的HTTP版本的默认连接都是非持久连接。为此，如果想在旧版本的HTTP协议上维持连接，则需要指定Connection首部字段的值为Keep-Alive。

image.png

上图所示，①客户端发送请求给服务器时，服务器端会像②那样加上首部字段keep-alive及首部字段Connection后返回响应。

Date首部字段

Date表明创建HTTP报文的日期和时间。

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

Transfer-Encoding

首部字段Transfer-Encoding规定了传输报文主体时采用的编码方式。

 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字节分块数据...

以上用例中，正如在首部字段Transfer-Encoding中指定的那样，有效使用分块传输编码，且分别被分成3312字节和914字节大小的分块数据。

Warning

HTTP/1.1的Warning首部是从HTTP/1.0的响应首部（Retry-After）演变过来的。该首部通常会告知用户一些与缓存相关的问题的警告。

Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03 Jul 2012 05:09:44 GMT

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

Warning: [警告码][警告的主机:端口号]“[警告内容]”([日期时间])​
警告码警告内容说明
110Response is stale（响应已过期）代理返回已过期的资源
111Revalidation failed（再验证失败）代理在验证资源有时效性时失败（服务器无法到达等原因）
112Disconnection operation（断开连接操作）代理与互联网连接被故意切断
113Heuristic exporation(试探性过期)响应的试用期超过24小时（有效缓存的设定时间大于24小时的情况下）
199Miscellaneous warning(杂项警告)任意的警告内容
214Transformation applied（使用了转换）处理对内容编码或每天类型等执行了某些处理时
299Miscellaneous persistent warning(持久杂项警告)任意的警告内容

请求首部字段

请求首部字段是从客户端往服务器端发送请求报文中所使用的字段，用于补充请求的附加信息、客户端信息、对响应内容相关的优先级等内容。

Accept

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

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等图片类型。若想要给显示的媒体类型增加优先级，则使用q=来额外表示权重值1，用分号（;）进行分隔。权重值q的范围是0~1（可精确到小数点后3位），且1为最大值。不指定权重q值时，默认权重为q=1.0。

Accept-Charset

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

Accept-Chartset首部字段可用来通知服务器用户代理支持的字符集及字符集的相对优先顺序。另外，可一次性指定多个字符集。与首部字段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 相同。另外，也可使用星号（*）作为通配符，指 定任意的编码格式。

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

Host: www.hackr.jp​

首部字段 Host 会告知服务器，请求的资源所处的互联网主机名和端口号。Host 首部字段在 HTTP/1.1 规范内是唯一一个必须被包含在请求内的首部字段。 ​ 首部字段 Host 和以单台服务器分配多个域名的虚拟主机的工作机制有很密切的关联，这是首部字段 Host 必须存在的意义。

Range

Range: bytes=5001-10000​

对于只需获取部分资源的范围请求，包含首部字段 Range 即可告知服务器资源的指定范围。上面的示例表示请求获取从第 5001 字节至第 10000 字节的资源。

User-Agent

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1

首部字段 User-Agent 会将创建请求的浏览器和用户代理名称等信息传达给服务器。 ​ 由网络爬虫发起请求时，有可能会在字段内添加爬虫作者的电子邮件地址。此外，如果请求经过代理，那么 中间也很可能被添加上代理服务器的名称。

响应首部字段

服务器字段是由服务器端向客户端返回响应报文中所使用的字段，用户补充响应的附加信息、服务器信息，以及对客户端附加要求等信息。

Accept-Ranges

当不能处理范围请求时，Accept-Ranges: none。

Accept-Ranges: bytes​

首部字段 Accept-Ranges 是用来告知客户端服务器是否能处理范围请求，以指定获取服务器端某个部分的资源。 ​ 可指定的字段值有两种，可处理范围请求时指定其为 bytes，反之则指定其为 none。

Age

Age:600

首部字段 Age 能告知客户端，源服务器在多久前创建了响应。字段值的单位为秒。 ​ 若创建该响应的服务器是缓存服务器，Age 值是指缓存后的响应再次发起认证到认证完成的时间值。代理创 建响应时必须加上首部字段 Age。

Content-Disposition

Content-disposition（内容-部署）是MIME协议类型的扩展，MIME协议指示MIME用户代理如何显示附加的文件。

Content-Dispositon

Content-disposition是MIME协议的扩展，MIME协议指示MIME用户代理如何显示附加的文件。当Internet Explorer接收到头时，他会激活文件下载对话框，它的文件名框自动填充headers指定的文件名。

服务器向浏览器发送文件时，如果是浏览器支持的文件类型，一般会默认使用浏览器打开，比如txt，jpg等。如果需要提示用户保存，就要利用Content-Disposition进行处理，关键在于一定要加上attachment [附件] [attachment ]`

Response.AppendHeader("ContentDisposition","attachment;filename=FileName.txt");

这样的话，浏览器在打开的时候回提示保存还是打开，及时选择打开，也会使用相关联的程序，比如记事本打开，而不是IE直接打开。

作为消息体中的消息体

在HTTP场景中，第一个参数或者是inline （默认值，表示回复中的消息体会以页面的一部分或者整个页面的形式展开），或者是attachment (意味着消息体应该被下载到本地；大多数浏览器会呈现一个“保存为”的对话框，将filename 的值预填为下载后的文件名，假如它存在的话)。

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"

作为multipart body中的消息头

在HTTP场景中。第一个参数总是固定不变的form-data ；附加的参数不区分大小写，并且拥有参数值，参数名与参数值用等号（‘=’）连接，参数值用双引号括起来。参数之间用分号（‘;’）分割。

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"

指令

name

后面是一个表单字段名的字符串，没一个字段名会对应一个子部分。在同一个字段名对应多个文件的情况下（例如：带有multiple 属性的<input type='file'> 元素），则对个子部分共同用一个字段名。如果name参数的值为_charset_ ,意味着这个子部分表示的不是一个HTML字段，而是在为明确指定字符集信息的情况下各部分使用的默认字符集。

filename

后面是要传送的文件的初始名称的字符串。这个参数总是可选的，而且不能盲目使用：路径信息必须舍掉，同时要进行一定的转换以符合服务器文件系统规则。这个参数主要用来提供展示性信息。当与Content-Disposition：attachment 一同使用的时候，它被作用“保存为”对话框中呈现给用户的默认文件名。

filename*

“filename”和“filename ”两个参数的唯一区别在于，“filename”采用了RFC 5987 中规定的编码方式。当 "filename" 和 "filename" 同时出现的时候，应该优先采用 "filename*"，假如二者都支持的话。

兼容性说明

  • 在 filename 和 filename* 两个参数同时出现的情况下，Firefox 5（比以前的版本）可以更好地处理 Content-Disposition 应答消息头。它会遍历所有提供的名称，假如 filename* 存在的话，就采用它的值，即使 filename 更靠前。之前的版本会采用出现在前面的参数的值，导致有更合适的名称而不被使用。参见bug 588781.

实体部分字段

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部，用户补充内容的更新时间等与实体相关的信息。

Allow

Allow: GET, HEAD​

首部字段 Allow 用于通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持 的 HTTP 方法时，会以状态码 405 Method Not Allowed 作为响应返回。与此同时，还会把所有能支持的 HTTP 方法写入首部字段 Allow 后返回。

Content-Encoding

Content-Encoding: gzip

首部字段 Content-Encoding 会告知客户端服务器对实体的主体部分选用的内容编码方式。内容编码是指在不 丢失实体信息的前提下所进行的压缩。

主要采用以下 4 种内容编码的方式。（各方式的说明请参考 6.4.3 节 Accept-Encoding 首部字段）。

  • gzip
  • compress
  • deflate
  • identity

Content-Language

Content-Language: zh-CN

首部字段 Content-Language 会告知客户端，实体主体使用的自然语言（指中文或英文等语言）。

Content-Length

Content-Length: 15000

首部字段 Content-Length 表明了实体主体部分的大小（单位是字节）。对实体主体进行内容编码传输时，不 能再使用 Content-Length 首部字段。由于实体主体大小的计算方法略微复杂，所以在此不再展开。

Content-Location

Content-Location: http://www.hackr.jp/index-ja.html​

首部字段 Content-Location 给出与报文主体部分相对应的 URI。和首部字段 Location 不同，ContentLocation 表示的是报文主体返回资源对应的 URI。

比如，对于使用首部字段 Accept-Language 的服务器驱动型请求，当返回的页面内容与实际请求的对象不同 时，首部字段 Content-Location 内会写明 URI。（访问 www.hackr.jp/ 返回的对象却是 www.hackr.jp/index-ja.ht… 等类似情况）

Content-MD5

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==

首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于检查报文主体在传输过程中是否保持完 整，以及确认传输到达。

Content-Range

Content-Range: bytes 5001-10000/10000

针对范围请求，返回响应时使用的首部字段 Content-Range，能告知客户端作为响应返回的实体的哪个部分 符合范围请求。字段值以字节为单位，表示当前发送部分及整个实体大小。

Content-Type

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

首部字段 Content-Type 说明了实体主体内对象的媒体类型。和首部字段 Accept 一样，字段值用 type/subtype 形式赋值。 ​ 参数 charset 使用 iso-8859-1 或 euc-jp 等字符集进行赋值。

为Cookie 服务的首部字段

管理服务器与客户端之间状态的 Cookie，虽然没有被编入标准化 HTTP/1.1 的 RFC2616 中，但在 Web 网 站方面得到了广泛的应用。 ​ Cookie 的工作机制是用户识别及状态管理。Web 网站为了管理用户的状态会通过 Web 浏览器，把一些数据 临时写入用户的计算机内。接着当用户访问该Web网站时，可通过通信方式取回之前发放的 Cookie。

为Cookie服务的首部字段

首部字段名说明首部类型
Set-Cookie开始状态管理所使用的Cookie信息响应首部字段
Cookie服务器接收到的Cookie信息请求首部字段

Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;​

当服务器准备开始管理客户端的状态时，会事先告知各种信息。 ​ 下面的表格列举了 Set-Cookie 的字段值。

Set-Cookie 字段的属性

属性说明
NAME=value赋予Cookie的名称和其值（必须项）
expires=DATECookie的有效期（若不明确指定则默认为浏览器关闭前为止）
path=PATH将服务器上的文件目录作为Cookie的适用对象（若不指定则默认为文档所在的文件目录）
damain=域名作为Cookie适用对象的域名（若不指定则默认为创建Cookie的服务器的域名）
Secure仅在HTTPS安全通信是才会发送Cookie
HtppOnly加以限制，使Cookie不能被JavaScript脚本访问

expires 属性

Cookie 的 expires 属性指定浏览器可发送 Cookie 的有效期。 ​ 当省略 expires 属性时，其有效期仅限于维持浏览器会话（Session）时间段内。这通常限于浏览器应用程序被关闭之前。 ​ 另外，一旦 Cookie 从服务器端发送至客户端，服务器端就不存在可以显式删除 Cookie 的方法。但可通过覆盖已过期的 Cookie，实现对客户端 Cookie 的实质性删除操作。

Cookie

Cookie: status=enable

首部字段 Cookie 会告知服务器，当客户端想获得 HTTP 状态管理支持时，就会在请求中包含从服务器接收到的 Cookie。接收到多个 Cookie 时，同样可以以多个 Cookie 形式发送。

其他首部字段

HTTP首部字段是可以自行扩展的。所以在web服务器和浏览器的应用上，会出现各种非标准的首部字段。

avatar
文章
阅读
粉丝