伺服器提交了協議沖突

㈠ 08服務器無法遠程提示協議錯誤.

方法/步驟
1
中斷遠程桌面連接客戶端無法建立跟遠程計算機的連接。
導致這個錯誤的可能的原因是:
1) 遠程計算機上的遠程連接可能沒有啟用。
2) 已超出遠程計算機上的連接最大數。
3) 建立連接時出現了一個網路錯誤
具體的解決辦法：
有時候是這個錯誤提示：由於網路錯誤，連接被中斷，請重新連接到遠程計算機；遠程連接我肯定是開啟了的，防火牆裡面3389埠也是打開的，並且連接其他的伺服器就可以連接上，說明我本機沒問題，用掃描軟體，掃描了一下這個伺服器，顯示IP和埠都是存在的，說明這個伺服器網路也沒問題，實在沒辦法，只有不斷的測試，後來在系統日誌裡面看到很多條系統錯誤信息。其中：嚴重錯誤「RDP 協議組件 "DATA ENCRYPTION" 在協議流中發現一個錯誤並且中斷了客戶端連接。」幾經周折得知這是因為Certificate子鍵負責終端服務通信中數據信息的認證和加密，它一旦被損壞，終端服務的協議組件就會檢測到錯誤，中斷客戶機與終端伺服器之間的通信。導致Certificate子鍵損壞的原因很多，如管理員安裝和卸載某些系統軟體、對終端服務參數的不合理配置等。這時我們需要重置該鍵值中的內容，才能修復終端服務。
進入注冊表編輯器窗口，展開「HKEY_LOCAL_MA CHINE\ SYSTEM\CurrentCon trolSet\Services\TermService\ Parame ters」，找到名為 「Cer tificate」的子鍵，將它刪除，重新啟動XP系統或Windows 2000 server伺服器，系統就會重新生成 「Certificate」子鍵，這樣客戶端就能正常連接到終端伺服器了。
在終端伺服器出現無法連接的問題後，我們首先要判斷這是不是網路故障引起的，檢測遠程客戶端和XP系統(Windows 2000 Server伺服器)是否能夠正常連接到網路；然後就要檢查終端伺服器的加密級別是否設置過高。排除上述原因後，就有可能是「Certificate」子鍵損壞了。此外，「HKEY_LOCAL _MACHINE\ SYSTEM\Cur rentControlSet\Services\Term Service\Parameters」下的 「X509 Certificate」和「X509 Certificate ID」損壞了也有可能導致終端服務出現問題，它們的修復方法與「Certificate」子鍵損壞後的修復方法相同。

2
提示「本地計算機客戶端訪問許可不能升級或更新」的解決方法
1) 打開被控機的注冊表編輯器，定位到HKLM\SOFTWARE\Microsoft\MSLicensing。
2) 備份MSLicensing鍵。
3) 刪除MSLicensing鍵，重啟系統。

3
提示「遠程計算機已結束連接」
1) 打開被控機的注冊表編輯器，定位到HKLM\SYSTEM\ControlSet001\Enum\Root\RDPDR，備份該項；右鍵單擊該項，選擇「許可權」，為當前登錄的用戶增添「完全控制」的許可權。
2) 新建key文件，將以下內容寫入，雙擊導入注冊表後重啟計算機即可。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Enum\Root\RDPDR\0000]
"ClassGUID"="{4D36E97D-E325-11CE-BFC1-08002BE10318}"
"Class"="System"
"HardwareID"=hex(7):52,00,4f,00,4f,00,54,00,5c,00,52,00,44,00,50,00,44,00,52,\
00,00,00,00,00
"Driver"="{4D36E97D-E325-11CE-BFC1-08002BE10318}\\0030"
"Mfg"="(標准系統設備)"
"Service"="rdpdr"
"DeviceDesc"="終端伺服器設備重定向器"
"ConfigFlags"=dword:00000000
"Capabilities"=dword:00000000

4
提示「客戶端無法連接到遠程計算機」。
1) 遠程計算機不可到達（ping不通或者被防火牆攔截）
2) 伺服器沒有開啟3389埠（系統屬性里「遠程」頁面里的「遠程桌面」未打勾或沒有使用有遠程登陸許可權的用戶即可）
3) terminal services 服務未啟動，啟動此服務即可,另外還有兩個RDP服務也別忘記哦
4) 檢查遠程桌面是不是被更改了埠，步驟：打開「開始→運行」，輸入「regedit」，打開注冊表，進入以下路徑：[HKEY_LOCAL_MACHINE\SYSTEM\
CurrentControlSet\Control\Terminal Server\Wds\rdpwd\Tds\tcp]，看見PortNamber值了嗎？其默認值是3389如果不對請改回來。

㈡ C#發送郵件錯誤： System.net.mail.smtpException;伺服器提交了協議沖突 伺服器響應為： .

try
{
client.Send(message);
回 }
catch (SmtpException e)
{
Console.WriteLine("Error: {0}", e.StatusCode);
}
finally
{
data.Dispose();
}
檢查一答下e.StatusCode是否是GeneralFailure
如果是可能是 你自己發送的郵件賬號 有問題。比如賬號不存。。。

㈢ C#發送郵件錯誤： System.net.mail.smtpException;伺服器提交了協議沖突 伺服器響應為： .

try
{
client.Send(message);
}
catch (SmtpException e)
{
Console.WriteLine("Error: {0}", e.StatusCode);
}
finally
{
data.Dispose();
}
檢查一下e.StatusCode是否是GeneralFailure
如果是可能是 你自己發送的郵件賬號 有問題。比如賬號不存。。。

㈣ 伺服器提交了協議沖突. Section=ResponseHeader Detail=CR 後面必須是 LF 哪位高手教我解決下,詳細點的.

是伺服器有安全軟體，加入白名單就可以了 就不會出現這個問題了

㈤ 伺服器提交了協議沖突. Section=ResponseHeader Detail=「Content-Length」標題值無效

|The server committed a protocol violation

One of the issues involving XML-RPC.NET that turns up fairly frequently is when the library throws an instance of System.Net.WebException with the message ""The server committed a protocol violation". This usually occurs because from .NET 1.1 SP1 onwards the parsing of HTTP responses became much more strict, as a security measure to prevent attacks which exploit malformed HTTP status lines and headers. The strict behaviour can be switched off via the application config file:

<?xml version ="1.0"?>
<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
</configuration>

From .NET 2.0 this behaviour can be configured programmatically using the HttpWebRequestElement useUnsafeHeaderParsing property. At first when I read about this I assumed it was a property that can be set dynamically at runtime, for example in the same way as the HttpWebRequest KeepAlive property. But in fact its used in the new 2.0 configuration infrastructure to set the value in the config file (although once you do this the new value applies to the current running application as well as any apps launched afterwards. The new configuration infrastructure is pretty complex but this code seems to work ok:

Configuration config = ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.None);
SettingsSection section = (SettingsSection)config.GetSection(
"system.net/settings");
section.HttpWebRequest.UseUnsafeHeaderParsing = false;
config.Save();

ConfigurationUserLevel.None specifies that the configuration file in the same directory as the executable should be modified so this file has to be writable. The other options PerUserRoaming and PerUserRoamingAndLocal can be used in different scenarios.
Finally, I found the code below in a post on the .NET Framework Networking and Communication forum. This uses reflection to set the private field useUnsafeHeaderParsing to true and as a result may not be suitable in all scenarios where the relevant code access security permission is not available. (Note: add System.Configuration.dll as a reference to your project.)

public static bool SetAllowUnsafeHeaderParsing()
{
//Get the assembly that contains the internal class
Assembly aNetAssembly = Assembly.GetAssembly(
typeof(System.Net.Configuration.SettingsSection));
if (aNetAssembly != null)
{
//Use the assembly in order to get the internal type for
// the internal class
Type aSettingsType = aNetAssembly.GetType(
"System.Net.Configuration.SettingsSectionInternal");
if (aSettingsType != null)
{
//Use the internal static property to get an instance
// of the internal settings class. If the static instance
// isn't created allready the property will create it for us.
object anInstance = aSettingsType.InvokeMember("Section",
BindingFlags.Static | BindingFlags.GetProperty
| BindingFlags.NonPublic, null, null, new object[] { });
if (anInstance != null)
{
//Locate the private bool field that tells the
// framework is unsafe header parsing should be
// allowed or not
FieldInfo aUseUnsafeHeaderParsing = aSettingsType.GetField(
"useUnsafeHeaderParsing",
BindingFlags.NonPublic | BindingFlags.Instance);
if (aUseUnsafeHeaderParsing != null)
{
aUseUnsafeHeaderParsing.SetValue(anInstance, true);
return true;
}
}
}
}
return false;
}

㈥ 伺服器提交了協議沖突. Section=ResponseStatusLine

config里配置一下就行了：
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>

㈦ c#拋出異常 伺服器提交協議沖突 Section=ResponseStatusLine 求解決

asp.net 增強了安全性，對一些有危害的http 頭進行了判斷，比如url中有空格的情況，以幫助網站提版高網路攻擊的防權御能力。如果你的http頭中有一些ASP.NET 認為是有危害的信息，則會返回這個錯誤。
根本原因是微軟沒有容忍不符合RFC 822中的httpHeader必須以CRLF結束的規定的伺服器響應。
解決辦法是對web.config （app.config) 配置做一些調整

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing= "true " />
</settings>
</system.net>
</configuration>

㈧ 伺服器犯了協議沖突。Section=ResponseStatusLine

微軟沒有容忍不符合RFC 822中的httpHeader必須以CRLF結束的規定的伺服器響應。
通過修改配置文件專解決：在app.config(WinForm)或屬web.config(Web)文件里修改。

WinForm下的app.config默認不存在，手動在Debug文件夾所在的同級目錄下新建一個XML配置文件，內容為：
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing= "true " />
</settings>
</system.net>
</configuration>
編譯以後會在Debug下面自動創建一個 程序名.exe.config 的配置文件

㈨ 伺服器提交了協議沖突. Section=ResponseHeader Detail=CR 後面必須是 LF

獲取ip的地址可能拒絕了請求，你可以換一個地址，之前我也遇到過。

㈩ 一台伺服器能不能同時支持http和mms兩種協議

只要這兩種協議使用的不是同一個埠的話，應該是可以的話