HTTP 请求头含义(必记)

  1.HTTP 状态码的含义:

HTTP状态码(HTTP Status Code)是用以表示网页 服务器HTTP响应状态的3位数字代码。它由 RFC 2616 规范定义的,并得到RFC 2518、RFC 2817、RFC 2295、RFC 2774、RFC 4918等规范扩展

  2.相应的字头的含义:

必记

1xx

消息字头  这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束

2xx

成功字头 这一类型的状态码,代表请求已成功被服务器接收、理解、并接受

3xx

重定向 这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。

4xx

请求错误字头 这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。除非响应的是一个 HEAD 请求,否则服务器就应该返回一个解释当前错误状况的实体,以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容

5xx6xx

服务器错误的字头 这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个HEAD 请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体,这些状态码适用于任何响应方法。

3.常见的状态码:

200:

请求已成功,请求所希望的响应头或数据体将随此响应返回

201

请求已经被实现,而且有一个新的资源已经依据请求的需要而建立,且其 URI 已经随Location头信息返回。假如需要的资源无法及时建立的话,应当返回'202 Accepted'

301

被请求的资源已永久移动到新位置,并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。如果可能,拥有链接编辑功能的客户端应当自动把请求的地址修改为从服务器反馈回来的地址。除非额外指定,否则这个响应也是可缓存的。

302

请求的资源临时从不同的 URI响应请求。由于这样的重定向是临时的,客户端应当继续向原有地址发送以后的请求。只有在Cache-ControlExpires中进行了指定的情况下,这个响应才是可缓存的。

304

如果客户端发送了一个带条件的 GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个状态码。304响应禁止包含消息体,因此始终以消息头后的第一个空行结尾。

400

1、语义有误,当前请求无法被服务器理解。除非进行修改,否则客户端不应该重复提交这个请求。

 2、请求参数有误。

401

当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么401响应代表着服务器验证已经拒绝了那些证书。如果401响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。

403:

服务器已经理解请求,但是拒绝执行它。与401响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个404响应,假如它不希望让客户端获得任何信息

405

请求行中指定的请求方法不能被用于请求相应的资源。该响应必须返回一个Allow 头信息用以表示出当前资源能够接受的请求方法的列表

413

服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。此种情况下,服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的,服务器应当返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。

414

请求的URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务

500

服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。一般来说,这个问题都会在服务器端的源代码出现错误时出现。



   

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
1. HTTP协议请求报文的格式如下: -行:包括请求方法、请求目标和HTTP协议版本。 - 请求头:包含各种请求相关的部信息如User-Agent、Host、Content-Type等。 - 空行:用于分隔请求头和请求体。 - 请求体:可选,包含请求的数据,如表单数据或JSON数据等。 HTTP协议响应报文的格式如下: - 状态行:包括HTTP协议版本、状态码和状态描述。 -应:包含各种响应相关的部信息,如Content-Type、Content-Length等。 - 空行:用于分隔响应和响应体。 - 响应体:包含响应的数据,如HTML页面、JSON数据等。 请求报文中的字段含义: - 请求方法:指定请求的类型,如GET、POST、PUT等。 - 请求目标:指定请求的URI或URL。 - HTTP协议版本:指定使用的HTTP协议版本,如HTTP/1.1。 - 请求头:包含各种部信息,用于传递额外的请求参数或元数据。 响应报文中的字段含义: - HTTP协议版本:指定使用的HTTP协议版本,如HTTP/1.1。 - 状态码:表示请求的处理结果,如200表示成功,404表示资源未找到等。 - 状态描述:对状态码的简要描述。 - 响应:包含各种部信息,用于传递额外的响应参数或元数据。 2. API文档一般包含以下几个部分: - 接口概述:对API的整体介绍和说明。 - 接口列表:列出所有可用的API接口及其简要描述。 - 接口详情:对每个API接口进行详细的说明,包括请求方式、请求参数、返回结果等。 - 示例代码:提供API的调用示例代码,方便开发人员参考和使用。 - 错误码说明:列出可能的错误码及其含义,方便错误处理和调试。 在接口测试中,API文档的不同部分发挥以下作用: - 接口列表:帮助测试人员了解所有可用的接口,选择需要测试的接口。 - 接口详情:提供了接口的详细说明,包括请求方式、参数和返回结果等,帮助测试人员编写测试用例和进行测试验证。 - 示例代码:提供了接口调用的示例代码,方便测试人员参考和使用,减少测试编写的工作量。 - 错误码说明:列出了可能的错误码及其含义,方便测试人员进行错误处理和调试。 3. 使用Apifox进行简单接口测试的步骤如下: 1. 注册并登录Apifox账号。 2. 创建一个新的项目,并命名。 3. 在项目中创建接口,填写接口的基本信息,包括请求方式、URL、请求参数等。 4. 设置接口的请求头和请求体,根据需要添加相应的参数和数据。 5. 发送接口请求,查看响应结果,并进行验证。 6. 根据需要,可以添加断言、预设测试数据等进行更详细的接口测试。 7. 根据测试结果进行分析和总结,记录测试用例并进行报告。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值