HTTP协议基础

最新推荐文章于 2023-09-06 07:00:55 发布

jwzhangjie

最新推荐文章于 2023-09-06 07:00:55 发布

阅读量1.7k

点赞数 1

分类专栏： IOS android 文章标签： http协议

本文链接：https://blog.csdn.net/jwzhangjie/article/details/46012315

版权

android 同时被 2 个专栏收录

153 篇文章 1 订阅

订阅专栏

IOS

9 篇文章 0 订阅

订阅专栏

报文组成方式

起始行(start line)；
包含属性的首部(header)块；
可选的、包含数据的主体(body)部分。

报文的语法

请求报文(request message)
<method> <request-URL> <version>
<headers>
<entity-body>
响应报文(response message)
<version> <status> <reason-phrase>
<headers>
<entity-body>

方法
GET
GET是最常用的方法，通常用于请求服务器发送某个资源。
HEAD
HEAD方法和GET方法的行为类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源情况下，对资源的首部进行检查。这可以验证服务器是否有效
PUT
与GET从服务器读取文档相反，PUT方法会向服务器写入文档。
POST
通常会用它来支持HTML的表单，表单中填好的数据通常会被送给服务器，然后由服务器将其发送到其他的地方。
TRACE
客户端要发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的HTTP请求。TRACE允许客户端在最终将请求发送给服务器时，看看它变成什么样子。
TRACE请求会在目的服务器发起一个"环回"诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改。
TRACE方法主要用于诊断；但它确实也有缺点，它假定中间应用程序对各种不同类型请求(不同的方法--GET、HEAD、POST等)的处理是相同的。比如，代理可能将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序(比如Web缓存)。TRACE不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。
TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
OPTIONS
OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操作)。
这位客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判断访问各种资源的最优方式。
DELETE
DELETE方法所做的事情就是请求服务器删除请求URL所指定的资源。但是客户端应用无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。

状态码

HTTP状态码分为五大类。

100~199——信息性状态码
HTTP/1.1向协议中引入了信息性状态码。

200~299——成功状态码
客户端发起请求时，这些请求通常都是成功的。服务器有一组表示成功的状态码，分别对应于不同类型的请求。
- 300~399——重定向状态码
- 重定向状态码要么告诉客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的Location首部来告诉客户端资源已被移除，以及现在可以在那里找到它，这样浏览器就可以在不打扰使用者情况下，透明地转入新的位置。
- - 400~499——客户端错误状态码
  - 有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，或者最常见的是，请求一个不存在的URL。
  - - 500~599——客户端错误状态码
    - 有时客户端发送一条有效请求，服务器自身却出错了。这可能是客户端碰上了服务器的缺陷，或者服务器上的子元素，比如某个网管资源，出了错。