前言

前不久，受领导所托，为部门的应届毕业生做了一次HTTP协议基础的培训，记录下来，时刻提醒自己基础才是最重要的。不过缺少https的部分，后期会补上。

一、HTTP网络协议栈

HTTPS网络协议栈

四、请求方法

get 获取某个资源

head 服务器在响应中只返回头部，不返回响应体

put 向服务器写入文档，如果文档已存在则替换它。有安全问题，所以大部分web服务器禁止响应该方法，或者要求用户输入密码
post 向服务器提交数据，如提交表单

trace 响应主体中携带它受到的原始请求报文

options 返回响应头allow:get,post 表示web服务服务器支持哪几种请求方法

delete 删除资源，客户端无法保证删除程序一定会执行，http协议允许服务器在不通知客户端的情况下撤销请求

五、状态码

（1）100-199 信息性状态码

目前仅定义了100、101

http1.1新增的状态码

100 说明收到了请求的初始部分，请客户端继续。

101 转换协议，说明服务器正在根据客户端的制定，将协议转换成update首部所列的协议

（2）200-299 成功状态码

目前仅定义了200-206

（3）300-399 重定向状态码

目前仅定义了300-307

300 Multiple Choices 客户端请求的URL指向多个资源时，服务器会返回该状态码

301 Moved Permanently 请求的资源已被移除。响应的location头部中应该包含该资源现在对应的URL方便客户端重新请求

302 Found 与301类似，表示客户端可以使用location中的URL临时定位资源，但是将来的请求依旧要使用老URL

304 Not Modified 表示客户端请求的资源没被修改过，服务器不会返回响应体。

（4）400-499 客户端错误状态码

目前仅定义了400-417

400 Bad Request 客户端发送了一个错误的请求

403 Forbidden 请求被服务器拒绝，可在响应体部分说明拒绝原因，但是通常这个状态码是在服务端不想说明原因时使用的

404 Not Found 资源没找到

405 Method Not Allowed 请求的URL不支持请求方法，通常返回该状态码的响应中应该包含Allow首部，指明该资源支持的请求方法。

408 Requet Timeout 客户端完成请求所花的时间太长，服务器可返回该状态码并关闭链接

（5）500-599 服务器错误状态码

目前仅定义了500-505

500 Internal Server Error 服务器遇到一个妨碍他为请求提供服务的错误时，响应该状态码

六、首部

从HTTP1.0开始，HTTP协议开始定义首部。

（1）通用首部

Cache-Control: no-cache

Cache-Control: max-age=0

Date: Sun, 20 Jul 2014 05:50:26 GMT

Transfer-Encoding: chunked 对报文主体执行过的编码的列表

（2）实体首部：

Content-Type: application/x-javascript

Content-Length: 2939

（3）请求首部

Accept: */*, text/*, image/gif, image/jpeg,text/css,text/html,application/xhtml+xml,application/xml; q=1

q值（质量值）：内容协商。用于表明客户端的偏好。某一资源服务器如果有多个版本，该值可向服务器表明客户端希望接受哪个版本。

Accept-Charset : utf-8

Accept-Language: zh-CN,zh;q=0.8,en;q=0.6

Accept-Encoding: gzip,deflate,sdch

If-Modified-Since: Thu, 03 Jul 2014 07:55:56 GMT

If-None-Match: "11e92a-457b-31345aa"

User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/36.0.1985.125 Safari/537.36

Referer: http://appmail.mail.10086.cn/mpost2014/html/indexrecommend.html

Connection: keep-alive

HTTP1.1停止了对keep-alive连接的支持，用持久链接改进了工作机制，与1.0的keep-alive不同的是，HTTP1.1的持久链接在默认情况下是激活的，除非应用程序在报文头中添加头部connection:close要求事物处理结束之后关闭连接。在以前的版本中，keep-alive要么是可选的要么就不支持。

关于connection：close:

请求头中添加了该头部，浏览器就不会再用该链接发送其他请求，换言之，如果客户端不希望用这条连接发送其他请求，请在最后一条请求中携带该头部.

Host: appmail.mail.10086.cn:80

Cookie: OUTFOX_SEARCH_USER_ID=-317159478@10.120.182.11; YNOTE_FORCE=true;

Max-Forward: 5 只能与请求方法TRACE一起使用，自定请求所经过的代理或其他中间节点的最大数目

Pragma:no-cache 

（4）响应首部

Allow: get, post, head

Content-Encoding: gzip

Expires: Mon, 21 Jul 2014 05:14:57 GMT

ETag: "11e92a-457b-31345aa"

Last-Modified: Thu, 03 Jul 2014 07:55:56 GMT

Server: nginx

Set-Cookie: RMKEY=;Path=/;Domain=mail.10086.cn;Max-Age=0;HTTPOnly

（5）扩展首部

X-Forwarded-For: 64.95.76.161 代理服务器用这个首部说明某条请求都被转发给了谁

作业：

一、问答题：

（1）139邮箱资源服务器与缓存相关的响应首部是怎么配置的？

（2）登录139邮箱web2.3，在浏览器有缓存的情况下，刷新页面，浏览器会不会重新发送请求获取静态资源？如果会，请列出与缓存相关的请求首部以及响应状态码；如果不会，请说明原因。

（3）请指出Cache-Control与Expires的区别

（4）新功能上线后，如何清空浏览器的缓存，让用户获取最新的资源文件？

问题1、问题2 可用Fiddler抓包然后截图说明。