服务器提交了协议冲突

㈠ 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两种协议

只要这两种协议使用的不是同一个端口的话，应该是可以的话