Creé un programa, intenté publicar una cadena en un sitio y me sale 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?
Respuestas:
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 establecer la KeepAlivepropiedad en falso.
A veces, este error ocurre cuando el UserAgentparámetro de solicitud está vacío (en la api de github.com en mi caso).
Establecer este parámetro en una cadena personalizada no vacía resolvió mi problema.
WebClientaquí stackoverflow.com/a/11841680/4795214
HttpClient agregar: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); línea para corregir.
El culpable en mi caso fue devolver una No Contentrespuesta pero definir un cuerpo de respuesta al mismo tiempo. Que esta respuesta me recuerde a mí y tal vez a otros que no devuelvan una NoContentrespuesta con un cuerpo nunca más.
Este comportamiento es consistente 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.
The server committed a protocol violation. Section=ResponseStatusLine error al usar WebApi para devolver una NoContent()respuesta personalizada que estaba enviando No Contentla respuesta por alguna extraña razón! Una vez que eliminé eso, el problema desapareció :)
someContentreturn Request.CreateResponse(HttpStatusCode.NoContent, someContent);
Otra posibilidad: al hacer un POST, el servidor responde con un 100 continuar de forma incorrecta.
Esto resolvió mi problema:
request.ServicePoint.Expect100Continue = false;var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;
Esto me estaba sucediendo cuando tenía Skype ejecutándose en mi máquina local. Tan pronto como cerré, la excepción desapareció.
Una forma de depurar esto (y asegurarse de que es la violación del protocolo la que está causando el problema) es usar Fiddler (Http Web Proxy) y ver si ocurre el mismo error. Si no es así (es decir, Fiddler manejó el problema por usted), entonces debería poder solucionarlo usando el indicador UseUnsafeHeaderParsing.
Si está buscando una forma de establecer este valor mediante programación, consulte los ejemplos aquí: http://o2platform.wordpress.com/2010/10/20/dealing-with-the-server-committed-a-protocol-violation-sectionresponsestatusline /
Muchas soluciones hablan de una solución alternativa, pero no de la causa real del error.
Una posible causa de este error es si el servidor web utiliza una codificación diferente a ASCIIo ISO-8859-1para generar la sección de respuesta del encabezado. La razón para usarlo ISO-8859-1sería si Response-Phrasecontiene caracteres latinos extendidos.
Otra posible causa de este error es si un servidor web utiliza UTF-8esa salida del marcador de orden de bytes (BOM). Por ejemplo, la constante predeterminada Encoding.UTF8genera la lista de materiales, y es fácil olvidar esto. Las páginas web funcionarán correctamente en Firefox y Chrome, pero HttpWebRequestbombardearán :). Una solución rápida es cambiar el servidor web para usar la codificación UTF-8 que no genera la lista de materiales, por ejemplo new UTF8Encoding(false)(lo cual está bien siempre y cuando Response-Phrasesolo contenga caracteres ASCII, pero realmente debería usar ASCIIo ISO-8859-1para los encabezados, y luego UTF-8o alguna otra codificación para la respuesta).
La configuración de la expectativa 100 continúa en falsa y la reducción del tiempo de inactividad del socket a dos segundos resolvió el problema para mí
ServicePointManager.Expect100Continue = false;
ServicePointManager. MaxServicePointIdleTime = 2000; Skype fue la principal causa de mi problema:
Este error generalmente ocurre cuando ha configurado Visual Studio para depurar una aplicación web existente que se ejecuta en IIS en lugar del servidor web de depuración ASP.NET integrado. IIS escucha de forma predeterminada las solicitudes web en el puerto 80. En este caso, otra aplicación ya está escuchando las solicitudes en el puerto 80. Normalmente, la aplicación infractora es Skype, que de forma predeterminada se hace cargo de la escucha en los puertos 80 y 443 cuando se instala. 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 los puertos 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.
Intenté acceder a la API de 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;Ninguna de las soluciones funcionó para mí, así que tuve que usar un WebClient en lugar de una HttpWebRequest y el problema desapareció.
Necesitaba usar un CookieContainer, así que usé la solución publicada por Pavel Savara en este hilo: Uso de CookieContainer con la clase WebClient
simplemente elimine "protegido" de esta línea:
contenedor CookieContainer privado de solo lectura = new CookieContainer ();
Una causa probable de este problema es la configuración del Protocolo de descubrimiento automático de proxy web (WPAD) en la red. La solicitud HTTP se enviará de forma transparente a un proxy que puede devolver una respuesta que el cliente no aceptará o no está configurado para aceptar. Antes de hackear su código en bits, verifique que WPAD no esté en juego, particularmente si esto simplemente "comenzó a suceder" de la nada.
Lo primero que intentamos fue deshabilitar la compresión de contenido dinámico para IIS, eso resolvió los errores, pero el error no se produjo en el servidor y solo un cliente se vio afectado por esto.
En el lado del cliente, desinstalamos clientes VPN, restablecimos la configuración de Internet y luego reinstalamos los clientes VPN. El error también podría ser causado por un antivirus anterior que tenía 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.
Vea su código y averigüe si está configurando algún encabezado con un valor NULL o vacío.