El servidor ha ocasionado una violación del protocolo. Sección = ResponseStatusLine ERROR


115

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:


71

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.


3
Tenía 6 URL que arrojaban este error. La configuración de useUnsafeHeaderParsing lo solucionó para un enlace, pero la configuración de KeepAlive = false lo solucionó para todos los 6.
David Hammond

3
Lo mismo se puede colocar dentro de la etiqueta raíz <configuration> en App.copnfig para aplicaciones no web (por ejemplo, arreglé la aplicación WPF de esa manera, ¡gracias!).
Yury Schkatula

¿Alguien sabe por qué IIS impone esta medida de seguridad? Funcionó, pero no entiendo el motivo de la restricción en los valores del encabezado (configurándolos manualmente en mi caso).
emran

26
Esto es simplemente evitar el problema en lugar de solucionarlo. Creo que esta no debería ser la solución predeterminada.
Tobias

4
De acuerdo con Tobias, estás evitando el problema. Ahora bien, puede ser que el problema esté en un servidor que no puede solucionar y, por lo tanto, evitarlo puede ser su única opción ... pero aún así, seamos claros sobre la diferencia entre evitar un error de protocolo y solucionarlo.
metaforge

58

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.


5
Ah, esto es lo que necesitaba. Gracias. Aquí hay un ejemplo de agente de usuario: stackoverflow.com/a/15144495/891976
David Ruhmann

Una línea rápida para usar WebClientaquí stackoverflow.com/a/11841680/4795214

5
Gracias. Si desea consultar GitHub a través de HttpClient agregar: client.DefaultRequestHeaders.Add("User-Agent", "Anything"); línea para corregir.
Cihan Yakar

32

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.


¡Simplemente lea esto después de recibir el 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ó :)
Intrepid

2
Este también era mi problema, aunque era complicado porque era la llamada DESPUÉS de la respuesta Sin contenido la que fallaba.
mdickin

Se someContentreturn Request.CreateResponse(HttpStatusCode.NoContent, someContent);
corrigió

12

Otra posibilidad: al hacer un POST, el servidor responde con un 100 continuar de forma incorrecta.

Esto resolvió mi problema:

request.ServicePoint.Expect100Continue = false;

Esto funcionó para mí al acceder a la API de MediaFire.
AlexPi

3
Sé que llego tarde pero, ¿qué quieres decir con "de manera incorrecta"?
kuskmen

1
Para cualquiera que use HttpClient , lo siguiente funcionó para mí:var http = new HttpClient(); http.DefaultRequestHeaders.ExpectContinue = false;
user2444499

9

Esto me estaba sucediendo cuando tenía Skype ejecutándose en mi máquina local. Tan pronto como cerré, la excepción desapareció.

Idea cortesía de esta página


Tenía el mismo problema. Resultó ser Skype. Es tan lamentable que no se puedan proporcionar los mensajes adecuados.
Jordan Koskei

en realidad no necesita cerrar Skype, agregué una respuesta a continuación para mostrar cómo abordarlo sin cerrar Skype.
AltF4_

8

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 /


De hecho, Fiddler está solucionando el problema que tengo con una solicitud GET HTTP. ¿Podemos ver lo que hace Fiddler?
Olivier MATROT

8

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).


Esta es la mejor respuesta. Explica por qué el servidor web no funciona correctamente. ¡Gracias! (Tengo que emular un servidor web con sockets debido a problemas de implementación con HttpListener.)
Andrew Rondeau

6

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; 

6

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.


2
y recuerde reiniciar IIS después de hacerlo
Ahmed Galal

3

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;

2

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 ();


2

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.



1

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.


0

En mi caso, IIS no tenía los permisos necesarios para acceder a la ruta ASPX relevante.

Le di permisos de usuario de IIS al directorio relevante y todo estuvo bien.


0

Vea su código y averigüe si está configurando algún encabezado con un valor NULL o vacío.


0

Empecé a recibir este error de mis servicios PHP JSON / REST

Comencé a recibir el error de las cargas POST relativamente raras después de agregar el ob_start("ob_gzhandler")script GET php al que se accede con más frecuencia

Puedo usar solo ob_start(), y todo está bien.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.