通过对“是”与“应当”的划分，休谟从逻辑上把“事实”和“价值”区分开来，从而否定了在事实判断和价值判断之间存在必然的逻辑联系。他认为我们不能从关于“是”的事实命题推断出关于“应当”的价值命题，即从纯粹事实的描述性说明中不能推断出应当做什么的标准或有关道德的准则或规定。前者是关于某种状况自身属性非真即假的说明，而后者是关于某种状况与认识主体的利益和需要之间关系的评价以及主体对该状况的态度。一般地说，前者是认识论的问题，后者是价值论的问题。

我不懂爱情 - 轮回 又一次

也许是有爱情的 只是没有未来
又一个夏天 天空已不再蔚蓝

看安妮宝贝的书 听Beyond的歌  玩StarCraft 甚至看排球女将
都快怀旧到70后的领地去了

只能靠曾经的音乐翻出所有回忆 一一轻抚 好像自己唯一的家当 存在感得到了一些充实 然后更加空虚

这样日子久了会容易让人沉沦 直到死

自私如我的人 永远得不到爱情 无论相信与否

爱过 伤害过 然后离别 遗忘

我无法给她想要的 就如她无法给我想要的一样 或许相爱的两个人 徒劳的努力让人沮丧 隐约的绝望

2006-5-4

在登陆sina时遇到了一个问题：

在获取服务器响应时得到异常：

The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF

然后上网搜了一下，发现国外好多人都已经遇到这个问题了，比较好的解释问题的是微软技术论坛上的Reed Kimble，原文如下：

Here is the problem...  It is not a bug...

The Internet RFC 822, section 3.2, states that a Header Field in an internet message will be terminated with the character CRLF.  RFC 822 is referenced by nearly all other popular protocol RFCs, including RFC 2616 (the HTTP 1.1 RFC).  Unfortunately, RFC 2616 also has an antiquated recommendation under section 19.3 for "Tolerant Applications" that states "...the line terminator for message-header fields is the sequence CRLF.  However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.".  This recommendation is unfortunate because it is an obvious security risk to allow parsing of malformed headers and it has convinced some developers that there is no need to fix incomplete code that terminates a header with only LF or only CR.

As for IE rendering a page with one of these malformed headers... IE is a notoriously sloppy browser.  You can build a page that breaks LOTS of RFC rules and IE will still render it.  This is what has lead to the number of security issues that IE has had.

I've run into this error under VS05 using any of the WebResponse objects in a Windows Application.  There is no config file to be edited as mentioned in previous posts.  I'm trying to communicate with a hardware device that is embedded with windows mobile and provides a XML over HTTP host interface for communication.  Whatever webserver is running on this device formulates it's response headers using only a "LF" character.  Therefore none of the WebResponse objects can be created from a WebRequest object pointing to this device's URI.

The manufacturer of the device tells me that I must contact Microsoft and show them that MS has designed the .NET Framework to not be tolerant of malformed headers.  I was hoping someone from the organization could reply to this post and verify that the CF expects fully compliant Internet Message Headers.  Or, if there is a work around at the framework level (that is, one that will work for a Windows Fat Client) to please post it.  Although, I still feel that allowing my app to parse unsafe headers is a security risk and it would be better to see someone from MS confirm that this is the case and is the reason why, out of the box, the framework doesn't allow unsafe headers.

Reed Kimble

引用地址：http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=21106&SiteID=1

主体意思是微软没有容忍不符合RFC 822中的httpHeader必须以CRLF结束的规定的服务器响应。Sina的用的是“Apache/1.3.29 (Unix) PHP/4.3.9”技术，所以…

不过，一个解决方案是在application.config或web.config文件里加入

<configuration>

<system.net>

      <settings>

        <httpWebRequest useUnsafeHeaderParsing="true" />

      </settings>

</system.net>

</configuration>

允许系统容忍（tolerant）只以CR或LF结尾的hearder信息，问题便可以解决，起码现在对sina的访问经测试已解决，但论坛上仍有人说问题依然存在，我觉得两个可能，一是访问了更垃圾的服务器，二是这孩子没会添加上面的config信息。

嗯，有空时需要测试一下对blogbus的访问是否受到影响～

先写到这，因为这个问题好像国内还比较少见，写篇blog，希望对大家有所帮助。

14:51

对于2006-4-28 15:10日志中提到的sina发贴时数据上传的问题，其中的数据采用multipart/form-data 方式上传：

Content-Type: multipart/form-data; boundary= ---------------------------7d6cb303044c

在每条数据间出现一个形如-----------------------------7d6cb303044c的分隔符，经查证，此分隔由浏览器自动生成，不同浏览器有不同的分界，只要保证这个分界符不会出现在数据中。

具体文章可参见：http://www-128.ibm.com/developerworks/cn/java/fileup/index.html

15:10