{转}关于HTTP的GET和POST请求

timg.jpgHTTP 414 - Request - URI Too Long --Nginx

以上的错误是折磨我2小时的东西,让我不得不记录下来。昨晚,我接到一个需求就是能不能通过API的形式备份和恢复数据库,一般人的做法就是将相关逻辑写在API服务端,通过API接口发送指令,然后备份和复制都这同一台服务器上,一开始我也是这么做的,实现也比较容易。但是现在的问题在于要从A服务器发送指令给API服务器B,将B中的数据缓存在A服务器上,然后A服务器发送数据给C服务器将从B上拷贝的数据恢复到C上去。

A服务器发送数据给C服务器将从B上拷贝的数据恢复到C上去

问题来了,这里要发送数据,为了保证数据类型也能完整的发送过去,同时为了减少HTTP请求次数,我将一整张表用PHPserialize函数,串行化成一个字符串,长长的字符串,通过URL拼接,直接发送过去,发现没有任何数据返回,而且在批量备份多个表的时候,并不是所有的数据都没法传送,只有2~3个表出错,所以我开始了漫漫的排错。

跟踪API服务器的API应用的Log,发现没有收到请求,所以继续去跟API服务器的Nginx的Log,发现依旧一切正常,再去跟PHP的Log,还是没有问题,因为我的测试机器的API服务和数据缓存服务在同台机器上,所以排除了数据发送服务的Nginx和PHP报错可能,最后只剩下发送服务的应用Log,跟了下,果然发现了原因的根本,HTTP 414 - Request - URI Too Long

GET和POST这两种HTTP数据请求/发送方式,在学习Web基础的时候我们就都有学到,同时对于他们之间的区别也很明白,最大的一个区别就在于,GET请求的数据量是有上限的,而POST却没有,但是在项目中,我却忽略了这个重要的因素,结果就是数据库一团糟。

最后说两句,在文章中,我排错的过程是我花了整整2个小时摸索出了的,其实这个事情中真正让我成长的便是这个!在没有页面报错的情况下,我们如何快速的定位到问题的根本?这个技能非常重要,还有就是,注意细节,能多想的就多想想,需求一直在变,主要在于你能不能看穿未来的需求!这便是经验吧~


0 Likes
你目前的身份是游客,评论请输入昵称和电邮!