HttpWebRequest 的一辈子都没有见过问题？

Question

服务器提交了协议冲突. Section=ResponseHeader Detail=CR 后面必须是 LF  The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF  主体意思是微软没有容忍不符合RFC 822中的httpHeader必须以CRLF结束的规定的服务器响应。  解决方案是在app.config或web.config文件里加入 
<configuration>
    <system.net>
        <settings>
            <httpWebRequest useUnsafeHeaderParsing="true" />
        </settings>
    </system.net>
</configuration><?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <system.net>
        <settings>
            <httpWebRequest useUnsafeHeaderParsing="true" />
        </settings>
    </system.net>
</configuration>
允许系统容忍（tolerant）只以CR或LF结尾的hearder信息 

Answer 1

我也碰到了这个问题，还在百度上找结果，无意中发现这个帖子，二楼的办法我试过，可以解决这个问题，但是被调用的WEBSERVERS有的功能却不在正常了，可用肯定不是代码的问题。所以现在我也还在继续找答案。留个脚印，如果我解决了我再回来回答你的问题。另外多说一句，LZ说的问题和二楼的回复的答案并不是一个问题根源。

Answer 2

仔细看了看LZ的问题，发现虽然异常结果是一样的，但是我是调用WEB SERVERS出现的这个问题。所以我就在想，是不是说当结果输出的时候被抛出异常？

Answer 3

2楼的好象解决问题,但据说这样会使得"网址解析攻击"变得更容易!
目前来看,用socket来代替HttpWebRequest可以很好的避免这一问题.
http://blogs.msdn.com/mflasko/archive/2005/11/02/488370.aspx

Answer 4

//关键是,咱们现在没有找到,也没有时间去找到一个彻底的解决办法,所以的解决办法正如2楼所说,那这样其实是牺牲了安全性啊,所以我们可以增加一点工作量,用socket来实现,避免这一问题,也是一种思路吧!哈哈

Answer 5

实际上也相对HttpWebRequestsocket也相对HttpWebRequestsocket更加灵活和稳定

Answer 6

对于LZ的问题，你提出的这个方法我也同意是个避免的方式，不过，我想会不会是对于返回的部分有问题，比如，他返回的内容中的头部分是不是含有其他的信息，但是这个信息并不是IIS能正常解析的，或者是IIS认为是错误的内容。所以才会有这个异常。

Answer 7

估计你的IE设置了代理！在代码中加入 限制访问时候使用代理
listRequest.Proxy = null;

Answer 8

估计你的IE设置了代理！在代码中加入 限制访问时候使用代理
listRequest.Proxy = null;