HTTP
URI和URL
-
URI：统一资源标识符
-
URL：统一资源定位符
与URI相比我们更熟悉URL，URL是使用浏览器等访问web页面的时候需要输入的网页地址
http://www.baidu.com
URI是更通用的资源标识符，URL是它的一个子集
URI由两个主要的子集构成
-
URL：通过描述资源的位置来描述资源
-
URN：通过名字来识别资源，和位置无关
URL
URI 是 Uniform Resource Identifier 的缩写
-
Uniform：规定统一的格式，可方便处理各种不同类型的资源，而不用根据上下文环境来识别资源指定的访问方式，加入新的协议方案(HTTP, HTTPS, FTP等)也更容易
-
Resource：资源的定义是“可以标识的任何东西”，除了文档文件、图像或者服务（天气预报）等能够区别于其他类型的，劝都可以称为资源，另外资源不仅可以是单一的，也可以是多数的集合体
-
Identifier：表示可标识的对象，也成为标识符
综上所述，URI就是某个协议方案表示的资源的定位标识符，协议方案是指访问资源所使用的协议类型名称
采用HTTP协议的时候，协议方案就是http，除此之外还有ftp、mailto、file等。看几个例子
ftp://ftp.is.co.za.rfc/rfc1808.txt
http://samaritan89.github.io/f2e/js/ajax.html
mailto:sunluyong@gmail.com
telnet://192.0.2.16:80
URL 格式
我们常见的URL主要由三部分组成
-
方案，也就是我们常说的协议
-
服务器位置
-
资源路径
看个例子
http://samaritan89.github.io/f2e/js/ajax.html
通用的URL由9部分组成
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<hash>
-
对于web页面来说最常用的协议就是http和https
-
user和password现在不常见了，不会在URL明文书写用户名和密码了，都是通过登录的方式
-
主机可以是IPO地址过着域名
-
端口号用来区分主机上的进程，方便找到web服务器，http默认是80
-
path是资源的路径，也就是存放位置，不一定和物理路径完全对应，符合web服务器路由约定即可
-
params，在一些协议中需要参数来访问资源，例如ftp是二进制还是文本传输，参数是名值对，用
;隔开 -
query：这个是get请求最常用的传递参数方式了 ?a=1&b=2&=3
-
hash也成为片段，设计为标识文档的一部分，很多MVVM框架用作了路由功能
相对URL
相对URL是URL一部分，从路径开始，前面木人使用当前文档的设置
./image/logo.png
../script/a.js
/css/main.css
报文
HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息开头，描述报文的内容及含义，后面跟着可选的数据部分
组成
HTTP报文是简单的格式化数据块，每个报文都包含一条来自客户端的请求或者一条来自服务器的响应，由3个部分组成
- 对报文进行描述的起始行 —— start line
- 包含属性的首部块 —— header
- 可选的包含数据的主体部分 —— body
HTTP/1.0 200 OK
content-type: text/plain
content-length: 19
Hi, I'm a message
起始行和首部就是由行分隔的ASCII文本，主题是一个可选的数据块，可能是文本、二进制或者空
语法
HTTP报文分为两类
请求报文：
向web服务器请求一个动作
<method><request-URL><version>
<headers>
<entity-body>
响应报文
把请求结果返回给客户端
<version><status><reason-phrase>
<headers>
<entity-body>
首部和方法配合，共同决定了服务器和客户端能做什么
方法
HTTP最大的作用就是客户端发送请求，服务器给出响应，客户端想服务器发送请求的方式有很多
GET
GET是最常用的方法，通常用于请求服务器发送某个资源
我们平时在浏览器输入网页地址，就是给服务器发送了一个get请求，希望得到这个网页
HEAD
HEAD方法和GET类似，但是在服务器的响应中没有资源的内容，只有资源的一些基本信息，主要用于
-
在不获取资源的情况下获取资源信息（类型、大小等）
-
通过状态码产看资源是否存在
-
通过查看首部，测试资源是否被修改了
PUT
和GET从服务器获取资源相反，PUT用于想服务器写入资源。PUT的语义就是让服务器用请求的主体部分创建一个请求URL命名的文档，如果存在就替换
当然处于安全原因，并不是所有的服务器都实现，当然最近大热的RESTful API使它有了用武之地
POST
POST用于想服务器发送数据，通常用来支持HTML的表单（input、select、textarea），表单中的数据会被发送到服务器
TRACE
客户端发送一个请求的时候，这个请求可能会穿过防火墙、代理、网关和一些其它应用程序，没个中间节点都可能修改HTTP请求，TRACE方法允许客户端在最终请求发往服务器的时候，看看它变成了什么样子
TRACE请求会在目的服务器端发送一个“闭环”诊断，行程最后一站服务器会弹回一条TRACE响应，并在响应主题中携带它收到的原始请求报文
DELETE
DELETE方法用于要求服务器删除请求的URL，和PUT一样，服务器可能会不支持
OPTIONS
OPTIONS方法用于请求 web服务器告知其支持的各种功能
Status Code
完整的 HTTP 1.1规范说明书来自于RFC 2616，HTTP 1.1的状态码被标记为新特性，用来表示请求的结果，状态码被分为五大类：
- 100-199 用于指定客户端应相应的某些动作。
- 200-299 用于表示请求成功。
- 300-399 用于已经移动的文件并且常被包含在定位头信息中指定新的地址信息。
- 400-499 用于指出客户端的错误。
- 500-599 用于支持服务器错误。
