Web站点开发，主要是http协议的运用，其中最主要最通用的一个功能就是用户认证，这又涉及cookie和session，所以需要搞懂搞透。
HTTP协议
1、Web客户端和服务器
Web内容存储在Web服务器上，Web服务器使用HTTP协议（应用层），所以被称为HTTP服务器。HTTP客户端向服务器端发出请求（HTTP请求），服务器端在HTTP响应中回送所请求的数据。客户端一般是各种浏览器。
2、资源
Web服务器是Web资源（Web resource）的宿主。Web资源是Web内容的源头。最简单的Web资源就是Web服务器文件系统中的静态文件。 但资源不一定非得是静态文件。资源还可以是根据需要生成内容的软件程序。
3、媒体类型（MIME）
网上有数千种不同的数据类型，HTTP给每种要通过Web传输的对象打上了名为MIME类型（MIME type）的数据格式标签。Web服务器会为所有HTTP对象数据附加一个MIME类型，当浏览器从服务器取回一个对象时，会去查看相关的MIME类型，以确定是否知道该如何处理这个对象。MIME类型是一种文本标签，表示一种主要的对象类型和一个特定的子类型，中间由一条斜杠分隔：
- HTML格式的文本文档：text/html类型标记
- 普通ASCII文本文档：text/plain类型标记
- JPEG图片：image/jpeg类型标记
- GIF图片：image/gif类型标记
- QuickTime电影：video/quicktime类型标记
- PowerPoint文件：application/vnd.ms-powerpoint类型标记
4、URI
服务器资源名被称为统一资源标识符（Uniform Resource Identifier， URI）。如http://www.baidu.com/image/dog.gif。URI 有两种形式， 分别称为 URL 和 URN。
统一资源定位符（URL） 是资源标识符最常见的形式。 URL 描述了一台特定服务器上某资源的特定位置。大部分 URL 都遵循一种标准格式， 这种格式包含三个部分。
• URL 的第一部分被称为方案（scheme）， 说明了访问资源所使用的协议类型。 这部分通常就是 HTTP 协议（http://）。
• 第二部分给出了服务器的因特网地址（比如， www.jbaidu.com）。
• 其余部分指定 Web 服务器上的某个资源（如 /image/dog.gif，这个可以类别linux的绝对路径）。
统一资源名（URN）是作为特定内容的唯一名称使用的， 与目前的资源所在地无关。使用与位置无关的 URN， 就可以将资源四处搬移。 通过 URN， 还可以用同一个名字通过多种网络访问协议来访问资源。如，不论因特网标准文档 RFC 2141位于何处（甚至可以将其复制到多个地方），都可以用下列 URN 来命名它：
urn:ietf:rfc:2141
URN 需要一个支撑架构来解析资源的位置。处于试验阶段。
5、事物
客户端通过 HTTP 与 Web 服务器及其资源进行事务处理，一个 HTTP 事务由一条（从客户端发往服务器的） 请求命令和一个（从服务器发回客户端的） 响应结果组成。 这种通信是通过名为HTTP 报文（HTTP message）的格式化数据块进行的。
我们需要重点了解的就是这种报文的格式。
6、方法
HTTP 支持几种不同的请求命令， 这些命令被称为 HTTP 方法（HTTP method）。 每条 HTTP 请求报文都包含一个方法。 这个方法会告诉服务器要执行什么动作（获取一个 Web 页面、 运行一个网关程序、 删除一个文件等）。我们最常见的就是GET和POST。
7、状态码
每条 HTTP 响应报文返回时都会携带一个状态码。 状态码是一个三位数字的代码，告知客户端请求是否成功， 或者是否需要采取其他动作。常见的有200：OK，文档正确返回；302：Redirect（重定向）；404：Not Found（没找到）；
8、Web页面中可以包含多个对象
一个页面通常需要多个事物来完成，如包含图片等的页面，浏览器会执行一个事务来获取描述页面布局的 HTML“框架”， 然后发布另外的 HTTP 事务来获取每个嵌入式图片、 图像面板、 Java 小程序等。 这些嵌入式资源甚至可能位于不同的服务器上。
9、报文
HTTP 报文是由一行一行的简单字符串组成的。 HTTP 报文都是纯文本， 不是二进制代码。
从 Web 客户端发往 Web 服务器的 HTTP 报文称为请求报文（request message）。 从服务器发往客户端的报文称为响应报文（response message）， 再无其他类型的HTTP 报文。
HTTP 报文包括以下三个部分：
• 起始行
报文的第一行就是起始行， 在请求报文中用来说明要做些什么， 在响应报文中说明出现了什么情况。
• 首部字段
起始行后面有零个或多个首部字段。 每个首部字段都包含一个名字和一个值， 为了便于解析， 两者之间用冒号（:） 来分隔。 首部以一个空行结束。 添加一个首部字段和添加新行一样简单。
• 主体
空行之后就是可选的报文主体了， 其中包含了所有类型的数据。 请求主体中包括了要发送给 Web 服务器的数据； 响应主体中装载了要返回给客户端的数据。 起始行和首部都是文本形式且都是结构化的， 而主体则不同， 主体中可以包含任意的二进制数据（比如图片、 视频、 音轨、 软件程序）。 当然， 主体中也可以包含文本。
HTTP报文
报文的组成部分：HTTP报文是简单的格式化数据块。请求报文和响应报文都由三部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。
起始行和首部就是由行分隔的 ASCII 文本。 每行都以一个由两个字符组成的行终止序列作为结束， 其中包括一个回车符（ASCII 码 13） 和一个换行符（ASCII 码 10）。这个行终止序列可以写做 CRLF。
实体的主体或报文的主体（或者就称为主体） 是一个可选的数据块。 与起始行和首部不同的是， 主体中可以包含文本或二进制数据， 也可以为空。
报文的语法：
请求报文格式：
响应报文的格式：
其中：method，即方法，我们常见的就是GET、POST；request-URL，即请求URL；version，即版本，格式是HTTP/<major>.<minor>，现在通常是HTTP/1.1；status，即状态码，三位数字描述请求过程中所发生的的情况；reson-phrase，即原因短语；headers，即首部，可以有零个或多个首部，每个首部都包含一个名字， 后面跟着一个冒号（:）， 然后是一个可选的空格， 接着是一个值， 最后是一个 CRLF。 首部是由一个空行（CRLF） 结束的， 表示了首部列表的结束和实体主体部分的开始。 HTTP/1.1， 要求有效的请求或响应报文中必须包含特定的首部；entity-body，即实体的主体部分，包含一个由任意数据组成的数据块。 并不是所有的报文都包含实体的主体部分， 有时， 报文只是以一个 CRLF 结束。
一个请求、响应的过程描述：
创建一个bottle架构的http服务器，httpdaemon.py：
from bottle import template, Bottle,request,response,TEMPLATE_PATH
import os
root = Bottle()
TEMPLATE_PATH.insert(0, os.path.abspath(os.path.join(os.path.dirname(__file__), "templates")))
@root.route('/login/')
# 装饰器，定义了URL，即/login/这个url由login这个函数来处理，就是路由系统
def login():
return template("login.html")
root.run(host='localhost', port=8090)模板文件login.html：
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>Title</title>
</head>
<body>
<h1>HELLO WORLD!</h1>
</body>
</html>启动后：
在浏览器上输入：http://127.0.0.1:8090/login/，就可以获取到login.html这个文件。
整个过程就是：
1、在浏览器地址栏输入http://127.0.0.1:8090/login/?kkk=plpl&dddd=mmmmm，然后回车，就向服务器发送一个请求报文：
为什么我们只是输入了一个URL地址，而请求报文会有那么多内容呢？这就是浏览器做的工作，按照HTTP协议的规定，有效的请求或响应报文中必须包含特定的首部，然后各个浏览器在根据自己的需要，添加一些首部，于是就有了我们现在看到的请求报文。浏览器根据输入的内容，能确定请求报文的起始行，先确定方法是GET（在地址栏输入后回车的都是GET方法请求），然后根据http://确定协议是HTTP，版本是浏览器默认的1.1，后面的127.0.0.1:8090取出，作为首部的host键的值，从第一个斜杠/开始到最后作为请求URL。
2、服务器在收到这个请求报文后，会根据这个报文创建一个对象，即request对象，然后按照请求报文的要求，进行事物处理，这里就是调用login（）函数进行处理，先生成一个response对象，然后获取login.html文档，做一些自定义的操作，在response对象中记录，最后根据response对象生成响应报文，返回给浏览器端，响应报文：
3、这里的请求资源，即请求URL，就不是一个静态文件，而是一个函数，函数生成对应的响应报文，响应报文的响应实体，也不是login.html，（虽然在这里二者完全一致），而是经过模板渲染后的内容，就是以login.html为模板，进行渲染，即按模板语言格式对变量等替换为值的过程后的结果，作为响应实体，返回给客户端。
首部：
理解HTTP的重点是理解首部，HTTP 首部字段向请求和响应报文中添加了一些附加信息。 本质上来说， 它们只是一些名 / 值对的列表，或叫键 / 值对。
首部分类：HTTP 规范定义了几种首部字段：
1、通用首部 ： 既可以出现在请求报文也可以出现在响应报文中。
提供与报文相关的最基本信息，如报文创建日期，不管是请求报文还是响应报文，都是同一个意思。
- Connection ：允许客户端和服务器指定与请求/响应连接有关的选项
- Date ：提供日期和时间，说明报文创建时间
- MIME-Version ：给出了发送端使用的MIME版本
- Trailer ： 如果报文采用了分块传输编码（chunked transfer encoding）方式，可以用这个首部列出位于报文拖挂（trailer）部分的首部集合。
- Transfer-Encoding ： 告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式
- Update ： 给出了发送端可能想要升级使用的新版本或协议
- Via ： 显示了报文经过的中间节点（代理、网关）
- 通用缓存首部：HTTP/1.0引入了允许HTTP应用程序缓存对象本地副本的首部，这样就不需要总是直接从源端服务器获取，最新HTTP版本有丰富的缓存参数集。
- Cache-Control ： 用于随报文传送缓存指示
- Pragma ： 另一种随报文传送指示的方式，但并不专用于缓存
2、请求首部：提供更多有关请求的信息。用于说明是谁或什么在发送请求、请求源自何处，或客户端的喜好及能力。服务器根据这些信息，试着为客户端提供更好的响应。
请求的信息性首部：
- Client-IP ： 提供了运行客户端的机器的IP。
- From ：提供了客户端用户的E-mail地址。
- Host ：给出了接收请求的服务器的主机名和端口号。
- Referer ： 提供了包含当前请求URI的文档的URL。
- UA-Color ： 提供了与客户端显示器的显示颜色有关的信息
- UA-CPU ： 给出了客户端CPU的类型或制造商
- UA-Disp ： 提供了与客户端显示器（屏幕）能力有关的信息。
- UA-OS ： 给出了运行在客户端机器上的操作系统名称及版本。
- UA-Pixels ： 提供了客户端显示器的像素信息。
- User-Agent ： 将发起请求的应用程序名称告知服务器。
Accept首部：为客户端提供了一种将其喜好和能力告知服务器的方式，包括想要什么、可以使用什么，以及最重要的不想要什么。服务器可以根据这些额外信息，对要发送的内容做更明智决定。Accept首部使两端都受益，客户端会得到它们想要的内容，服务器不会浪费时间和带宽发送客户端无法使用的东西。
- Accept ： 告诉服务器能够发送哪些媒体类型。
- Accept-Charset ： 告诉服务器能够发送哪些字符集。
- Accept-Encoding ： 告诉服务器能够发送哪些编码方式
- Accept-Language ： 告诉服务器能够发送哪些语言。
- TE ： 告诉服务器可以使用哪些扩展传输编码。
条件请求首部：客户端为请求加上某些限制，如客户端已经有了一份文档副本，希望只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。即要求服务器在对请求进行响应之前，确保某个条件为真。
- Expect ： 允许客户端列出某请求所要求的服务器行为。
- If-Match ： 如果实体标记与文档当前的实体标记相匹配，就获取这份文档。
- If-Modified-Since ： 除非在某个指定的日期之后资源被修改过，否则就限制这个请求。
- If-None-Match ： 如果提供的实体标记与当前文档的实体标记不相符，就获取文档。
- If-Range ： 允许对文档的某个范围进行条件请求。
- If-Unmodified-Since ： 除非在某个指定日期之后资源没有被修改过，否则限制这个请求。
- Range ： 如果服务器支持范围请求，就请求资源的指定范围。
安全请求首部：HTTP本身支持一种简单机制，可以对请求进行质询/响应认证。这种机制要求客户端在获取特定资源之前，先对自身进行认证。
- Authorization ： 包含了客户端提供给服务器，以便对其进行身份认证的数据。
- Cookie ： 客户端用它向服务器传送一个令牌——它并不是真正的安全首部，但确实隐含了安全功能。
- Cookie2 ： 用来说明请求端支持的cookie版本。
代理请求首部：
- Max-Forward ： 在通往源端服务器的路径上，将请求转发给其他代理或网关的最大次数。
- Proxy-Authorization ： 与Authorization首部相同，但这个首部使在与代理进行认证时使用的。
- Proxy-Connection ： 与Connection首部相同，是在与代理建立连接时使用的。
3、响应首部：提供更多有关响应的信息。这些首部有助于客户端处理响应，并在将来发起更好的请求。
响应的信息性首部：
- Age ： （从最初创建开始）响应持续时间。
- Public ： 服务器为其资源支持的请求方法列表。
- Retry-After ： 如果资源不可用，在此日期或时间重试。
- Server ： 服务器应用程序软件的名称和版本。
- Title ： 对HTML文档来说，就是HTML文档的源端给出的标题。
- Warning ： 比原因短语中更详细一些的警告报文。
协商首部：如果资源有多种表示方法——如不同语言的同一文档，可以为服务器和客户端提供对资源进行协商的能力。
- Accept-Ranges ： 对此资源来说，服务器可接受的范围类型。
- Vary ： 服务器查看的其他首部的列表，可能会使响应发生变化；即这是一个首部列表，服务器会根据这些首部的内容挑选出最合适的资源版本发送给客户端。
安全响应首部：本质上是HTTP的质询/响应认证机制的响应侧。
- Proxy-Authenticate ： 来自代理的对客户端的质询列表。
- Set-Cookie ：不是真正的安全首部，但隐含有安全功能；可以在客户端设置一个令牌，以便服务器对客户端进行标识。
- Set-Cookie2 ： 与Set-Cookie类似。
- WWW-Autenticate ： 来自服务器的对客户端的质询列表。
4、实体首部：描述主体的长度和内容，或者资源自身，HTTP报文的负荷。请求和响应报文都可能包含实体首部，从有关对象类型的信息，到能够对资源使用的各种有效的请求方法。实体首部可以告知报文的接收者它在对什么进行处理。
实体的信息性首部：
- Allow ： 列出了可以对此实体执行的请求方法。
- Location ： 告知客户端实体实际上位于何处；用于将接收端定向到资源的（可能是新的）位置（URL）上去。
内容首部：提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其他有用信息。如Web浏览器可以通过查看返回的内容类型，得知如何显示对象。
- Content-Base ： 解析主体中的相对URL时使用的基础URL。
- Content-Encoding ： 对主体执行的任意编码方式。
- Content-Language ： 理解主体时最适宜使用的自然语言。
- Content-Length ： 主体的长度或尺寸。
- Content-Location ： 资源实际所处的位置。
- Content-MD5 ： 主体的MD5校验和。
- Content-Range ： 在整个资源中此实体表示的字节范围。
- Content-Type ：这个主体的对象类型
实体缓存首部：通用的缓存首部说明了如何或何时进行缓存。实体缓存首部提供了与被缓存实体有关的信息——如验证已缓存的资源副本是否仍然有效所需的信息，以及更好估计已缓存资源何时失效所需的线索。
- Etage ： 与此实体相关的实体标记。
- Expires ： 实体不再有效，要从原始源端再次获取此实体的日期时间。
- Last-Modified ： 这个实体最后一次修改的日期时间。
5、扩展首部：规范中没有定义的新手部，由应用程序开发者创建。
常见首部：
Date： Tue，3Oct 2023 14:12:02 GMT 服务器产生响应的日期
Content-length： 1234 实体的主体部分包含的字节数，此处是1234个字节
Content-type： image/gif 实体的主体部分是一个GIF图片
Accept： image/gif，image/jpeg，text/html 客户端可以接收GIF和JPEG图片以及HTML
首部延续行：
长的首部行可分为多行以提高可读性， 多出来的每行前面至少要有一个空格或制表符（tab）。
实体的主体部分：
HTTP 报文第三部分是可选的实体主体部分。 实体的主体是 HTTP 报文的负荷。就是 HTTP 要传输的内容。HTTP 报文可以承载很多类型的数字数据： 图片、 视频、 HTML 文档、 软件应用程
序、 信用卡事务、 电子邮件等。
方法：
GET和HEAD：安全的方法，这里的安全与我们正常的理解有区别，意思是使用 GET 或 HEAD 方法的 HTTP 请求都不会产生什么动作，意味着 HTTP 请求不会在服务器上产生什么结果。安全方法并不一定是什么动作都不执行的（实际上， 这是由 Web 开发者决定的）。使用安全方法的目的就是当使用可能引发某一动作的不安全方法时， 允许 HTTP 应用程序开发者通知用户。就是说GET和HEAD的协议本意就是获取资源，而不执行其他动作，而如POST，就是要在服务器上执行一个动作，一般是增删改等。所以，如果在一个网站上直接调用POST方法，而动作是另一个网站，则会出现CSRF Forbidden，可能就是这个所谓的安全问题。
GET：请求服务器上某个资源
HEAD：与GET方法行为类似，只返回首部
PUT：向服务器写入文档
POST：向服务器输入数据，通常用来支持HTML表单。
TRACE：在请求穿过防火墙、代理等时，允许客户端在最终将请求发送给服务器时，看看最终请求报文的样子。
OPTIONS：请求Web服务器告知其支持的各种功能。
DELETE：请服务器删除请求URL所指定的资源。
扩展方法：LOCK、MKCOL、COPY、MOVE等
状态码：
104
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
