c# - ejemplo - El servidor ha ocasionado una violación del protocolo. Sección=ResponseStatusLine ERROR
webrequest post parameters c# (16)
A veces, este error se produce cuando el parámetro de solicitud del UserAgent está vacío (en github.com api en mi caso).
Establecer este parámetro en una cadena personalizada no vacía resolvió mi problema.
Creé un programa, traté de publicar una cadena en un sitio y recibí este error:
"El servidor cometió una infracción de protocolo. Section = ResponseStatusLine"
después de esta línea de código:
gResponse = (HttpWebResponse)gRequest.GetResponse();
¿Cómo puedo solucionar esta excepción?
El culpable en mi caso fue devolver una respuesta No Content pero definir un cuerpo de respuesta al mismo tiempo. Que esta respuesta me recuerde a mí y quizás a otros que no devuelvan una respuesta NoContent con un cuerpo nunca más.
Este comportamiento es coherente con 10.2.5 204 Sin contenido de la especificación HTTP que dice:
La respuesta 204 NO DEBE incluir un cuerpo de mensaje, y por lo tanto siempre termina con la primera línea vacía después de los campos de encabezado.
Empecé a recibir este error de mis servicios php JSON / REST
Empecé a recibir el error de relativley cargas POST raras después de que agregué ob_start("ob_gzhandler") a la secuencia de comandos GET php más frecuentemente visitada
Puedo usar solo ob_start() , y todo está bien.
En mi caso, IIS no tenía los permisos necesarios para acceder a la ruta ASPX relevante.
Puse los permisos de usuario de IIS en el directorio correspondiente y todo estaba bien.
Establecer esperar 100 continuar a falso y reducir el tiempo de inactividad del socket a dos segundos resolvió el problema para mí
ServicePointManager.Expect100Continue = false;
ServicePointManager. MaxServicePointIdleTime = 2000;
Esto estaba sucediendo cuando tenía Skype ejecutándose en mi máquina local. Tan pronto como cerré, la excepción desapareció.
Intenté acceder a la API Last.fm Rest desde detrás de un proxy y obtuve este famoso error.
El servidor ha ocasionado una violación del protocolo. Sección = ResponseStatusLine
Después de probar algunas soluciones, solo estas dos funcionaron para mí
HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ProtocolVersion = HttpVersion.Version10;
y
HttpWebRequest HttpRequestObj = WebRequest.Create(BaseUrl) as HttpWebRequest;
HttpRequestObj.ServicePoint.Expect100Continue = false;
Intente poner esto en su aplicación / web.config:
<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing="true" />
</settings>
</system.net>
Si esto no funciona, también puede intentar configurar la propiedad KeepAlive en falso.
Lo primero que hemos intentado fue deshabilitar la compresión de contenido dinámico para IIS, que resolvió los errores pero el error no se produjo en el lado del servidor y solo un cliente se vio afectado por esto.
Del lado del cliente, desinstalamos clientes VPN, reiniciamos la configuración de Internet y luego reinstalamos clientes VPN. El error también podría ser causado por antivirus previos que tenían firewall. Luego habilitamos la compresión de contenido dinámico y ahora funciona bien como antes.
Apareció un error en la aplicación personalizada que se conecta a un servicio web y también en TFS.
Mi problema fue que llamé a https endoipint con http .
Muchas soluciones hablan sobre una solución alternativa, pero no sobre la causa real del error.
Una posible causa de este error es si el servidor web utiliza una codificación que no sea ASCII o ISO-8859-1 para dar salida a la sección de respuesta del encabezado. La razón para usar ISO-8859-1 sería si la Response-Phrase contiene caracteres latinos extendidos.
Otra posible causa de este error es si un servidor web usa UTF-8 que genera el marcador de orden de bytes (BOM). Por ejemplo, la constante constante Encoding.UTF8 genera la BOM, y es fácil olvidar esto. Las páginas web funcionarán correctamente en Firefox y Chrome, pero HttpWebRequest bombardeará :). Una solución rápida es cambiar el servidor web para usar la codificación UTF-8 que no new UTF8Encoding(false) la lista de materiales, por ejemplo, new UTF8Encoding(false) (que está bien siempre que la Response-Phrase solo contenga caracteres ASCII, pero realmente debería usar ASCII o ISO-8859-1 para los encabezados, y luego UTF-8 u otra codificación para la respuesta).
Ninguna de las soluciones funcionó para mí, así que tuve que usar un WebClient en lugar de HttpWebRequest y el problema ya no existía.
Necesitaba usar un CookieContainer, así que usé la solución publicada por Pavel Savara en este hilo - Usando CookieContainer con clase WebClient
simplemente elimine "protegido" de esta línea:
private readonly CookieContainer container = new CookieContainer ();
Otra posibilidad: al hacer un POST, el servidor responde con un 100 continuar de una manera incorrecta.
Esto resolvió mi problema:
request.ServicePoint.Expect100Continue = false;
Una forma de depurar esto (y para asegurarse de que es la violación del protocolo que está causando el problema), es usar Fiddler (Http Web Proxy) y ver si ocurre el mismo error. Si no lo hace (es decir, Fiddler manejó el problema por usted), entonces debería poder arreglarlo usando el indicador UseUnsafeHeaderParsing.
Si está buscando una forma de establecer este valor programáticamente, vea los ejemplos aquí: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline/
Vea su código y busque si está configurando un encabezado con NULL o valor vacío.
Skype fue la causa principal de mi problema:
Este error generalmente ocurre cuando configura Visual Studio para depurar una aplicación web existente que se ejecuta en IIS en lugar del servidor web de depuración ASP.NET incorporado. IIS de forma predeterminada escucha las solicitudes web en el puerto 80. En este caso, otra aplicación ya está escuchando solicitudes en el puerto 80. Típicamente, la aplicación ofensiva es Skype, que por defecto se encarga de escuchar en los puertos 80 y 443 cuando está instalado. Skype ya ocupa el puerto 80. Por lo tanto, IIS no puede iniciarse.
Para resolver el problema, siga los pasos:
Skype -> Herramientas -> Opciones -> Avanzado -> Conexión:
Desmarque "Usar el puerto 80 y 443 como alternativas para las conexiones entrantes".
Y como se señala a continuación, realice un reinicio de IIS una vez hecho.