本文来自discuz官方论坛，由用户fangshawn发表。

最近帮网友调试uc通信不成功；经调试后发现，通信其实是成功的，但由于服务器无法确定返回的字符长度，所以采用Chunked编码动态的提供body内 容的长度;通信把编码应该出掉的部分没去除；具体调试如下；
在之前调试采用了别人的调试方法：也介绍过给网友们；就是下面这文章；
http://www.discuz.net/viewthread … &from=favorites
我的介绍就是在这基础上吧！
echo “\$url = $url <br />\n \$status = $status<br />\n”;die(‘haha’);
在上面打印status时；status返回是 110;

我尝试着找到低层代码，返回了以下结果；
HTTP/1.1 200 OK Connection: close Date: Thu, 28 Jan 2010 05:12:41 GMT Content-Type: text ml Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-Powered-By: PHP/5.2.9-2 Transfer-Encoding: chunked 1 1 0
也就是说 Connection 是OK；但代码接口返回结果时却不是返回我们想要的 1；而返回了110；浏览器直接调试接口时，返回的又正确是1；
最后查资料发现这个小秘密 Transfer-Encoding: chunked 1 1 0 前面的1是chunked编码后的长度;最后的0是chunked的结束符；

我尝试着在接口入口处就直接返加字母a ；结果status 变成1a0了；哈哈；

这样子在uc平台后面的通信显示是不成功的，但其实是通信是通了；会不会对同步登录造成影响我未有深入，(因为最后网友神奇的说重起了服务器就通信成功 了)
个人觉得不影响，因为同步登录是是有标签的，Chunked编码并不会改变标签；
哈哈；大家觉的呢

如果大家发因为上面的chunked编码导致同步登录不正常,留言;我会试着找出解决的方法
麻烦不找我,我也不去找麻烦;哈哈

我是曾经遇到，通信正常，但其他操作不正常，那是因为无法往应用的uc目录下写文件，还有uc_client的Cache目录。都必须要可写。因为uc的配置文件和uc_client中的Cache都会在更改应用信息的时候同步更新。