HTTP 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个小时摸索出了的，其实这个事情中真正让我成长的便是这个！在没有页面报错的情况下，我们如何快速的定位到问题的根本？这个技能非常重要，还有就是，注意细节，能多想的就多想想，需求一直在变，主要在于你能不能看穿未来的需求！这便是经验吧~
本文由 陌上花开 创作，采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外，均为本站原创或翻译，转载前请务必署名
最后编辑时间为: Jul 1, 2016 at 06:26 am