本周,在群里和东哥对 HTTP 接口请求进行了激烈的讨论,也让我对接口的请求处理有了一些不一样的看法

HTTP 请求头设置

如果对 HTTP 请求头,不是很了解到同学,可以先查看这篇 Blog HTTP 详解

请求头的设置,会直接影响到请求参数的格式和请求结果

常用的头设置说明
1: HTTP/1.1
HTTP/1.1 请求必须包含主机头域,否则系统会以 400 状态码返回

2: Accept:/
Accept:告诉 WEB 服务器自己接受什么介质类型,/ 表示任何类型,type/* ,表示该类型下的所有子类型,type/sub-type

3: User-Agent
User-Agent 头域的内容包含发出请求的用户信息。Referer 头域允许客户端指定请求 uri 的源资源地址,这可以允许服务器生成回退链表,可用来登陆、优化 cache 等

4: Content-type
Content-Type 实体头用于向接收方指示实体的介质类型,指定 HEAD 方法送到接收方的实体介质类型,或 GET 方法发送的请求介质类型,表示后面的文档属于什么 MIME 类型

在接口测试中,常用的方法有四种,GET、POST、PUT、DEL ,而 GET 方法请求中,最常见的就是由于 URL 中含有特殊字符导致在传递参数时,导致接口请求请求参数被改变,服务器解析失败。

以下两个例子,是我在工作中碰到的比较有特点的两个例子

例 1 :

将以下 URL 地址放入 Google Chrome ,按 F12 ,观察请求参数与实际参数的区别
Test Addr

你会发现, 你的请求参数应该是

dFRLTecWI5V2ke6xoVj33qmvmI0r3g+nQNsqYxPDmn6Y4c8NXPjwhNvLWX9ueQ02zr99dQl5O2Foxl0EnSgn8B75b4q+4aRsT6qq6D5b91K86Y3Kb8lUanQS7f7k6Z6ElXIXUlm3ZGY7U5v9qlP1G3VuhENd5JdQqRGdgHDssL7Y6E2WtYARbp7CuTVGi0pCBByrFsd3XGpuSmy7acMLUQ==

但是实际 Http 发送出去的参数却是这样的

dFRLTecWI5V2ke6xoVj33qmvmI0r3g nQNsqYxPDmn6Y4c8NXPjwhNvLWX9ueQ02zr99dQl5O2Foxl0EnSgn8B75b4q 4aRsT6qq6D5b91K86Y3Kb8lUanQS7f7k6Z6ElXIXUlm3ZGY7U5v9qlP1G3VuhENd5JdQqRGdgHDssL7Y6E2WtYARbp7CuTVGi0pCBByrFsd3XGpuSmy7acMLUQ==

这也是在接口测试中,关于 Get 方法的常规使用中,极其容易出现的问题。至于怎么解决这个问题,方法有很多,甚至只需要把 GET 方法替换成 POST 即可 (很多同学认为接口其实大部分是 POST 的,不尽然,具体看业务情况和可控的安全范围)

例 2 :

在常见的 Post 方法中,一般 POST 的参数其实是一个 json 或称为 object 的 dict,但是,很可能因为 URL 请求时,使用了请求头为

  • Content-type:x-www-form-urlencoded
  • (这里就不额外提供一条这样的接口了,如果有兴趣,可以自己尝试一下)

    那么很有可能代码如下 (伪代码)

    import requests
    headers = {}
    postdata = {"key_1":"value_1","key_2":"value_2"}
    headers['Content-type'] = "x-www-form-urlencoded"
    page = requests.post(url='xxxxx.json',data = postdata,headers )
    
    

    那么你 post 出去的参数格式,很可能是一个 key_1=value_1&key_2=value2 这样的一个格式

    由于时间关系,暂时写到这里 ,学习需要点滴积累,希望大家能在 TesterHome 学到更多的知识,认识更多志同道合的朋友!


    ↙↙↙阅读原文可查看相关链接,并与作者交流