一个base64引发的血案
2017-08-31 16:56
232 查看
结果发现header跟body之间多了一个换行符('\r\n'),http协议默认header和body之间有一个空行隔开,也就是一个只含有\r\n的行,但是多了一个\r\n,就会导致服务器取body的时候从这个多出来的\r\n开始取content-length个字符,这样body里最后的两个字符就被这个多出来的\r\n挤掉了
而通过观察,这个原因是由于header的最后一个字段Authorization: Basic eHh4eHh4eDp4eHh4eHh4后面多了一个"\n"导致,
这个字段的值是同事经过base64.encodestring("XXXXXX:XXXXXX")编码后得到的字符串,查看了一下python的lib doc,发现这个函数默认返回一个以"\n"结尾的字符串,这就这个问题的根本原因,replace掉其中的\n,一切就都OK了
base64.encodestring返回的字符串默认结尾带"\n",而且产生的base64编码字符串每76个字符就会用"\n"隔开,所以最安全的方法不是strip去掉结尾的\n,而是用replace去掉其中所有的\n。为啥base64.ecodestring每76字符就换行,这个是mime协议的规定,用于email发送,具体查看mime协议吧
而通过观察,这个原因是由于header的最后一个字段Authorization: Basic eHh4eHh4eDp4eHh4eHh4后面多了一个"\n"导致,
这个字段的值是同事经过base64.encodestring("XXXXXX:XXXXXX")编码后得到的字符串,查看了一下python的lib doc,发现这个函数默认返回一个以"\n"结尾的字符串,这就这个问题的根本原因,replace掉其中的\n,一切就都OK了
base64.encodestring返回的字符串默认结尾带"\n",而且产生的base64编码字符串每76个字符就会用"\n"隔开,所以最安全的方法不是strip去掉结尾的\n,而是用replace去掉其中所有的\n。为啥base64.ecodestring每76字符就换行,这个是mime协议的规定,用于email发送,具体查看mime协议吧
相关文章推荐
- 一个base64引发的血案
- Silverlight Image Source URI : 一个反斜杠引发的血案
- 一个static 引发的“血案”
- 一个由session.close()引发的血案
- 一个“Spring轮子”引发的“血案”(2)
- 一个游标引发的血案,哈哈
- FFmpeg Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 23518,一个空格引发的血案
- hello world, 想说爱你不容易 —— 一个空格引发的血案
- 由一个自动部署脚本引发的血案。。。This is very likely to create a memory leak
- 一个电容引发的血案-经验教训篇
- 一个“Spring轮子”引发的“血案”(2)
- 一个“Sprng轮子”引发的“血案”(3)
- 一个斜杠引发的血案
- 一个“Spring轮子”引发的“血案”(6)
- 一个“Spring轮子”引发的血案(1)
- 一个Assert引发的血案
- 一个脚本引发的血案 推荐
- 一个普通ERROR 1135 (HY000)错误引发的血案:
- 一个“Spring轮子”引发的血案(1)
- MySQL中一个双引号的错位引发的血案