HTTP个人总结（二）
今天主要总结两块内容，HTTP报文和URL资源。
首先总结URL和资源。
URL是什么？
URL就是因特网资源的标准化名称
URL的语法又是什么？
大多数的URL语法都建立在下面由9个部分构成的通用格式上：
scheme://user:[email protected]:port/path/params?query>#flag
解释如下：
方案——使用什么协议。方案实际上就是规定如何访问指定资源的标识符。它会告诉负责解析URL的应用程序应该使用什么协议。方案组件必须以一个字符符号开始，由第一个“：”符号将其与URL的其余部分分隔开来。
主机与端口：能够提供哪台机器装载了资源，以及在那台机器的什么地方可以找到能对目标资源进行访问的服务器。
用户名和密码：很多服务器都要求输入用户名和密码才会允许访问用户的访问数据
比如在工作上使用ssh连接服务器 如：ssh [email protected] 之后会让你输入密码
路径：说明了资源位于服务器的什么地方，可以使用字符“/“将HTTP URL的路径组件划分成一些路径段，每个路径段都有自己的参数组件
参数：为了向应用程序提供它们所需的输入参数，以便正确地与服务器进行交互，URL中有一个参数组件。比如：
ftp://prep.ai.mit.edu/pub/gnu;type=d
在这个例子中，有一个参数type=d,参数名为type，值为d
查询字符串:如：http://www.joes-hardware.com/inventory-check,cgi?item=12631
这个URL问号（？）右边部分就是查询组件，多查询参数中间用&分隔
片段：比如一个带有章节性的大型文本文档，资源的URL会指向整个文本文档，使用片段（flag）来表示一个资源内部的片段。HTTP服务器通常只处理整个对象，而不是对象的片段，客户端不能讲片段传送给服务器，浏览器从服务器获得整个资源之后，会根据片段来显示你感兴趣的那部分资源。
接下来讲URL的快捷方式？
相对URL是URL的一种便捷缩略记法。基础URL是作为相对URL的参考点使用的，可以来自以下地方：
1.在资源中显示提供。比如HTML文档中可能包含一个基础URL的HTML标记
2.封装资源的基础URL。没有显示指定的基础URL，可以将它所属资源的URL作为基础
3.没有基础URL，在某种情况下，没有基础URL。这通常意味着你有一个相对URL，但有时可能只是一个不完整或损坏了的URL
解析相对引用：
举个例子：
1.路径为./hammers.html，基础URL为http://www .joes-hardware.com/tools.html
2.方案为空，沿着图表的左半边向下处理，基础基础URL的方案
3.至少一个组件非空，一直处理到低端，继承主机和端口组件
4.将来自相对URL的组件与我们继承来的组件合并起来，得到新的绝对URL
自动扩展URL特性有两种方式：
1.主机名扩展
2.历史扩展
还有各种令人头疼的符号？
URL是可移植性的，它要统一命名因特网上所有的资源，安全传输意味着URL的传输不能丢失信息，为了避开这些问题，URL只能使用一些相对较小、通用的安全字母表中的字符，设计者们还希望URL是可读的，因此，即使不可见，不可打印的字符能够穿过邮件程序，从而成为可移植的，也不能在URL中使用
URL字符集：URL的设计者将转义序列集成了进去，通过转义序列，就可以使用US-ASCII字符集的有限子集对任意自赋值或数据进行编码了，这就实现了可移植性和完整性
编码机制：为了避开安全字符集表示法带来的限制，通过一种转义表示法来表示不安全的字符，这种转义表示法包含一个百分号（%），后面跟着两个表示字符ASCII码的十六进制数
通常搜索引擎会出现这种，比如百度搜索某个中文内容，在URL上就会出现这种形式
字符限制：在URL中有几个字符被保留起来，有着特殊的含义，有些字符不在定义的US-ASCII可打印字符集中。还有些字符会与某些因特网网关和协议产生混淆，因此不赞成使用如：
有时你使用一些不安全字符的时候并没有发生什么不好的事情，对某些传输协议来说，这并不是问题，但对应用程序开发人员来说，对非安全字符进行编码仍然是明智的
关于方案：
下面总结关闭HTTP报文这块内容。
什么是报文流？
HTTP报文在HTTP应用程序之间发送的数据块，流动形式：
那么报文又是由哪几个部分组成的？
1.由报文描述的起始行
2.包含属性的首部块
3.包含数据的主体部分
其中起始行和首部行是由分隔的ASCII文本，每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符（ASCII码13）和一个换行符（ASCII码10）。这个行终止序列可以写做CRLF，尽管规范是这样，但是稳健的应用程序也应该接受单个换行符作为行的终止。
报文的主体是一个可选数据块，可以包含文本和二进制数据，也可以为空
报文的语法？
所有的HTTP报文分为两类：请求报文和响应报文。如：
请求报文格式：
响应报文格式：
下面对各部分简要描述：
方法(method)：客户端希望服务器对资源执行的动作，如GET、POST
请求URL（request-URL)：命名了所请求资源，或者URL路径组件的完整URL
版本（version）：报文所使用的HTTP版本
状态码（status）：三位数字描述了请求过程中发生的情况
原因短语（reason-phrase）：数字状态码的可读版本
首部（headers）：可以有零个或多个首部，每个首部都包含以key：value的形式，由一个空行（CRLF）结束，表示首部列表的结束和主体部分的开始
实体的主体部分（entity-body）:包含一个任意数组组成的数据块
注意，一组HTTP首部总是应该以一个空行（单个CRLF）结束，甚至即使没有首部和实体主体部分也应该如此，但是由于很多客户端和服务器（错误的）省略了最后的CRLF，为了兼容，我们都应该接受那些最后没有CRLF的报文
起始行？
所有的HTTP报文都以一个起始行作为开始，请求报文的起始行说明了要做些什么，响应报文的起始行说明发生了什么。
方法：HTTP规范中定义了一组常用的请求方法，描述了7种，有些方法的请求报文中有主体，有些则是无主体的要求
状态码：方法是用来告诉服务器做什么事情的，状态码则用来告诉客户端发生了什么事情。
首部又有什么？
首部分类以下几种：
1.通用首部：既可以出现在请求报文中，也可以出现在响应报文中
2.请求首部：提供更多有关请求的信息
3.响应首部：提供更多关于响应的信息
4.实体首部：描述主体的长度和内容，或者资源本身
5.扩展首部：规范中没有定义的新首部
首部延续行：将长首部行为分为多行可以提高可读性，多出来的每行前面至少要有一个空格或者制表符。
方法的详细介绍？
并不是每个服务器都实现了所有的方法，如果一台服务器要与HTTP/1.1兼容，只需要实现GET和HEAD方法就行，并且有些方法如DELETE等方法会受限，可能不希望任何人都能够操作资源，这些限制通常都是在服务器配置中设置的，因此会随着站点和服务器的不同而有所不同。
GET方法：通常用于请求服务器发送某个资源，HTTP/1.1要求服务器实现此方法。
HEAD方法：与GET方法行为类似，但是服务器在响应中只返回首部，不会返回实体的主体部分。使用HEAD可以在不获取资源的情况下了解资源的情况，通过查看响应中的状态码，看看某个对象是否存在，通过查看首部，测试资源是否被修改。服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同，并且跟GET一样是HTTP/1.1必须实现的方法
PUT方法：与GET从服务器读取文档相反，PUT方法会向服务器写入文档。PUT方法的语义就是让服务器用户请求的主体部分创建一个由所请求的URL命名新的文档，如果那个URL已经存在的话，就用这个主体替代它。
POST方法：通常用它来支持HTML的表单。如：
TRACE方法：客服端发起一个请求时可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求，TRACE方法允许客户端在最终将请求发送给服务器，看看它变成了什么样子。
TRACE方法主要用于诊断，用于验证请求是否如愿穿过了请求/响应链。
OPTIONS方法：请求WEB服务器告知其支持的各种功能。
DELETE方法：所做的就是请服务器删除请求URL所指定的资源，但是客户端应用程序无法保证删除操作一定会被执行。
扩展方法：HTTP被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在HTTP/1.1规范定义的方法。服务器会为它所管理的资源实现一些服务。如WebDAV HTTP扩展
如果你定义了一个扩展方法，很可能大部分HTTP应用程序都无法理解，同样你的应用程序也可能会遇到一些其他应用程序在用，而不理解的扩展方法。所以最好对扩展方法宽容一些，如果在不破坏端到端行为的情况下将带有未知方法的报文传递给下游服务器，代理会尝试传递这些报文，否则会以501（无法实现）状态码回应。最好按惯例：对所发送的内容要求严一点，对所接受的内容宽容一点
下面来讲状态码：
100~199——信息性状态码：（不是太懂，暂不要求）
客户端与100 Continue：从很多方面来看，这是一种优化，客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用100 Continue。如果服务器没有响应，超时一定时间后，客户端应该直接将实体发送出去
服务器与100 Continue:如果服务器收到一条带有 100 Continue的Expect首部的请求，他会用100 Continue响应或一条错误码进行响应
代理与100 Continue：如果代理知道下一跳服务器是HTTP/1.1兼容的，或者并不知道下一跳服务器与哪个版本兼容，它都应该将Expect首部放在请求中向下妆发。如果知道下一跳只能与HTTP/1.1之前的版本兼容，就应该已417错误进行响应
200~299——成功状态码：
300~399+重定向状态码：重定向状态码要么告知客户端使用替代位置来访问它们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容
可以通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证：
400~499——客户端错误状态码：
500~599——服务器错误状态码：
现在来讲首部？
首部有五种：通用首部、请求首部、响应首部、实体首部、扩展首部
通用首部：
请求首部：
Accept首部：提供了一种将其喜好和能力告知服务器的方式，服务器可以根据这些额外信息，对要发送的内容做出更明智的决定。
条件请求首部：有时客户端希望为请求加上某些限制，比如客户端有缓存，只有当服务器上的文档与缓存有所区别时才请求服务器
安全请求首部：HTTP本身支持一种简单的机制，可以对请求进行质询/响应认证，可以使事务稍微安全一些。
代理请求首部：
响应首部：
协商首部：
安全响应首部：
实体首部：
内容首部：
实体缓存首部：