http 回应头的闷事

在编码过程中一点小的不注意可能让几天睡不着觉!

此事记录一来警戒自己每事必认真,二来给遇到些问题的同学你一些借鉴

前几天在写一个关于http下载的一个模块,下载地址也是从网络上http post后从回应头里面读出来参数.根据需求写完代码之后我把从参数读后TRACE到输出窗口,然后我从窗口copy数据到ie的地址栏中进行一次get操作结果OK.于是copy到的数据做为http下载模块的参数.一切也OK.呵呵,到两个模块合并测试的时候,把post后取得的参数直接传到下载模块,结果返回的是"
400 Bad request ".真是奇怪了怎么会是地址有错呢?可是TRACE出来的地址没有什么问题呀.

1.我判断是否编码出问题了:因从http 头返回的参数是UTF8编码.于是我把UTF8转成国标码后,再次测试还是同样的问题.

2.我把TRACE出来字符串与编码转换后的字符一下比较.

如下:

TRACE(strReturn);//打到输出

CString str = _T("TRACESTR");(从输出窗口copy)

if(str == strReturn)

{

TRACE("==");
}

结果还是不等( )

 

没办法我只好把这个参数通POST到服务器上,结果服务器一解析发现了一个问题

在参数的最后多了一个"/r"

这个我才明白过来.原来在取参数返回头参数的时候出现了问题.

因为返回头的格式是

XXXXX: YYYYYYYYYYY/r/n

我当初得到YYYYYYYYYYY的方法是取得"XXXX: "后面的所有字符,于是得到了YYYYYYYYY/r/n.

CString str1 = "YYYYYYYYYY";

CString str2 = "YYYYYYYYYY/r/n";

str1,与str2是不一样的字符串但是TRACE出来时str2只比str1多一个回车,要是没有认真分析是不易发现的.

最终经过修改把"/r/n"处理掉,一切又OK了.呵呵.

所以以后在写测试代码时要多注意这些细节问题,不然模块进行综合测试的时候会花费更多的时间.

此事浪费了我一天的调试时间,我记之.