对一些http的请求进行分析

前一篇文章说打算使用netty实现一个springmvc框架，但是在对ajax请求进行测试时却出现了问题
把请求的uri拿出来发现它的一部分是/test/[object%20Object] 这样的，而我的框架实现逻辑就是建立与对请求的各种头和uri进行分析，之前一直都是使用的普通的get和post方法没有什么问题但是今天打算测试一下异步通讯时出现了通过反射找不到方法的错误，下面我们通过一个简单的channel将传过来的数据转换为string进行比对看看都有什么不同

第一次查看时感觉可能是由于ajax将data合并到了uri上才导致的解析失败，但是我将data设为空也和是不行的，第二快的uri就是乱麻一样。

get请求是直接通过URL请求的
http://127.0.0.1/login.html
ajax请求是通过jquery实现的，代码如下

   <script>
        $(document).ready(function(){
            $("#test").click(function(){
                htmlobj=$.post({
                    type :"post",
                    contentType:"application/json;charset=UTF-8",
                    url:"http://127.0.0.1/test/ajaxtest/",
                    // data:{
                    //     "ajaxtest":"caohaoajaxtest"
                    // },
                    success:function(result){
                        $("#myDiv").text(result);
                    }
                });
            });
        });
    </script>

get请求
GET /login.html HTTP/1.1
        Host: 192.168.31.118:9001
        Connection: keep-alive
        Upgrade-Insecure-Requests: 1
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36
        Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: zh-CN,zh;q=0.9
----------------------------------------------
ajax请求
POST /test/[object%20Object] HTTP/1.1
Host: 192.168.31.118:9001
Connection: keep-alive
Content-Length: 0
Accept: */*
        User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.61 Safari/537.36
        X-Requested-With: XMLHttpRequest
        Origin: http://192.168.31.118:9001
        Referer: http://192.168.31.118:9001/test/test
        Accept-Encoding: gzip, deflate
        Accept-Language: zh-CN,zh;q=0.9

隔了一天找到了原因，是因为我在ajax的行里面加了
contentType:“application/json;charset=UTF-8”,
由于这个属性才导致的画uri错误
这个属性应该是在响应消息的消息头中的，这个代表了传送回来的实体信息的格式是Json并且编码格式是uft-8
去掉这个属性就可以成功的获得想要的uri了

解决了这个问题之后我发现我对于http协议的各种传输方法好像还是有很多不甚了解的地方
打算用postman编辑一些请求打印出来看一下他们真正的格式，他们的消息头，消息行，和内容部分都是怎么传输的

GET /test?test1=1&test2=2 HTTP/1.1
Accept: text/html
Accept-Charset: application/json
Accept-Language: application/json
User-Agent: PostmanRuntime/7.25.0
Postman-Token: 1816889e-8a52-4fe0-bb6a-231e94f578ad
Host: 192.168.31.118:9001
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

上面这个是一个设置了两个头信息（告诉服务器客户端可以接受的信息的格式）和两个数据的get请求
这个get请求的数据是放在消息行的uri上的

下面设计一个有
{
“name”:“caohao”,
“password”:123456,
“test”:{
“t”:“t”,
“e”:“e”
}
}
这样的data和一些头消息的post请求

POST /test HTTP/1.1
Content-Type: application/json
User-Agent: PostmanRuntime/7.25.0
Accept: */*
Postman-Token: f18e5548-a94e-422f-ac23-123d16959545
Host: 192.168.31.118:9001
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Content-Length: 75

{
	"name":"caohao",
	"password":123456,
	"test":{
		"t":"t",
		"e":"e"
	}
}

这里看到了我最想知道的东西，就是请求中的data到底是以什么形式传过来的，只有知道了这个才能将这些数据拿出来。