HTTP状态码及请求头

状态码

状态码告知从服务器端返回的请求结果

一般可分为5个大类

1XX	Informational(信息性状态码)
2XX	Success(成功状态码)
3XX	Redirection(重定向状态码)
4XX	Client Error(客户端错误状态码)
5XX	Server Error(服务器错误状态码)

只要遵守状态码类别的定义,即使改变RFC2616中定义的状态码,或者服务端自行创建状态码都没问题

2XX

2xx的响应结果表明请求被正常处理了

204

200这个就不说了, 说一下204这个响应, 该状态码表示已成功处理请求, 但是返回的响应报文中不含实体的主体部分. 也不允许返回任何实体的主体. 返回204响应,浏览器的页面不会发生更新.

如果只需要客户端往服务端发消息, 而服务端不需要响应内容的时候就可以使用这个状态码

206

该状态码表示客户端进行了范围请求, 而服务端成功执行了这部分的GET请求. 响应报文中含由Content-Range指定范围的实体内容.

.这种情况经常发生在客户端继续请求一个未完成的下载的时候(通常是当客户端加载一个体积较大的嵌入文件,比如视屏或PDF文件),或者是客户端尝试实现带宽遏流的时候.

3XX

官话来说就是在正确处理请求之前要执行某些操作

301

永久性重定向, 该状态码表示请求的资源已经被分配了新的url. 

302

临时重定向, 同是表示请求的资源新分配了地址, 希望用户本次能使用新的url访问

301和302类似, 但是如果页面保存了书签的话, 301会将书签地址修改(浏览器做的)

303

该状态码表示由于请求对应的资源存在着另一个url. 应使用GET方法定向获取请求的资源.

302和303有着相同的功能,但是303明确表示客户端应采用GET方法获取新资源

比如说一个POST请求得到的返回结果是要用GET重定向到另一个url上去,这里使用303是最理想的

301,302的标准是禁止将POST改成GET的, 但是实际上...

304 Not Modified

服务器资源未改变, 可以直接使用客户端未过期的缓存, 304响应不包含响应体

307 

同是临时重定向, 但是他不会改变请求的方式.

4XX

4XX的响应结果表明客户端是发生错误原因的所在

400 Bad Request

该状态码表示请求报文中存在语法错误,

401 Unauthorized

该状态码表示发送的请求需要通过HTTP认证的认证信息,如果之前进行过1次请求, 则表示用户认证失败, 浏览器初次接到401响应会弹出一个认证的对话窗口

403 Forbidden

这个大家肯定不陌生了, 就是拒绝你访问

404 Not Found

这个也是很熟悉的, 表示服务器上找不到资源, 也可以在服务器拒绝请求且不想说明理由时使用

405 Method Not Allowed

不支持该请求方法

5XX

5XX表示服务器本身发生错误

500 Internal Server Error

该状态码表示服务端在执行请求时发生了错误. 也有可能是web应用存在的bug或某些临时的故障

503 Service Unavailable

该状态码表示服务器暂时处于超负载或正在进行停机维护, 现在无法处理请求, 如果事先得知解除以上状态的时间, 最好写入RetryAfter首部字段再返回给客户端

 

最后要说的是, 状态码只算是一个规范, 状态码和状态不一致的情况也是经常发生的

头部字段

先写几个常用的吧

请求首部字段

Accept: 此字段通知服务器, 用户代理用户代理能够处理的媒体类型及媒体类型的相对优先级

Authorizstion: 用户的认证信息, 这个和HTTP的认证是有关的

Host: 告知服务器,请求资源所处的主机名和端口号

Referer: 告知服务器请求的原始资源的url,就是说从哪个地址过去的, 比如有些图片资源, 复制到别的网站就不能看了, 实际上复制的是a标签, 再去访问图片时该请求头就变了

User-Agent: 用于传达浏览器的种类

响应首部字段

Location: 该字段配合30X, 告知跳转的地址

实体首部

实体首部字段是包含在请求报文和响应报文中的实体部分所使用的首部,

Allow: 通知客户端能够支持 Request-URI 指定资源的所有 HTTP 方法。当服务器接收到不支持的 HTTP 方法时，会以状态码405 Method Not Allowed 作为响应返回。

Content-Type:说明了实体主体内对象的媒体类型。和首部字段 Accept 一样，字段值用 type/subtype 形式赋值。

除此之外还有cookie相关的和core跨域相关的, 后面在补充

HTTPS

HTTP 协议中没有加密机制，但可以通过和 SSL（Secure Socket Layer，安全套接层）或TLS（Transport Layer Security，安全层传输协议）的组合使用，加密 HTTP 的通信内容。用 SSL 建立安全通信线路之后，就可以在这条线路上进行 HTTP通信了。与 SSL 组合使用的 HTTP 被称为 HTTPS（HTTPSecure，超文本传输安全协议）或 HTTP over SSL。

HTTPS 采用共享密钥加密和公开密钥加密两者并用的混合加密机制。

在交换密钥环节使用公开密钥加密方式，之后的建立通信交换报文阶段则使用共享密钥加密方式。

公开密钥加密方式还是存在一些问题的。那就是无法证明公开密钥本身就是货真价实的公开密钥。公开密钥可能在传输过程中就被替换掉了, 为了证明公钥是服务端签发的, 可以使用由数字证书认证机构(CA)和其相关机关颁发的公开密钥证书.

步骤大概是:

• 服务器运营人员向数字证书认证机构提出公开密钥的申请. 
• 认证机构用自己的私有秘钥向服务器的公钥做数字签名, 然后将公开密钥和数字签名放入公钥证书
• 客户端(认证机构的公钥都会事先植入到浏览器里)拿到服务器的证书之后, 检验证书上的数字签名, 确认服务器公开密钥的真实性