HttpWebRequest no funciona, excepto cuando se está ejecutando fiddler

Question

Este es probablemente el problema más extraño que me he encontrado. Tengo un fragmento de código para enviar POST a una url. El código no funciona ni arroja ninguna excepción cuando el violín no se está ejecutando. Sin embargo, cuando se está ejecutando el violín, el código publica los datos con éxito. Tengo acceso a la página de publicación para saber si los datos han sido PUBLICADOS o no. Esto es probablemente muy sin sentido, pero es una situación con la que me estoy encontrando y estoy muy confundido.

byte[] postBytes = new ASCIIEncoding().GetBytes(postData); 
HttpWebRequest req = (HttpWebRequest)WebRequest.Create("http://myURL); 
req.UserAgent = "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10 (KHTML, like Gecko) Chrome/8.0.552.224 Safari/534.10"; 
req.Accept = "application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"; 
req.Headers.Add("Accept-Charset", "ISO-8859-1,utf-8;q=0.7,*;q=0.3"); 
req.Headers.Add("Accept-Language", "en-US,en;q=0.8"); 
req.Method = "POST"; 
req.ContentType = "application/x-www-form-urlencoded"; 
req.ContentLength = postBytes.Length; 
req.CookieContainer = cc; 
Stream s = req.GetRequestStream(); 
s.Write(postBytes, 0, postBytes.Length); 
s.Close(); 

Answer 1

Si usted no llama GetResponseStream() entonces no se puede cerrar la respuesta. Si no cierra la respuesta, termina con un socket en mal estado en .NET. DEBE cerrar la respuesta para evitar interferencias con su solicitud posterior.

Answer 2

Está bien que se han enfrentado a problemas similares unas semanas y la razón era que cuando está funcionando violinista cambia la configuración de proxy para aprobar la solicitud a través violinista pero cuando está cerrado el proxy de alguna manera todavía permanece y por lo tanto no se permita que su solicitud continúe en internet.

Intenté estableciendo las configuraciones de red de IE y Firefox para no tomar ningún proxy y funcionó.

Prueba de esto, puede ser el mismo problema ...

Answer 3

Tuve un problema similar recientemente. Wireshark mostraría que HTTPWebRequest no salía de la máquina del cliente a menos que se estuviera ejecutando Fiddler. Intenté eliminar la configuración del proxy, pero eso no solucionó el problema. Intenté todo, desde configurar la solicitud a HttpVersion.Version10, habilitar/deshabilitar SendChuck, KeepAlive y una serie de otras configuraciones. Ninguno de los cuales funcionó.

En última instancia, acabo de comprobar si .Net detectó un proxy e hizo que la solicitud intentara ignorarlo. Eso solucionó mi problema con request.GetResponse() lanzando una excepción inmediata.

IWebProxy proxy = request.Proxy; 

if (request.Proxy != null) 
{ 
    Console.WriteLine("Removing proxy: {0}", proxy.GetProxy(request.RequestUri)); 
    request.Proxy = null; 
} 

Answer 4

En mi caso, cuando tuve la misma situación (POST sólo funciona cuando está funcionando violinista) el código estaba enviando el POST desde una aplicación que se ejecuta en IISExpress en un entorno de desarrollo detrás de un proxy a un servidor externo. Aparentemente, incluso si tiene configuraciones de proxy configuradas en Opciones de Internet, el entorno en el que se está ejecutando IIS puede no tener acceso a ellas. En mi entorno de trabajo simplemente tuve que actualizar web.config con la ruta al script de configuración de nuestro proxy. Es posible que deba modificar otras configuraciones de proxy. En ese caso, su amigo es esta página de MSDN que explica cuáles son: http://msdn.microsoft.com/en-us/library/sa91de1e.aspx.

Al final incluí lo siguiente en la aplicación web.config y luego se realizó el POST.

<configuration> 
    <system.net> 
    <defaultProxy> 
     <proxy scriptLocation="http://example.com:81/proxy.script" /> 
    </defaultProxy> 
    </system.net> 
</configuration> 

Answer 5

Cierre el HttpWebResponse después de conseguirlo.

Tuve el mismo problema, luego comencé a cerrar las respuestas después de cada solicitud, y Boom, no es necesario tener el fiddler ejecutándose.

Este es un pseudo de un código sincrónico:

request.create(url); 

///codes 

httpwebresponse response = (httpwebresponse)request.getresponse(); 

/// codes again like reading it to a stream 

response.close(); 

Answer 6

me encontré con el mismo problema con Python - peticiones a un servidor local estaban fracasando con un 404, pero luego cuando les encontré con Fiddler funcionamiento se estaban trabajando correctamente

La verdadera clave del problema aquí es que Fiddler funciona actuando como un proxy para el tráfico HTTP para que todas las solicitudes de la máquina local pasen por Fiddler en lugar de directamente a la red.

En la situación exacta en la que estaba, yo estaba haciendo peticiones a un servidor local, el tráfico regular pasa a través de un proxy y en Local Area Network (LAN) Settings para la conexión de red del panel Proxy server la opción Bypass proxy server for local addresses se comprobó.

Mi sospecha es que el "servidor proxy de derivación para direcciones locales" no es necesariamente recogido por el lenguaje de programación, pero los detalles del servidor proxy son. Fiddler es consciente de esa política, por lo que las solicitudes a través del trabajo de Fiddler, pero las solicitudes directas del lenguaje de programación no lo hacen.

Al configurar el proxy para la solicitud del servidor local a nada, funcionó correctamente desde el código. Obviamente, eso podría ser una sorpresa si te encuentras moviéndote de un servidor interno a uno externo durante la implementación.

Answer 7

Me enfrenté al mismo escenario: estaba realizando la POST hasta un punto final detrás de la Autenticación de Windows.

Fiddler keeps a pool of open connections, pero su prueba de C# o secuencia de comandos de powershell no cuando se ejecuta sin violín.

Para que pueda hacer la prueba/secuencia de comandos para mantener también un grupo de conexiones autenticadas abiertas, configurando la propiedad UnsafeAuthenticatedConnectionSharing como verdadera en su HttpWebRequest. Lee more about it here, microsoft KB. En ambos casos en ese artículo, puede ver que están haciendo dos solicitudes. El primero es un GET o HEAD simple para obtener el encabezado de autenticación (para completar el protocolo de enlace), y el segundo es el POST, que usará el encabezado obtenido anteriormente.

Aparentemente usted no puede (tristeza) directamente hacer el apretón de manos con solicitudes HTTP POST.

Answer 8

Estamos teniendo un problema muy similar aquí. Nos estamos conectando a servicios remotos y parecen fallar casi siempre. Sin embargo, cuando hacemos proxy a través de Fiddler (desde el servidor web) todo funciona espléndidamente. Estamos trabajando para depurar ahora, sin embargo, parece que este es un problema muy similar.

Answer 9

Utilice siempre el constructo. que asegúrese de que toda liberación de recursos después de la llamada siguientes entradas

using (HttpWebResponse responseClaimLines = (HttpWebResponse)requestClaimLines.GetResponse()) 
       { 
        using (StreamReader reader = new StreamReader(responseClaimLines.GetResponseStream())) 
        { 
         responseEnvelop = reader.ReadToEnd(); 
        } 
       } 

añadir a WEBconfig archivo

<system.net> 
<connectionManagement> 
<add address="*" maxconnection="30"/>