HTTP协议

HTTP协议

可用burpsuite改写GET和POST方法

URL

URL,全称是UniformResourceLocator, 中文叫统一资源定位符,是互联网上用来标识某一处资源的地址。以下面这个URL为例，介绍下普通URL的各部分组成：

1.协议部分

该URL的协议部分为“http：”，这代表网页使用的是HTTP协议。在Internet中可以使用多种协议，如HTTP，FTP等等本例中使用的是HTTP协议。在"HTTP"后面的“//”为分隔符

例子：file 资源是本地计算机上的文件。格式file:///，注意后边应是三个斜杠。

ftp 通过 FTP访问资源。格式 FTP://

gopher 通过 Gopher 协议访问该资源。

http 通过 HTTP 访问该资源。 格式 HTTP://

https 通过安全的 HTTPS 访问该资源。 格式 HTTPS://

mailto 资源为电子邮件地址，通过 SMTP 访问。 格式 mailto:

MMS 通过 支持MMS（流媒体）协议的播放该资源。（代表软件：Windows Media Player）格式 MMS://

ed2k 通过 支持ed2k（专用下载链接）协议的P2P软件访问该资源。（代表软件：电驴） 格式 ed2k://

Flashget 通过 支持Flashget:（专用下载链接）协议的P2P软件访问该资源。（代表软件：快车） 格式 Flashget://

thunder 通过 支持thunder（专用下载链接）协议的P2P软件访问该资源。（代表软件：迅雷） 格式 thunder://

news 通过 NNTP 访问该资源。

2.域名部分

一个URL中，也可以使用IP地址作为域名使用，有时，在主机名前也可以包含连接到服务器所需的用户名和密码（格式：username:password@hostname）

2.1用户名和密码：很多服务器都要求输入用户名和密码才会允许用户访问数据，如FTP服务器。

例子：

ftp://joe:joepasswd@ftp.prep.edu/pub/name

joe是用户名、joepasswd是密码

3.端口部分

跟在域名后面的是端口，域名和端口之间使用“:”作为分隔符。端口不是一个URL必须的部分，如果省略端口部分，将采用默认端口

例子：很多HTTP的默认端口号是80。比如，130.32.12.34:800，这里的IP地址是主机名，端口是800

4.虚拟目录部分

从域名后的第一个“/”开始到最后一个“/”为止，是虚拟目录部分。虚拟目录也不是一个URL必须的部分。

例子：本例中的虚拟目录是“/news/”

5.文件名部分

从域名后的最后一个“/”开始到“？”为止，是文件名部分，如果没有“?”,则是从域名后的最后一个“/”开始到“#”为止，是文件部分，如果没有“？”和“#”，那么从域名后的最后一个“/”开始到结束，都是文件名部分。

例子：本例中的文件名是“index.asp”。文件名部分也不是一个URL必须的部分，如果省略该部分，则使用默认的文件名index.html

6.锚部分

从“#”开始到最后，都是锚部分。本例中的锚部分是“name”。锚部分也不是一个URL必须的部分，其右面的字符就是该位置的标识符(一般情况下，锚链接会用到)

例子：下面的URL中，代表网页si.html的print位置，浏览器读取这个URL后，会自动将print位置滚动至可视区域，不需要用户自己翻到该位置

http://www.cheng.cn/si.html#print

7.参数部分

从“？”开始到“#”为止之间的部分为参数部分，又称搜索部分、查询部分。本例中的参数部分为“boardID=5&ID=24618&page=1”。参数可以允许有多个参数，参数与参数之间用“&”作为分隔符。

例子：很多资源，比如数据库服务、搜索引擎，都可以通过提问题或进行查询来缩小请求资源的范围。或者为了向应用程序提供它们所需要的输入参数，以便正确地与服务器进行交互。

http://www.cheng.cn/si.html?name=csh&age=24

查询组件有两个名/值对：name=csh和age=24

URI和URL的区别

URI，是uniform resource identifier，统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的
URI一般由三部组成：
①访问资源的命名机制
②存放资源的主机名
③资源自身的名称，由路径表示，着重强调于资源。

URL是uniform resource locator，统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。

URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。
采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。URL一般由三部组成：
①协议(或称为服务方式)
②存有该资源的主机IP地址(有时也包括端口号)
③主机资源的具体地址。如目录和文件名等

URN，uniform resource name，统一资源命名，是通过名字来标识资源，比如

mailto:java-net@java.sun.com。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个 URL 都是 URI，但不一定每个 URI 都是 URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。上面的 mailto、news 和 isbn URI 都是 URN 的示例。

在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。
相反的是，URL类可以打开一个到达资源的流。

URL同源策略

同源策略是浏览器的一个安全功能，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。所以xyz.com下的js脚本采用ajax读取abc.com里面的文件数据是会被拒绝的。

同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。

URL同源策略(CSDN)

URL同源策略(简书)

HTTP协议 - 请求

http请求由三部分组成，分别是：请求行，消息报头，请求正文

请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：

Method Request-URI HTTP-Version(CR)(LF)

其中 Method表示请求方法（GET，POST，HEAD等）

Request-URI是一个统一资源标识符

HTTP-Version表示请求的HTTP协议版本

（CR）（LF）表示回车和换行（除了作为结尾的（CR）（LF）外不允许单独出现）

eg:GET /get.php?arg1=value1 HTTP/1.1

HTTP消息请求报头允许客户端向服务器端传递请求的附加信息以及客户端自身的信息

常用的请求报头：Accept,Accept-Charset,Accept-Ecoding,Accept-Language,Authorization,Host(发送请求时该报头域是必需的),User-Agent

每个类型请求头结束后，会跟上（CR）（LF）

消息报头和请求正文会隔一行

请求头格式：

请求首行 请求方法 GET/POST URL 协议版本(HTTP/1.1)\r\n
请求头部 key：value \r\n
回车换行符 \r\n
请求体
（如果get请求是没有请求体的，内容在url后面以键值对格式拼接）
如果是post请求有请求体

响应头格式：

响应首行 协议版本/HTTP/1.1 状态码 200/404/500 状态码描述OK\r\n
响应头部 key：value \r\n
回车符换行符 \r\n
响应体

常用标准请求头字段

---

Accept 设置接受的内容类型

Accept: text/plain

Accept-Charset 设置接受的字符编码

Accept-Charset: utf-8

Accept-Encoding 设置接受的编码格式

Accept-Encoding: gzip, deflate

Accept-Datetime 设置接受的版本时间

Accept-Datetime: Thu, 31 May 2007 20:35:00 GMT

Accept-Language 设置接受的语言

Accept-Language: en-US

Authorization 设置HTTP身份验证的凭证

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Cache-Control 设置请求响应链上所有的缓存机制必须遵守的指令

Cache-Control: no-cache

Connection 设置当前连接和hop-by-hop协议请求字段列表的控制选项

Connection: keep-alive
Connection: Upgrade

Content-Length 设置请求体的字节长度

Content-Length: 348

Content-MD5 设置基于MD5算法对请求体内容进行Base64二进制编码

Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Type 设置请求体的MIME类型（适用POST和PUT请求）

Content-Type: application/x-www-form-urlencoded

Cookie 设置服务器使用Set-Cookie发送的http cookie

Cookie: $Version=1; Skin=new;

Date 设置消息发送的日期和时间

Date: Tue, 15 Nov 1994 08:12:31 GMT

Expect 标识客户端需要的特殊浏览器行为

Expect: 100-continue

Forwarded 披露客户端通过http代理连接web服务的源信息

Forwarded: for=192.0.2.60;proto=http;by=203.0.113.43
Forwarded: for=192.0.2.43, for=198.51.100.17

From 设置发送请求的用户的email地址

From: user@example.com

Host 设置服务器域名和TCP端口号，如果使用的是服务请求标准端口号，端口号可以省略

Host: en.wikipedia.org:8080
Host: en.wikipedia.org

If-Match 设置客户端的ETag,当时客户端ETag和服务器生成的ETag一致才执行，适用于更新自从上次更新之后没有改变的资源

If-Match: "737060cd8c284d8af7ad3082f209582d

If-Modified-Since 设置更新时间，从更新时间到服务端接受请求这段时间内如果资源没有改变，允许服务端返回304 Not Modified

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match 设置客户端ETag，如果和服务端接受请求生成的ETage相同，允许服务端返回304 Not Modified

If-None-Match: “737060cd8c284d8af7ad3082f209582d”

If-Range 设置客户端ETag，如果和服务端接受请求生成的ETage相同，返回缺失的实体部分；否则返回整个新的实体

If-Range: “737060cd8c284d8af7ad3082f209582d”

If-Unmodified-Since 设置更新时间，只有从更新时间到服务端接受请求这段时间内实体没有改变，服务端才会发送响应

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Max-Forwards 限制代理或网关转发消息的次数

Max-Forwards: 10

Origin 标识跨域资源请求（请求服务端设置Access-Control-Allow-Origin响应字段）

Origin: http://www.example-social-network.com

Pragma 设置特殊实现字段，可能会对请求响应链有多种影响

Pragma: no-cache

Proxy-Authorization 为连接代理授权认证信息

Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Range 请求部分实体，设置请求实体的字节数范围，具体可以参见HTTP/1.1中的Byte serving

Range: bytes=500-999

Referer 设置前一个页面的地址，并且前一个页面中的连接指向当前请求，意思就是如果当前请求是在A页面中发送的，那么referer就是A页面的url地址（轶事：这个单词正确的拼法应该是"referrer",但是在很多规范中都拼成了"referer"，所以这个单词也就成为标准用法）

Referer: http://en.wikipedia.org/wiki/Main_Page

TE 设置用户代理期望接受的传输编码格式，和响应头中的Transfer-Encoding字段一样

TE: trailers, deflate

Upgrade 请求服务端升级协议

Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket

User-Agent 用户代理的字符串值

User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/21.0

Via 通知服务器代理请求

Via: 1.0 fred, 1.1 example.com (Apache/1.1)

Warning 实体可能会发生的问题的通用警告

Warning: 199 Miscellaneous warning

常用非标准请求头字段

---

X-Requested-With 标识Ajax请求，大部分js框架发送请求时都会设置它为XMLHttpRequest

X-Requested-With: XMLHttpRequest

DNT 请求web应用禁用用户追踪

DNT: 1 (Do Not Track Enabled)
DNT: 0 (Do Not Track Disabled)

X-Forwarded-For 一个事实标准，用来标识客户端通过HTTP代理或者负载均衡器连接的web服务器的原始IP地址

X-Forwarded-For: client1, proxy1, proxy2
X-Forwarded-For: 129.78.138.66, 129.78.64.103

X-Forwarded-Host 一个事实标准，用来标识客户端在HTTP请求头中请求的原始host,因为主机名或者反向代理的端口可能与处理请求的原始服务器不同

X-Forwarded-Host: en.wikipedia.org:8080
X-Forwarded-Host: en.wikipedia.org

X-Forwarded-Proto 一个事实标准，用来标识HTTP原始协议，因为反向代理或者负载均衡器和web服务器可能使用http,但是请求到反向代理使用的是https

X-Forwarded-Proto: https

Front-End-Https 微软应用程序和负载均衡器使用的非标准header字段 Front-End-Https: on
X-Http-Method-Override 请求web应用时，使用header字段中给定的方法（通常是put或者delete）覆盖请求中指定的方法（通常是post）,如果用户代理或者防火墙不支持直接使用put或者delete方法发送请求时，可以使用这个字段

X-HTTP-Method-Override: DELETE

X-ATT-DeviceId 允许更简单的解析用户代理在AT&T设备上的MakeModel/Firmware

X-Att-Deviceid: GT-P7320/P7320XXLPG

X-Wap-Profile 设置描述当前连接设备的详细信息的xml文件在网络中的位置

x-wap-profile: http://wap.samsungmobile.com/uaprof/SGH-I777.xml

Proxy-Connection 早起HTTP版本中的一个误称，现在使用标准的connection字段

Proxy-Connection: keep-alive

X-UIDH 服务端深度包检测插入的一个唯一ID标识Verizon Wireless的客户

X-UIDH: …

X-Csrf-Token,X-CSRFToken,X-XSRF-TOKEN 防止跨站请求伪造

X-Csrf-Token: i8XNjC4b8KVok4uw5RftR38Wgp2BFwql

X-Request-ID,X-Correlation-ID 标识客户端和服务端的HTTP请求

X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5

常用标准响应头字段

---

Access-Control-Allow-Origin 指定哪些站点可以参与跨站资源共享

Access-Control-Allow-Origin: *

Accept-Patch 指定服务器支持的补丁文档格式，适用于http的patch方法

Accept-Patch: text/example;charset=utf-8

Accept-Ranges 服务器通过byte serving支持的部分内容范围类型

Accept-Ranges: bytes

Age 对象在代理缓存中暂存的秒数

Age: 12

Allow 设置特定资源的有效行为，适用方法不被允许的http 405错误

Allow: GET, HEAD

Alt-Svc 服务器使用"Alt-Svc"（Alternative Servicesde的缩写）头标识资源可以通过不同的网络位置或者不同的网络协议获取

Alt-Svc: h2=“http2.example.com:443”; ma=7200

Cache-Control 告诉服务端到客户端所有的缓存机制是否可以缓存这个对象，单位是秒

Cache-Control: max-age=3600

Connection 设置当前连接和hop-by-hop协议请求字段列表的控制选项

Connection: close

Content-Disposition 告诉客户端弹出一个文件下载框，并且可以指定下载文件名

Content-Disposition: attachment; filename=“fname.ext”

Content-Encoding 设置数据使用的编码类型

Content-Encoding: gzip

Content-Language 为封闭内容设置自然语言或者目标用户语言

Content-Language: en

Content-Length 响应体的字节长度

Content-Length: 348

Content-Location 设置返回数据的另一个位置

Content-Location: /index.htm

Content-MD5 设置基于MD5算法对响应体内容进行Base64二进制编码

Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Content-Range 标识响应体内容属于完整消息体中的那一部分

Content-Range: bytes 21010-47021/47022

Content-Type 设置响应体的MIME类型

Content-Type: text/html; charset=utf-8

Date 设置消息发送的日期和时间

Date: Tue, 15 Nov 1994 08:12:31 GMT

ETag 特定版本资源的标识符，通常是消息摘要

ETag: “737060cd8c284d8af7ad3082f209582d”

Expires 设置响应体的过期时间

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified 设置请求对象最后一次的修改日期

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Link 设置与其他资源的类型关系

Link: ; rel=“alternate”

Location 在重定向中或者创建新资源时使用

Location: http://www.w3.org/pub/WWW/People.html

P3P 以P3P:CP="your_compact_policy"的格式设置支持P3P(Platform for Privacy Preferences Project)策略，大部分浏览器没有完全支持P3P策略，许多站点设置假的策略内容欺骗支持P3P策略的浏览器以获取第三方cookie的授权

P3P: CP=“This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info.”

Pragma 设置特殊实现字段，可能会对请求响应链有多种影响

Pragma: no-cache

Proxy-Authenticate 设置访问代理的请求权限

Proxy-Authenticate: Basic

Public-Key-Pins 设置站点的授权TLS证书

Public-Key-Pins: max-age=2592000; pin-sha256=“E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=”;

Refresh "重定向或者新资源创建时使用，在页面的头部有个扩展可以实现相似的功能，并且大部分浏览器都支持
``

Refresh: 5; url=http://www.w3.org/pub/WWW/People.html

Retry-After 如果实体暂时不可用，可以设置这个值让客户端重试，可以使用时间段（单位是秒）或者HTTP时间

Example 1: Retry-After: 120
Example 2: Retry-After: Fri, 07 Nov 2014 23:59:59 GMT

Server 服务器名称

Server: Apache/2.4.1 (Unix)

Set-Cookie 设置HTTP Cookie

Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1

Status 设置HTTP响应状态

Status: 200 OK

Strict-Transport-Security 一种HSTS策略通知HTTP客户端缓存HTTPS策略多长时间以及是否应用到子域

Strict-Transport-Security: max-age=16070400; includeSubDomains

Trailer 标识给定的header字段将展示在后续的chunked编码的消息中

Trailer: Max-Forwards

Transfer-Encoding 设置传输实体的编码格式，目前支持的格式： chunked, compress, deflate, gzip, identity

Transfer-Encoding: chunked

TSV Tracking Status Value，在响应中设置给DNT(do-not-track),可能的取值
　　　“!” — under construction
　　　“?” — dynamic
　　　“G” — gateway to multiple parties
　　　“N” — not tracking
　　　“T” — tracking
　　　“C” — tracking with consent
　　　“P” — tracking only if consented
　　　“D” — disregarding DNT
　　　“U” — updated

TSV: ?

Upgrade 请求客户端升级协议

Upgrade: HTTP/2.0, HTTPS/1.3, IRC/6.9, RTA/x11, websocket

Vary 通知下级代理如何匹配未来的请求头已让其决定缓存的响应是否可用而不是重新从源主机请求新的

Example 1: Vary: *
Example 2: Vary: Accept-Language

Via 通知客户端代理，通过其要发送什么响应

Via: 1.0 fred, 1.1 example.com (Apache/1.1)

Warning 实体可能会发生的问题的通用警告

Warning: 199 Miscellaneous warning

WWW-Authenticate 标识访问请求实体的身份验证方案

WWW-Authenticate: Basic

X-Frame-Options 点击劫持保护：
　　　deny frame中不渲染
　　　sameorigin 如果源不匹配不渲染
　　　allow-from 允许指定位置访问
　　　allowall 不标准，允许任意位置访问

X-Frame-Options: deny

常用非标准响应头字段

---

X-XSS-Protection 过滤跨站脚本

X-XSS-Protection: 1; mode=block

Content-Security-Policy, X-Content-Security-Policy,X-WebKit-CSP 定义内容安全策略

X-WebKit-CSP: default-src ‘self’

X-Content-Type-Options 唯一的取值是"",阻止IE在响应中嗅探定义的内容格式以外的其他MIME格式

X-Content-Type-Options: nosniff

X-Powered-By 指定支持web应用的技术

X-Powered-By: PHP/5.4.0

X-UA-Compatible 推荐首选的渲染引擎来展示内容，通常向后兼容，也用于激活IE中内嵌chrome框架插件
``

X-UA-Compatible: IE=EmulateIE7
X-UA-Compatible: IE=edge
X-UA-Compatible: Chrome=1

X-Content-Duration 提供音视频的持续时间，单位是秒，只有Gecko内核浏览器支持

X-Content-Duration: 42.666

Upgrade-Insecure-Requests 标识服务器是否可以处理HTTPS协议

Upgrade-Insecure-Requests: 1

X-Request-ID,X-Correlation-ID 标识一个客户端和服务端的请求

X-Request-ID: f058ebd6-02f7-4d3f-942e-904344e8cde5

HTTP1.0的请求方法

三种请求方法，GET，POST和HEAD

GET请求

GET请求格式：

＜请求路径＞[?[arg]=＜value1＞[＆＜arg2＞]=＜value2＞…］

Server端可以根据参数名获取值

GET请求，是可以把数据放在URL中来传递，也可以不包含任何数据，HTTP请求只有请求头，没有请求数据

请求头中可以不包含Content-Length

GET请求可以只有请求的路径

GET请求也可以带需要传递的数据，在访问路径之后带（？）+参数=值的方式发送

POST请求

POST请求是包含数据

请求数据的格式,可以在HTTP头中定义.格式一般会有:

表单格式	application/x-www-form-urlencoded
混合格式	multipart/form-data
JSON格式	application/json
XML格式	text/xml
文本	text/plain

表单格式:与GET方法类似,是把所有提交数据放在数据区域

POST方式也可以向GET方式在URL带参数,但一般不会这样去用

表单方式与GET方式类似,只是把数据放在头文件下面的请求正文区域.请求如下:

POST / post-form.php HTTP/1.1

Content-Type:application/x-www-form-urlencoded

Host:192.168.0.105

Connection:close

User-Agent:Paw/2.2.5(Macintosh;OS X/10.12.1) GCDHTTPRequest

Content-Length:11

arg1=value1

混合模式

有文件上传时常用的方法.可以结束同时提交的不同类型的数据

表单中,可以吧类型更改为file就可以上传文件

<inout type="file"name="file"id=“file/>”

类型后面一般会跟boundary来告知数据区域分隔符

每个数据都可以单独说明数据类型

获取文件时,可以使用相应参数:

php代码如下:

$_FILES [“file”] [“name”] - 文件名

$_FILES [“file”] [“type”] - 类型

$_FILES [“file”] [“size”] - 文件大小

$_FILES [“file”] [“tmp name”] - 临时文件路径

混合模式一般是用来传输文件,后买你会跟boundary=_ xxxx _来进行每个参数的分割

文本模式

常见类型为json,xml,plain

这种类型的数据,需要服务器端代码自行解析

php代码为例:

file fet contents(“php://input”); - 可以获取数据区域文本

要是结束的是json,使用相关方法(函数)来解析

echo json decode(file get contents(“php://input”),true)[‘arg1’];

可以根据type(类型)来解开数据

文本模式,也可以按照文件来接收,

使用file get contents(“php://input”);可以免去读取文件里的内容

fifle get contents(“php://input”);模式不能结束multipart/form-data模式

HEAD请求

HEAD请求就是返回只有头部数据,数据部分不返回内容

返回的内容基本上与GET,POST的返回头一致

OPTIONS请求

OPTIONS请求,默认情况下会返回允许的请求类型

一般需要跨域的时候需要设置OPTIONS

使用脚本让浏览器跨域进行请求的时候,会检测OPTIONS,对方服务器是否允许跨越.允许的情况下,才会真正去进行相关请求

当拟用浏览器访问site1.com,某些脚本操作会提交到site2

.com而且附带非浏览器默认的头信息,这个时候浏览器奴会直接发出POST请求,先发出OPYIONS请求来判断是否允许发送POST.当对方回复允许了,才能发送POST请求

PUT DELETE

PUT:在特定目录里上传指定文件,文件名在URL中设置

DELETE:删除特定目录里的文件,文件名在URL中设置

在NGINX中,可以添加如下配置来允许PUT,DELETE

location /upload/{

​ dav_methods PUT DELETE;

​ root /usr/share/ngint/html;

}

TRACE,CONNECT

HTTP TRACE是让我们的web服务器端将客户端的所有请求信息返回给客户端的方法,该方法多见于debug需求

CONNECT是在特定应用走HTTP协议时会用到

proxy肯会用到

某些使用http协议,需要长连接的程序(SSL就用connect)

HTTP状态码

HTTP状态码的作用是告诉客户端,发生了什么事

HTTP状态码分为五大类,目前我们使用的HTTP协议版本是1.1,

支持下的状态码.

	已定义范围	分类
1xx	100-101	信息提示
2xx	200-206	成功
3xx	300-307	重定向
4xx	400-417	客户端错误
5xx	500-505	服务端错误

常见的状态码

200 服务器成功处理了请求

301/302 Moved Permanently (重定向)请求的URL已移走.Response中应该包含一个Location URL说明资源现在所处的位置

304 Not Modified(未修改)客户的缓存资源是最新的,要客户端使用缓存

404 Not Found 未找到资源

501 Internal Server Error服务器遇到一个错误,使其无法对请求提供服务

1XX：通知

1XX系列响应代码仅在与HTTP服务器沟通时使用。

• 100(“Continue”)
  重要程度：中等，但（写操作时）很少用。

这是对HTTP LBYL（look-before-you-leap）请求的一个可能的响应。该响应代码表明：客户端应重新发送初始请求，并在请求中附上第一次请求时未提供的（可能很大或者包含敏感信息的）表示。客户端这次发送的请求不会被拒绝。对LBYL请求的另一个可能的响应是417(“Expectation Failed”)。

请求报头：要做一个LBYL请求，客户端必须把Expect请求报头设为字符串"100-continue"。除此以外，客户端还需要设置其他一些报头，服务器将根据这些报头决定是响应100还是417。

• 101(“Switching Protocols”)
  重要程度：非常低。

当客户端通过在请求里使用Upgrade报头，以通知服务器它想改用除HTTP协议之外的其他协议时，客户端将获得此响应代码。101响应代码表示“行，我现在改用另一个协议了”。通常HTTP客户端会在收到服务器发来的101响应后关闭与服务器的TCP连接。101响应代码意味着，该客户端不再是一个HTTP客户端，而将成为另一种客户端。
尽管可以通过Upgrade报头从HTTP切换到HTTPS，或者从HTTP1.1切换到某个未来的版本，但实际使用Upgrade报头的情况比较少。Upgrade报头也可用于HTTP切换到一个完全不同的协议（如IRC）上，但那需要在Web服务器切换为一个IRC服务器的同时，Web客户端切换为一个IRC的客户端，因为服务器将立刻在同一个TCP连接上开始使用新的协议。

请求报头：客户端把Upgrade报头设置为一组希望使用的协议。
响应报头：如果服务器同意切换协议，它就返回一个Upgrade报头，说明它将切换到那个协议，并附上一个空白行。服务器不用关闭TCP链接，而是直接在该TCP连接上开始使用新的协议。

2XX: 成功

2XX系列响应代码表明操作成功了。

• 200(“OK”)
  重要程度：非常高。

一般来说，这是客户端希望看到的响应代码。它表示服务器成功执行了客户端所请求的动作，并且在2XX系列里没有其他更适合的响应代码了。

实体主体：对于GET请求，服务器应返回客户端所请求资源的一个表示。对于其他请求，服务器应返回当前所选资源的一个表示，或者刚刚执行的动作的一个描述。

-201(“Created”)
重要程度：高。

当服务器依照客户端的请求创建了一个新资源时，发送此响应代码。

响应报头：Location报头应包含指向新创建资源的规范URI。
实体主体：应该给出新创建资源的描述与链接。若已经在Location报头里给出了新资源的URI，那么可以用新资源的一个表示作为实体主体。

-202(“Accepted”)
重要程度：中等。

客户端的请求无法或将不被实时处理。请求稍后会被处理。请求看上去是合法的，但在实际处理它时有出现问题的可能。
若一个请求触发了一个异步操作，或者一个需要现实世界参与的动作，或者一个需要很长时间才能完成且没必要让Web客户端一直等待的动作时，这个相应代码是一个合适的选择。

响应报头：应该把未处理完的请求暴露为一个资源，以便客户端稍后查询其状态。Location报头可以包含指向该资源的URI。
实体主体：若无法让客户端稍后查询请求的状态，那么至少应该提供一个关于何时能处理该请求的估计。

• 203(“Non-Authoritative Information”)
  重要程度：非常低。

这个响应代码跟200一样，只不过服务器想让客户端知道，有些响应报头并非来自该服务器–他们可能是从客户端先前发送的一个请求里复制的，或者从第三方得到的。

响应报头：客户端应明白某些报头可能是不准确的，某些响应报头可能不是服务器自己生成的，所以服务器也不知道其含义。

• 204(“No Content”)
  重要程度：高。

若服务器拒绝对PUT、POST或者DELETE请求返回任何状态信息或表示，那么通常采用此响应代码。服务器也可以对GET请求返回此响应代码，这表明“客户端请求的资源存在，但其表示是空的”。注意与304(“Not Modified”)的区别。204常常用在Ajax应用里。服务器通过这个响应代码告诉客户端：客户端的输入已被接受，但客户端不应该改变任何UI元素。

实体主体：不允许。

• 205(“Reset Content”)
  重要程度：低。

它与204类似，但与204不同的是，它表明客户端应重置数据源的视图或数据结构。假如你在浏览器里提交一个HTML表单，并得到响应代码204，那么表单里的各个字段值不变，可以继续修改它们；但假如得到的响应代码205，那么表单里的各个字段将被重置为它们的初始值。从数据录入方面讲：204适合对单条记录做一系列编辑，而205适于连续输入一组记录。

• 206(“Partial Content”)
  重要程度：对于支持部分GET（partial GET）的服务而言“非常高”，其他情况下“低”。

它跟200类似，但它用于对部分GET请求（即使用Range请求报头的GET请求）的响应。部分GET请求常用于大型二进制文件的断点续传。

请求报头：客户端为Range请求报头设置一个值。
响应报头：需要提供Date报头。ETag报头与Content-Location报头的值应该跟正常GET请求相同。

若实体主体是单个字节范围（byte range），那么HTTP响应里必须包含一个Content-Range报头，以说明本响应返回的是表示的哪个部分，若实体主体是一个多部分实体（multipart entity）（即该实体主体由多个字节范围构成），那么每一个部分都要有自己的Content-Range报头。
实体主体：不是整个表示，而是一个或者多个字节范围。

3XX 重定向

3XX系列响应代码表明：客户端需要做些额外工作才能得到所需要的资源。它们通常用于GET请求。他们通常告诉客户端需要向另一个URI发送GET请求，才能得到所需的表示。那个URI就包含在Location响应报头里。

• 300(“Multiple Choices”)
  重要程度：低。

若被请求的资源在服务器端存在多个表示，而服务器不知道客户端想要的是哪一个表示时，发送这个响应代码。或者当客户端没有使用Accept-*报头来指定一个表示，或者客户端所请求的表示不存在时，也发送这个响应代码。在这种情况下，一种选择是，服务器返回一个首选表示，并把响应代码设置为200，不过它也可以返回一个包含该资源各个表示的URI列表，并把响应代码设为300。

响应报头：如果服务器有首选表示，那么它可以在Location响应报头中给出这个首选表示的URI。跟其他3XX响应代码一样，客户端可以自动跟随Location中的URI。
实体主体：一个包含该资源各个表示的URI的列表。可以在表示中提供一些信息，以便用户作出选择。

• 301(“Moved Permanently”)
  重要程度：中等。

服务器知道客户端试图访问的是哪个资源，但它不喜欢客户端用当前URI来请求该资源。它希望客户端记住另一个URI，并在今后的请求中使用那个新的URI。你可以通过这个响应代码来防止由于URI变更而导致老URI失效。

响应报头：服务器应当把规范URI放在Location响应报头里。
实体主体：服务器可以发送一个包含新URI的信息，不过这不是必需的。

• 302(“Found”)
  重要程度：应该了解，特别市编写客户端时。但我不推荐使用它。

这个响应代码市造成大多数重定向方面的混乱的最根本原因。它应该是像307那样被处理。实际上，在HTTP 1.0中，响应代码302的名称是”Moved Temporarily”，不幸的是，在实际生活中，绝大多数客户端拿它像303一样处理。它的不同之处在于当服务器为客户端的PUT，POST或者DELETE请求返回302响应代码时，客户端要怎么做。
为了消除这一混淆，在HTTP 1.1中，该响应代码被重命名为"Found"，并新加了一个响应代码307。这个响应代码目前仍在广泛使用，但它的含义市混淆的，所以我建议你的服务发送307或者303，而不要发送302.除非你知道正在与一个不能理解303或307的HTTP 1.0客户端交互。

响应报头：把客户端应重新请求的那个URI放在Location报头里。
实体主体：一个包含指向新URI的链接的超文本文档（就像301一样）。

• 303(“See Other”)
  重要程度：高。

请求已经被处理，但服务器不是直接返回一个响应文档，而是返回一个响应文档的URI。该响应文档可能是一个静态的状态信息，也可能是一个更有趣的资源。对于后一种情况，303是一种令服务器可以“发送一个资源的表示，而不强迫客户端下载其所有数据”的方式。客户端可以向Location报头里的URI发送GET请求，但它不是必须这么做。
303响应代码是一种规范化资源URI的好办法。一个资源可以有多个URIs，但每个资源的规范URI只有一个，该资源的所有其他URIs都通过303指向该资源的规范URI，例如：303可以把一个对http://www.example.com/software/current.tar.gz的请求重定向到http://www.example.com/software/1.0.2.tar.gz。

响应报头：Location报头里包含资源的URI。
实体主体：一个包含指向新URI的链接的超文本文档。

• 304(“Not Modified”)
  重要程度：高。

这个响应代码跟204(“No Content”)类似：响应实体主体都必须为空。但204用于没有主体数据的情况，而304用于有主体数据，但客户端已拥有该数据，没必要重复发送的情况。这个响应代码可用于条件HTTP请求（conditional HTTP request).如果客户端在发送GET请求时附上了一个值为Sunday的If-Modified-Since报头，而客户端所请求的表示在服务器端自星期日（Sunday）以来一直没有改变过，那么服务器可以返回一个304响应。服务器也可以返回一个200响应，但由于客户端已拥有该表示，因此重复发送该表示只会白白浪费宽带。

响应报头：需要提供Date报头。Etag与Content-Location报头的值，应该跟返回200响应时的一样。若Expires, Cache-Control及Vary报头的值自上次发送以来已经改变，那么就要提供这些报头。
实体主体：不允许。

• 305(“Use Proxy”)
  重要程度：低。

这个响应代码用于告诉客户端它需要再发一次请求，但这次要通过一个HTTP代理发送，而不是直接发送给服务器。这个响应代码使用的不多，因为服务器很少在意客户端是否使用某一特定代理。这个代码主要用于基于代理的镜像站点。现在，镜像站点（如http://www.example.com.mysite.com/）包含跟原始站点（如 http://www.example.com/）一样的内容，但具有不同的URI，原始站点可以通过307把客户端重新定向到镜像站点上。假如有基于代理的镜像站点，那么你可以通过把 http://proxy.mysite.com/设为代理，使用跟原始URI（http://www.example.com/）一样的URI来访问镜像站点。这里，原始站点example.com可以通过305把客户端路由到一个地理上接近客户端的镜像代理。web浏览器一般不能正确处理这个响应代码，这是导致305响应代码用的不多的另一个原因。

响应报头：Location报头里包含代理的URI。

• 306 未使用
  重要程度：无

306 响应代码没有在HTTP标准中定义过。

• 307(“Temporary Redirect”)
  重要程度：高。

请求还没有被处理，因为所请求的资源不在本地：它在另一个URI处。客户端应该向那个URI重新发送请求。就GET请求来说，它只是请求得到一个表示，该响应代码跟303没有区别。当服务器希望把客户端重新定向到一个镜像站点时，可以用307来响应GET请求。但对于POST，PUT及DELETE请求，它们希望服务器执行一些操作，307和303有显著区别。对POST，PUT或者DELETE请求响应303表明：操作已经成功执行，但响应实体将不随本响应一起返回，若客户端想要获取响应实体主体，它需要向另一个URI发送GET请求。而307表明：服务器尚未执行操作，客户端需要向Location报头里的那个URI重新提交整个请求。

响应报头： 把客户端应重新请求的那个URI放在Location报头里。
实体主体：一个包含指向新URI的链接的超文本文档。

4XX：客户端错误

这些响应代码表明客户端出现错误。不是认证信息有问题，就是表示格式或HTTP库本身有问题。客户端需要自行改正。

• 400(“Bad Request”)
  重要程度：高。

这是一个通用的客户端错误状态，当其他4XX响应代码不适用时，就采用400。此响应代码通常用于“服务器收到客户端通过PUT或者POST请求提交的表示，表示的格式正确，但服务器不懂它什么意思”的情况。

实体主体：可以包含一个错误的描述文档。

• 401(“Unauthorized”)
  重要程度：高。

客户端试图对一个受保护的资源进行操作，却又没有提供正确的认证证书。客户端提供了错误的证书，或者根本没有提供证书。这里的证书（credential）可以是一个用户名/密码，也可以市一个API key，或者一个认证令牌。客户端常常通过向一个URI发送请求，并查看收到401响应，以获知应该发送哪种证书，以及证书的格式。如果服务器不想让未授权的用户获知某个资源的存在，那么它可以谎报一个404而不是401。这样做的缺点是：客户端需要事先知道服务器接受哪种认证–这将导致HTTP摘要认证无法工作。

响应报头：WWW-Authenticate报头描述服务器将接受哪种认证。
实体主体：一个错误的描述文档。假如最终用户可通过“在网站上注册”的方式得到证书，那么应提供一个指向该注册页面的链接。

• 402(“Payment Required”)
  重要程度：无。

除了它的名字外，HTTP标准没有对该响应的其他方面作任何定义。因为目前还没有用于HTTP的微支付系统，所以它被留作将来使用。尽管如此，若存在一个用于HTTP的微支付系统，那么这些系统将首先出现在web服务领域。如果想按请求向用户收费，而且你与用户之间的关系允许这么做的话，那么或许用得上这个响应代码。
注：该书印于2008年

• 403(“Forbidden”)
  重要程度：中等。

客户端请求的结构正确，但是服务器不想处理它。这跟证书不正确的情况不同–若证书不正确，应该发送响应代码401。该响应代码常用于一个资源只允许在特定时间段内访问，
或者允许特定IP地址的用户访问的情况。403暗示了所请求的资源确实存在。跟401一样，若服务器不想透露此信息，它可以谎报一个404。既然客户端请求的结构正确，那为什么还要把本响应代码放在4XX系列（客户端错误），而不是5XX系列（服务端错误）呢？因为服务器不是根据请求的结构，而是根据请求的其他方面（比如说发出请求的时间）作出的决定的。

实体主体：一个描述拒绝原因的文档（可选）。

• 404(“Not Found”)
  重要程度：高。

这也许是最广为人知的HTTP响应代码了。404表明服务器无法把客户端请求的URI转换为一个资源。相比之下，410更有用一些。web服务可以通过404响应告诉客户端所请求的URI是空的，然后客户端就可以通过向该URI发送PUT请求来创建一个新资源了。但是404也有可能是用来掩饰403或者401.

• 405(“Method Not Allowd”)
  重要程度：中等。

客户端试图使用一个本资源不支持的HTTP方法。例如：一个资源只支持GET方法，但是客户端使用PUT方法访问。

响应报头：Allow报头列出本资源支持哪些HTTP方法，例如：Allow：GET，POST

• 406(“Not Acceptable”)
  重要程度：中等。

当客户端对表示有太多要求，以至于服务器无法提供满足要求的表示，服务器可以发送这个响应代码。例如：客户端通过Accept头指定媒体类型为application/json+hic，但是服务器只支持application/json。服务器的另一个选择是：忽略客户端挑剔的要求，返回首选表示，并把响应代码设为200。

实体主体：一个可选表示的链接列表。

• 407(“Proxy Authentication Required”)
  重要程度：低。

只有HTTP代理会发送这个响应代码。它跟401类似，唯一区别在于：这里不是无权访问web服务，而是无权访问代理。跟401一样，可能是因为客户端没有提供证书，也可能是客户端提供的证书不正确或不充分。

请求报头：客户端通过使用Proxy-Authorization报头（而不是Authorization）把证书提供给代理。格式跟Authrization一样。
响应报头：代理通过Proxy-Authenticate报头（而不是WWW-Authenticate）告诉客户端它接受哪种认证。格式跟WWW-Authenticate一样。

• 408(“Reqeust Timeout”)
  重要程度：低。

假如HTTP客户端与服务器建立链接后，却不发送任何请求（或从不发送表明请求结束的空白行），那么服务器最终应该发送一个408响应代码，并关闭此连接。

• 409(“Conflict”)
  重要程度：高。

此响应代码表明：你请求的操作会导致服务器的资源处于一种不可能或不一致的状态。例如你试图修改某个用户的用户名，而修改后的用户名与其他存在的用户名冲突了。

响应报头：若冲突是因为某个其他资源的存在而引起的，那么应该在Location报头里给出那个资源的URI。
实体主体：一个描述冲突的文档，以便客户端可以解决冲突。

• 410(“Gone”)
  重要程度：中等。

这个响应代码跟404类似，但它提供的有用信息更多一些。这个响应代码用于服务器知道被请求的URI过去曾指向一个资源，但该资源现在不存在了的情况。服务器不知道
该资源的新URI，服务器要是知道该URI的话，它就发送响应代码301.410和310一样，都有暗示客户端不应该再请求该URI的意思，不同之处在于：410只是指出该资源不存在，但没有给出该资源的新URI。RFC2616建议“为短期的推广服务，以及属于个人但不继续在服务端运行的资源”采用410.

• 411(“Length Required”)
  重要程度：低到中等。

若HTTP请求包含表示，它应该把Content-Length请求报头的值设为该表示的长度（以字节为单位）。对客户端而言，有时这不太方便（例如，当表示是来自其他来源的字节流时）。
所以HTTP并不要求客户端在每个请求中都提供Content-Length报头。但HTTP服务器可以要求客户端必须设置该报头。服务器可以中断任何没有提供Content-Length报头的请求，并要求客户端重新提交包含Content-Length报头的请求。这个响应代码就是用于中断未提供Content-Lenght报头的请求的。假如客户端提供错误的长度，或发送超过长度的表示，服务器可以中断请求并关闭链接，并返回响应代码413。

• 412(“Precondition Failed”)
  重要程度：中等。

客户端在请求报头里指定一些前提条件，并要求服务器只有在满足一定条件的情况下才能处理本请求。若服务器不满足这些条件，就返回此响应代码。If-Unmodified-Since是一个常见的前提条件。客户端可以通过PUT请求来修改一个资源，但它要求，仅在自客户端最后一次获取该资源后该资源未被别人修改过才能执行修改操作。若没有这一前提条件，客户端可能会无意识地覆盖别人做的修改，或者导致409的产生。

请求报头：若客户但设置了If-Match，If-None-Match或If-Unmodified-Since报头，那就有可能得到这个响应代码。If-None-Match稍微特别一些。若客户端在发送GET或HEAD请求时指定了If-None-Match，并且服务器不满足该前提条件的话，那么响应代码不是412而是304，这是实现条件HTTP GET的基础。若客户端在发送PUT，POST或DELETE请求时指定了If-None-Match,并且服务器不满足该前提条件的话，那么响应代码是412.另外，若客户端指定了If-Match或If-Unmodified-Since(无论采用什么HTTP方法)，而服务器不满足该前提条件的话，响应代码也是412。

• 413(“Request Entity Too Large”)
  重要程度：低到中等。

这个响应代码跟411类似，服务器可以用它来中断客户端的请求并关闭连接，而不需要等待请求完成。411用于客户端未指定长度的情况，而413用于客户端发送的表示太大，以至于服务器无法处理。客户端可以先做一个LBYL（look-before-you-leap）请求，以免请求被413中断。若LBYL请求获得响应代码为100，客户端再提交完整的表示。

响应报头：如果因为服务器方面临时遇到问题（比如资源不足），而不是因为客户端方面的问题而导致中断请求的话，服务器可以把Retry-After报头的值设为一个日期或一个间隔时间，以秒为单位，以便客户端可以过段时间重试。

• 414(“Request-URI Too Long”)
  重要程度：低。

HTTP标准并没有对URI长度作出官方限制，但大部分现有的web服务器都对URI长度有一个上限，而web服务可能也一样。导致URI超长的最常见的原因是：表示数据明明是该放在实体主体里的，但客户端却把它放在了URI里。深度嵌套的数据结构也有可能引起URI过长。

• 415(“Unsupported Media Type”)
  重要程度：中等。

当客户端在发送表示时采用了一种服务器无法理解的媒体类型，服务器发送此响应代码。比如说，服务器期望的是XML格式，而客户端发送的确实JSON格式。
如果客户端采用的媒体类型正确，但格式有问题，这时最好返回更通用的400。

• 416(“Requestd Range Not Satisfiable”)
  重要程度：低。

当客户端所请求的字节范围超出表示的实际大小时，服务器发送此响应代码。例如：你请求一个表示的1-100字节，但该表示总共只用99字节大小。

请求报头：仅当原始请求里包含Range报头时，才有可能收到此响应代码。若原始请求提供的是If-Range报头，则不会收到此响应代码。
响应报头：服务器应当通过Content-Range报头告诉客户端表示的实际大小。

• 417(“Expectation Failed”)
  重要程度：中等。

此响应代码跟100正好相反。当你用LBYL请求来考察服务器是否会接受你的表示时，如果服务器确认会接受你的表示，那么你将获得响应代码100，否则你将获得417。

5XX 服务端错误

这些响应代码表明服务器端出现错误。一般来说，这些代码意味着服务器处于不能执行客户端请求的状态，此时客户端应稍后重试。有时，服务器能够估计客户端应在多久之后重试。并把该信息放在Retry-After响应报头里。

5XX系列响应代码在数量上不如4XX系列多，这不是因为服务器错误的几率小，而是因为没有必要如此详细–对于服务器方面的问题，客户端是无能为力的。

• 500(“Internal Server Error”)
  重要程度：高。

这是一个通用的服务器错误响应。对于大多数web框架，如果在执行请求处理代码时遇到了异常，它们就发送此响应代码。

• 501(“Not Implemented”)
  重要程度：低。

客户端试图使用一个服务器不支持的HTTP特性。
最常见的例子是：客户端试图做一个采用了拓展HTTP方法的请求，而普通web服务器不支持此请求。它跟响应代码405比较相似，405表明客户端所用的方法是一个可识别的方法，但该资源不支持，而501表明服务器根本不能识别该方法。

• 502(“Bad Gateway”)
  重要程度：低。

只有HTTP代理会发送这个响应代码。它表明代理方面出现问题，或者代理与上行服务器之间出现问题，而不是上行服务器本身有问题。若代理根本无法访问上行服务器，响应代码将是504。

• 503(“Service Unavailable”)
  重要程度：中等到高。

此响应代码表明HTTP服务器正常，只是下层web服务服务不能正常工作。最可能的原因是资源不足：服务器突然收到太多请求，以至于无法全部处理。由于此问题多半由客户端反复发送请求造成，因此HTTP服务器可以选择拒绝接受客户端请求而不是接受它，并发送503响应代码。

响应报头：服务器可以通过Retry-After报头告知客户端何时可以重试。

• 504(“Gateway Timeout”)
  重要程度：低。

跟502类似，只有HTTP代理会发送此响应代码。此响应代码表明代理无法连接上行服务器。

• 505(“HTTP Version Not Supported”)
  重要程度： 非常低。

当服务器不支持客户端试图使用的HTTP版本时发送此响应代码。

实体主体：一个描述服务器支持哪些协议的文档。