以下是引發問題的代碼:
網上查了一下,發現都是這樣:
解決方案:winfrom 在app.config種添加 web 在 web.config種添加
<
system.net
>
<
settings
>
<
httpWebRequest
useUnsafeHeaderParsing="true" />
</
settings
>
</
system.net
>
useUnsafeHeaderParsing的值【該方法須在發送請求之前進行設定否則無效果】
ToggleAllowUnsafeHeaderParsing(true);
public static bool ToggleAllowUnsafeHeaderParsing(bool enable) { Assembly assembly = Assembly.GetAssembly(typeof(SettingsSection)); if (assembly != null) { Type settingsSectionType = assembly.GetType("System.Net.Configuration.SettingsSectionInternal"); if (settingsSectionType != null) { object anInstance = settingsSectionType.InvokeMember("Section", BindingFlags.Static | BindingFlags.GetProperty | BindingFlags.NonPublic, null, null, new object[] { }); if (anInstance != null) { FieldInfo aUseUnsafeHeaderParsing = settingsSectionType.GetField("useUnsafeHeaderParsing", BindingFlags.NonPublic | BindingFlags.Instance); if (aUseUnsafeHeaderParsing != null) { aUseUnsafeHeaderParsing.SetValue(anInstance, enable); return true; } } } } return false; }
以上代碼引用自:https://www.cnblogs.com/aochulai/p/3881415.html,並且添加了 ToggleAllowUnsafeHeaderParsing(true); 后果然OK了。
但問題所在是在哪里呢,所謂前人栽樹,后人乘涼。從https://www.cnblogs.com/lewisli/p/6775010.html得出該問題的查找方法。
其實“服務器提交了協議沖突. Section=ResponseHeader Detail=CR 后面必須是 LF” 這個問題的原因主要是以下幾點導致的:
從百度得知:
在文本處理中, CR, LF, CR/LF是不同操作系統上使用的換行符.
Dos和windows采用回車+換行CR/LF表示下一行,
而UNIX/Linux采用換行符LF表示下一行,
CR等於回車(\r),LF等於換行(\n)
在HTTP協議中HTTP Header請求信息中的每一行都必須是在CRLF來結束。
服務器檢測到你提交的請求不符合HTTP協議的這個規定,所以拒絕了你的請求。
那么究竟是哪一個部分產生出了不符合HTTP協議的格式的信息,是在http header的請求(Request)部分,還是響應信息(Response)部分呢?
是我提交的header的格式沒有按照“CRLF結尾”的規定,還是服務器根據我提交的heaer所產生的響應header沒有按照“CRLF結尾”的規定?
於是我打開WireShark,監測要連接的IP。
以下是POST的信息:
以下是返回的信息:
最終得出,服務端返回的信息頭里邊的Content-Type沒有以\r\n結尾。
參考文章:
https://www.cnblogs.com/lewisli/p/6775010.html
http://www.360doc.com/content/11/0113/20/3508740_86319358.shtml
https://my.oschina.net/EricWe/blog/126844
http://www.360doc.com/content/10/0930/17/3668821_57590979.shtml