UNIT12 Hyper Text Transfer Protocol

起源于1960年美国人Ted Nelson文本信息处理的思想——hypertext，他被誉为HTTP之父。

RFC1945=HTTP1.0/1996年/描述：已过时,非持久连接,仅get, 仅HTML格式。

RFC2068=HTTP1.1/1997年/初步描述：代理服务器还在用, 非持久连接, Get+Post+Head,MIME,带版本头。

RFC2616=HTTP1.1/1999年/现行标准：持久连接, PUT+DELETE+TRACE, Caching,增加了Range、If-Range、Content-Range等头字段，可从服务器上获取指定资源的特定部分

HTTP-NG(Next Generation of HTTP)的建议已经提出

一、HTTP中的有关术语

Connection： 两个程序之间出于通信的目的而建立的传输层虚拟电路。

Message：HTTP通信中的基本单元。消息通过连接来传送，它由结构化的比特流组成。

Request：HTTP请求消息。

Response：HTTP响应消息。

Resource：可以用URI进行标识的网络数据对象或者服务（多种数据格式、分辨率等）。

Entity/实体：实体由元信息和内容组成，元信息entity-header fields中，而内容包含在entitybody正文中（对于响应而言其实体往往是用户下载的资源） 。

User agent：发起请求的浏览器、编辑器、遍历Web的robot、或其它终端工具。

Origin server：资源所驻留的服务器。

session:是客户与服务器之间的不中断的请求响应序列。

二、URI=protocal://host[: port]/path/name

每个Web服务器上有很多资源，为了让客户访问这些资源，首先要唯一性地标识这些资源。Unified Resource Identifier是对Internet上的资源进行命名的一种标准机制。Internet上的每个资源都可以用一个唯一的URI来标识。   

三、HTTP/1.1 Key Features(性能/安全/数据类型处理)

     客户向服务器请求服务时，只需传送请求方法(GET、HEAD、POST)和路径。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

1、MIME规范使HTTP协议不再局限于HTML文件

2、Content negotiation (DirectoryIndex index:cgi?html?)

   是指当资源存在（媒体类型、语言等）多种表现形式时，从中选择出一种最好形式的资源实体过程。该过程有两种实现途径：

3、相比HTTP1.0增加了更多的请求头和响应头

4、request/response based的C/S模式(四大阶段)

tcp连接:浏览器与Web服务器建立连接，socket虚拟文件的建立标志着连接建立成功。

http请求

http应答

tcp关闭连接，浏览器解析响应:当应答结束后，Web浏览器与Web服务器必须断开，以保证其他Web浏览器能够与Web服务器建立连接。

5、多个请求和响应过程可以重叠进行

6、Statefull有状态的=(Stateless+cookie|session)

HTTP协议是无状态协议，无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

由于时间推移，HTTP承载了各类现代应用，才不得不出现了基于状态的辅助技术，例如cookie,或者是session技术。

7、可扩充性

     HTTP协议中允许客户与服务器之间可以传输任意类型的数据对象，正在传输的类型由Content-Type等头字段加以标记。这样，基于HTTP协议的系统的构建与该系统中要传输的数据无关。

   另一方面，HTTP协议中的method和header等又是可扩充的。

8、HTTP1.1 Caching 3种缓存机制

新鲜度： 含有完整的过期时间和寿命控制头信息，并且内容仍在保鲜期内； 浏览器已经使用过缓存副本，并且在一个会话中已经检查过内容的新鲜度； 缓存代理服务器近期内已使用过缓存副本，且内容的最后更新时间在上次使用期之前； 够新的副本将直接从缓存中送出，而不会向源服务器发送请求。

验证： 用来检查是否一个缓存变得陈旧后响应仍然是好的。若副本已经太旧了，缓存服务器将向源服务器发出请求校验请求，用于确定是否可以继续使用当前拷贝继续服务。

失效： 通常是另一个请求经过高速缓存时的一种副作用。举个例子，如果一个缓存响应相关URL随后得到POST、PUT或DELETE请求,缓存的响应将失效。

9、connection reuse/keep-alive/长连接

conectioness的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。

persistent Connection，即每次连接可处理多个请求。

 

※12.2 HTTP/1.1 Persistent Connection

一、Persistent/Non-Persistent Connection

1、连接步骤

短连接的操作步骤是： 建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接

长连接的操作步骤是： 建立连接——数据传输...（保持连接）...数据传输——关闭连接

2、连接方式选择要视需求而定

长连接方式常用于P2P通信: 短连接多用于操作频繁，点对点的通讯，而且连接数不能太多的情况,每次操作下次操作时直接发送数据就可以了，不用再三次握手建立TCP连接。例如：数据库的连接用长连接，用短连接频繁的通信会造成socket错误，频繁的socket创建也是对资源的浪费。

短连接方式常用于一点对多点C/S通信: 像web网站这么频繁的成千上万甚至上亿客户端的连接用短连接更省一些资源。试想如果都用长连接，而且同时用成千上万的用户，每个用户都占有一个连接的话，可想而知服务器的压力有多大。所以并发量大，但每个用户又不需频繁操作的情况下需要短连接。

3、长连接与短连接

通讯实体间使用长连接，一般还需要定义心跳消息，定期发送来检测系统间链路是否异常，每隔一定时间发送一次心跳（有的系统如果接收到数据包则会清除心跳计时器也就相当于系统中的数据包也算作心跳消息），如果一定次数没有收到心跳消息，这认为此连接出现问题，需要断开连接重新建立。

二、HTTP Persistent Connection/connection reuse

HTTP/1.1所有的连接默认都是持续连接，除非特殊声明不支持。 Apache 2.0 httpd 的默认连接过期时间是仅仅15秒 ，对于 Apache 2.2 只有5秒。短的过期时间的优点是能够快速的传输多个web页组件，而不会绑定多个服务器进程或线程太长时间。

1、持久HTTP连接具有以下优势

通过打开和关闭更少的TCP连接，节省了路由和主机的CPU耗时，以及TCP协议控制阻塞使用的主机内存。

HTTP请求和响应可以在一个连接的基础上管道化。管道技术允许客户端发送多个请求而不用等待响应，使得TCP连接更加高效地使用从而更少的浪费时间。

减少了后续请求的延迟（无需再进行握手）

根据RFC 2616，用户客户端与任何服务器和代理服务器之间不应该维持超过2个链接。代理服务器应该最多使用2×N个持久连接到其他服务器或代理服务器以提高HTTP响应时间避免阻塞。

2、持久HTTP连接具有以下劣势

对单个文件被不断请求的服务(如图片存放网站)，Keep-Alive可能会极大的影响性能，因为它在文件被请求之后还保持了不必要的连接很长时间。

3、Web浏览器中的使用

Netscape不使用过时时间来关闭持久连接。当需要打开一个新的持久链接，但连接到不同的服务器上时，浏览器使用最近最少使用算法终止一个空闲的持久链接。

IE支持持久链接，IE 6和IE 7缺省使用2个持久链接，而IE 8缺省使用6个持久链接。持久链接在不活跃60秒后过时，可以在Windows注册表中修改。

Mozilla Firefox支持持久链接。可以定制同时的持久连接的最大个数（每个服务器，每个代理服务器，总数）。连接在不活跃300秒（5分钟）后过时（配置中可以修改）。

Opera 4.0开始支持持久链接.可以配置同时的持久连接的最大个数（每个服务器，总数）。

 

 

※12.3 HTTP/1.1 Session Track

常用的会话跟踪技术:Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

一、HTTP/1.1+COOKIE实现会话跟踪

1、Session内存Cookie/无过期时间;

Persistent硬盘Cookie/有过期时间

2、Cookie实现过程

由于HTTP是一种无状态的协议，服务器单从网络连接上无从知道客户身份。怎么办呢？就给客户端们颁发一个通行证吧，每人一个，无论谁访问都必须携带自己通行证。这样服务器就能从通行证上确认客户身份了。这就是Cookie的工作原理。

①Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。

②客户端浏览器会把Cookie保存起来。

③当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。

④服务器检查该Cookie，以此来辨认用户状态，从而完成验证，或继续上一步操作。

3、查看本地COOKIE

①用IECookiesView

②Internet选项→常规→设置”→查看文件，这些TXT文件通常以<用户名>@domain格式命名，domain是你访问过的网站域名。

4、调节本地COOKIE

①微软IE→Internet选项→隐私页:调节滑块或点击“高级”

②Firefox→选项→隐私（linux：编辑/属性/隐私）→Cookies

5、Session hijack(会话劫持)

二、HTTP/1.1+session+cookie实现会话跟踪

session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构(也可能就是使用散列表)来保存息。

由于在服务器端保持状态的方案在客户端也需要保存一个标识(session id，即服务器上session对象文件的名称，由服务器随机产生，避免在握手或传输中暴露用户真实密码)，所以session机制可能需要借助于cookie机制来达到保存标识的目的。

三、Session与Cookie比较

1、从存取方式上比较

Cookie只保存ASCII；Session中可以存取任何类型的数据。

2、隐私安全上比较

账号密码等尽量不要写到Cookie中，最好是像Google、Baidu那样将Cookie信息加密，提交到服务器后再进行解密。

而如果选择Session就省事多了，反正是放在服务器上，Session里任何隐私都可以。

3、从有效期上比较

如果登录过Google，用户很长时间内不必每次访问都重新登录，Cookie maxAge会长久地记录该用户的登录信息。

使用Session也能实现这种效果，但是如果设置Session的超时时间过长，服务器累计的Session就会越多导致内存溢出。

4、从对服务器的负担上比较

Session在服务器端的为每个用户都会产生一个Session。若并发用户非常多，会产生非常多的Session，消耗大量的内存。

而Cookie保存在客户端，不占用服务器资源。对于Google、Baidu、Sina来说，Cookie也许是唯一的选择。

5、从浏览器支持上比较(如果客户端支持Cookie)

Cookie: maxAge=1=本窗口以及子窗口内有效，maxAge>0所有窗口内有效。

Session:只能在本浏览器窗口以及其子窗口内有效。如果两个浏览器窗口互不相干，它们将使用两个不同的Session。

WAP无Cookie,Session+URL地址重写也许是它唯一的选择

6、从跨域名上比较

Cookie支持跨域名访问，例如将domain属性设置为“.ibm.com”，则以“.ibm.com”为后缀的所有域名均可以访问该Cookie。跨域名Cookie现在被广泛用在网络中，例如Google、Baidu、Sina等。而Session则不会支持跨域名访问。Session仅在他所在的域名内有效。

四、URL地址重写是对客户端不支持Cookie的解决方案

URL地址重写的原理是将该用户Session的id信息重写到URL地址中。服务器能够解析重写后的URL获取Session的id。这样即使客户端不支持Cookie，也可以使用Session来记录用户状态。

1、判断客户端是否支持Cookie。如果客户端支持Cookie，会将URL原封不动地输出来。

2、若客户不支持Cookie，则会将用户Session id重写到URL中。

例如：URL为“www.site.com/Profile/1.aspx”，那么它可以被重写成 “www.site.com/Profile.aspx?ID=1”这样的URL，这样的网址可以更好的被网站所阅读。

五、表单中隐藏域小结

隐藏域在页面中对于用户是不可见的，在表单中插入隐藏域的目的在于收集或发送信息，以利于被处理表单的程序所使用。浏览者单击发送按钮发送表单的时候，隐藏域的信息也被一起发送到服务器。

比如按一个按钮弹出四个小窗口，当点击其中的一个小窗口时其他三个自动关闭．可是IE不支持小窗口相互调用，所以只有在父窗口写个隐藏域，当小窗口看到那个隐藏域的值是close时就自己关掉。

 

※12.4 HTTP Packet Structure

一、HTTP Request Message的结构

与主机建立连接后，客户以请求方法，URI和版本的形式向服务器发送请求。

1、报文由三个部分组成

(开始行|请求行)+首部行+(实体主体,通常不用)

2、请求报文的类型是由它所采用的“方法”决定的

①GET方法：在浏览器的地址栏中输入网址的方式访问网页时，浏览器采用GET方法向服务器获取资源。

②POST方法：要求被请求服务器接受附在请求后面的数据，常用于提交表单。

③HEAD方法：它与GET方法几乎是一样的，对于HEAD请求的：

二、HTTP Response Messenger的结构

服务器用包括(协议版本+成功或错误代码)的状态应答。

1、开始行|状态行=(HTTP的版本+状态码+解释状态码的简单短语)

2、HTTP Status Code都是三位数字

1xx消息：请求已被服务器接收，继续处理(HTTP/1.1不支持) 这类响应是临时响应，代表的响应都是信息性的，标示客户应该采取的其他行动。

2xx成功：请求已成功被服务器接收、理解、并接受 这类状态码，代表请求已成功被服务器接收、理解、并接受。

3xx重定向：需要后续操作才能完成这一请求 这类状态码代表需要客户端采取进一步的操作才能完成请求。通常，这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的Location域中指明。

4xx请求错误：请求含有词法错误或者无法被执行

5xx服务器错误：服务器在处理某个正确请求时发生错误

三、HTTP Type of request packets（method definitions）

1、HTTP服务器至少应实现GET和HEAD，其他方法都是可选的。

OPTIONS：向Web服务器发送'*'的请求来测试服务器的功能性。

HEAD：要求服务器查找对象的元信息(响应体将不会被返回)。

GET：WEB服务器中获取对象，不同类型的对象将获取不同的信息，比如： • 文件类型对象，获取该文件的内容。 • 程序类型对象，获取该程序执行的结果。 • 数据库查询类型对象，获取该查询的结果。 (注意：GET可能会被网络蜘蛛等随意访问)

POST：从客户端向WEB服务器发送表单或者上传文件，数据被包含在请求体中。

PUT：在指明的URL下存储一个文档。

DELETE：删除指明的URL所标识的资源。

TRACE：请示服务器回送收到的请示，用来进行环回测试的请求报文。

CONNECT：用于代理服务器(HTTP/1.1)。

实际的做的时候，很多人却没有按照HTTP规范去做，比如说：

很多人贪方便，更新资源时用了GET，因为用POST必须要到FORM（表单）会麻烦一点。

对资源的增，删，改，查操作，其实都可以通过GET/POST完成，不需要用到PUT和DELETE

传统的Web MVC框架基本上只支持GET和POST两种HTTP方法。

2、GET和POST区别如下

①生成方式

get	直接在URL栏中输入URL;  网页中的超链接。 form中method为get;     form中method为空时，默认是get提交。
post	只知道有一种：form中method属性为post

②数据传送方式

get方式：表单数据存放在URL地址后面。所有get方式提交时HTTP中没有消息体。

post方式：表单数据存放在HTTP协议的消息体中以实体的方式传送到服务器。

③服务器获取数据方式

GET方式：服务器采用request.QueryString来获取变量的值。

POST方式：服务器采用request.Form来获取数据。

④传送的数据量

GET方式：数据量长度有限制，一般不超过2kb。因为是参数传递，且在地址栏中，故数据量有限制。

POST方式：适合大规模的数据传送。因为是以实体的方式传送的。

⑤安全性

GET方式：安全性差。因为是直接将数据显示在地址栏中，浏览器有缓冲，可记录用户信息。所以安全性低。

POST方式：安全性高。因为post方式提是将表单中的字段与值放置在HTTP HEADER内一起传送到ACTION所指的URL中，用户是看不见的。

⑥在用户刷新时

GET方式：不会有任何提示。

POST方式：会弹出提示框，问用户是否重新提交。

⑦安全及幂等

GET:访问浏览器认为是等幂的，就是一个相同的URL只有一个结果。所以，第二次访问的时候，如果URL字符串没变化，浏览器是，直接拿出了第一次访问的结果。

POST:浏览器认为POST的提交必定是有改变的，在URL后面加上 ？+new Date();使每次访问的URL字符串不一样的。

重要方法	安全？	幂等？
GET	是	是
DELETE	否	是
PUT	否	是
POST	否	否
PATCH	否	是

 

 

※

12.5 HTTP Header Fields

X、用FireFox扩展能帮你分析HTTP headers

HTTP头标有四类:普通头标、请求头标、响应头标、实体头标。

1、Firebug ：比如html,css,dom的察看与调试，网站整体分析

2、LiveHTTPHeaders是FireFox下的一个插件，可以用来实时监测发起的http请求和响应，也可修改请求参数之后重新发起请求。

根据我们目的的不同，LiveHttpHeaders有两种启动方法：当我们只想监视通信量的时候，可以从浏览器的“查看”菜单中选择“侧栏”菜单项，最后选择Live HTTP Headers/ Ctrl+Shift+L菜单项;如果要使用该工具全部特性的话，则需要通过单击“工具”菜单中的Live HTTP Headers项来打开它。

3、telnet www.baidu.com 80

GET /index.php HTTP/1.1     //粘贴此行后连按两次回车

一、General-Header Fields

通用头可用于请求消息和响应消息。

1、Cache-Control：用于指定在请求/响应链上所有缓存系统（机制）所必须遵循的指令。例如：服务器在响应消息中加上通用头“Cache-Control : no-cache”表示该响应不应该被缓存。含义如下：

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

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

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

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

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

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

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

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

3、Pragma：用于指定的特定实现的指令，这些指令将作用于请求/响应链上的所有接收者。例如：客户在请求消息中加上通用头“Pragma : no-cache”则表示要求任何一个中介系统将该请求前传到源服务器，即使中介系统中曾经缓存了该请求的响应。

4、Connection：供发送者指定连接的参数。例如：“Connection :

close”表示在一次请求/响应后关闭连接，即本次连接为非持久性连接。

二、Request-Header Fields

请求头标向服务器端传递请求的附加信息及客户端自身信息。

1、Accept：用于告诉服务器，客户支持的数据类型。

举个例子：Accept：image/gif，表明客户端希望接受GIF图像格式的资源；Accept：text/html，表明客户端希望接受HTML文本。

2、Accept-Charset：用于告诉服务器客户端受的字符集。举个例子：Accept-Charset:iso-8859-1,gb2312。如果在请求消息中没有设置这个域，缺省时任何字符集都可以接受。

3、Accept-Encoding：类似于Accept，但用于告诉服务端客户机所支持的数据压缩格式。举例：Accept-Encoding:gzip.deflate。如果请求消息中没设置这个域服务器，客户端可以接受所有格式。

4、Accept-Language：类似于Accept，但是用于客户端语言环境。举个例子：Accept-Language:zh-cn。如果请求消息中没有设置这个头标域，服务器假定客户端对各种语言都可以接受。

5、Authorization：主要用于证明客户端有权查看某个资源。当浏览器访问一个页面时，如果收到服务器的响应代码为401（未授权），可以发送一个包含Authorization请求头标域的请求，要求服务器对其进行验证。

6、Host（必需）：客户机通过这个头，告诉服务器，想访问的主机名和端口号，它通常从HTTP URL中提取出来的。举个例子：

http://www.nit.edu.cn/index.html，请求消息中会包含Host请求头标域，如：Host：www.nit.edu.cn，此处使用缺省端口号80。若指定了端口号，则变成：Host：www.nit.edu.cn:指定端口号。

7、User-Agent：客户机通过这个头告诉服务器客户机的软件环境。

录论坛的时候往往会看到一些欢迎信息，其中列出了你的操作系统的名称和版本、浏览器名称和版本等，实际上，服务器应用程序就是从User-Agent请求头标域中获取到的。如果编写一个浏览器不使用User-Agent头标域，服务器就无法得知我们的信息了。

8、If-Modified-Since：告诉服务器资源缓存的时间。

9、Referer：客户机通过这个头告诉服务器，它是从哪个资源来反问服务器的（防盗链）

三、Response-Header Fields

响应头标允许服务器传递不能放在状态行中的附加响应信息，以及关于服务器的信息和对Request-URI标识的资源进行下一步访问的信息。

1、Server：告诉浏览器服务器的类型与User-Agent请求头标域是相对应。Server响应头标域例子：Server：Apache-Coyote/1.1。

2、WWW-Authenticate：客户端收到401（未授权的）响应消息时候，发送Authorization头标域请求服务器对其进行验证时，服务端响应头标就包含该头标域。举个例子：WWW-Authenticate:Basic realm="Basic Auth Test!"，可以看出服务器对请求资源采用的是基本验证机制。

3、Location：配合302状态码使用告诉客户重新定位的资源路径。

4、Content-Encoding：告诉浏览器数据的压缩格式。

5、Content-Length：通过这个头告诉浏览器回送数据的长度。

6、Content-Type：服务器通过这个头告诉浏览器返回数据的类型。

7、Last-Modified：告诉浏览器当前资源缓存的时间。

8、Refresh：服务器通过这个头告诉浏览器多长时间刷新一次。

9、Expires：告诉浏览器缓存时间的长短。0，-1不缓存。

四、Entity-Header Fields

请求和响应消息都可以传送一个实体。一个实体由实体报头域和实体正文组成，但并不是说实体报头域和实体正文要在一起发送，可以只发送实体报头域。

实体报头定义了关于实体正文（eg：有无实体正文）和请求所标识的资源的元信息，如使用的编码格式。

1、Allow：服务器支持哪些请求方法（如GET、POST等）。

2、Content-Encoding：它的值指示了已经被应用到实体正文的附加内容的编码，因而要获得Content-Type头标域中所引用的媒体类型，必须采用相应的解码机制。因此Content-Encoding可用于记录文档的压缩方法。举个例子：Content- Encoding：gzip。

3、Content-Length：表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据，以字节方式存储的十进制数字来表示。

4、Content-Type：Content-Type实体头标域用于指明发送给接收者的实体正文的媒体类型。举个例子： Content-Type:text/html;charset= GB2312

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

6、Expires：为了让代理服务器或浏览器在一段时间以后更新缓存中的页面，我们可以使用Expires实体头标域指定页面过期的时间。举个例子：Expires：Thu，15 Sep 2010 16:23:12 GMT。HTTP/1.1的客户端和缓存必须将其他非法的日期格式（包括0）看作已经过期。举个例子：为了让浏览器不要缓存页面，我们也可以利用Expires实体头标域，设置为0，jsp中的程序如下：response.setDateHeader("Expires","0")。

7、Last-Modified：文档的最后改动时间。客户可以通过If-Modified-Since请求头提供一个日期，该请求将被视为一个条件GET，只有改动时间迟于指定时间的文档才会返回，否则返回一个304（Not Modified）状态。

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

9、Refresh：“N秒之后刷新本页面或访问指定页面”，而不是“每隔N秒刷新本页面或访问指定页面 ”。Refresh头不属于HTTP 1.1正式规范的一部分，而是一个扩展，但Netscape和IE都支持它。

10、Content-Language：描述了资源所用的自然语言。没有设置该域则认为实体内容将提供给所有的语言阅读者。举个例子：Content-Language:da。

X、扩展头

在HTTP消息中，也可以使用一些在HTTP 1.1正式规范里没有定义的头字段，这些头字段统称为自定义的HTTP头或扩展头，它们通常被当作是一种实体头处理。现在流行的浏览器实际上都支持Cookie、Set-Cookie、Refresh和Content-Disposition等几个常用的扩展头字段。