记一次因请求参数太长引发的"惨案"(retrofit+okhttp)

一个项目中有使用到retrofit+ NanoHTTPD（本地服务）。

然后在客户现场测试使用时出现本地服务之间通信出现了异常，消息发不出去。

拿到相关log后，一查，是json参数解析出错了，发现传递的参数很长，所有字符加起来有1W+

，应该是url长度问题，这块是之前同事开发的，当时没料到会有这么长的参数。

经过测试，减少长度后是没有问题的。然后查了相关资料如下：

"The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

      Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths."

HTTP协议不对URI的长度作事先的限制，服务器必须能够处理任何他们提供资源的URI，并且应该能够处理无限长度的URIs，这种无效长度的URL可能会在客户端以基于GET方式的请求时产生。如果服务器不能处理太长的URI的时候，服务器应该返回414状态码（此状态码代表Request-URI太长）。

NanoHTTPD服务端对url长度有限制，具体多少没查到，浏览器端如下：

估摸着也是8000左右。于是这种参数传递方式肯定是行不通的，需要改造。

把原本放在url后面的参数放在body里面，然后测试后，问题解决。