2010-05-19 24 views
26

Estoy ejecutando el servidor de desarrollo Django 1.2 y obtengo estos mensajes de error de Broken Pipe cada vez que carga una página desde Chrome o Safari. Mi compañero de trabajo también está recibiendo el error cuando carga una página de su servidor de desarrollo. No tenemos estos errores cuando usamos Opera o Firefox.Django + WebKit = Tubo roto

Traceback (most recent call last): 
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 281, in run self.finish_response() 
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 321, in finish_response self.write(data) 
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages/django/core/servers/basehttp.py", line 417, in write self._write(data) 
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.py", line 300, in write self.flush() 
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/socket.py", line 286, in flush self._sock.sendall(buffer) 
error: [Errno 32] Broken pipe 

¿Alguien me puede ayudar? ¡Me estoy volviendo loco por esto!

+0

¿Cuánto tiempo se necesita para que la vista solicitada para funcionar? –

+0

La primera vez es rápido, pero después de obtener el error de tubería interrumpida, la carga de la página siguiente tarda ~ 10-15 segundos en completarse: S – jmagnusson

Respuesta

22

Esto no es un problema de Django. Su navegador probablemente está haciendo algo erróneo.

Este es un error común, que ocurre cada vez que su navegador cierra la conexión mientras el servidor dev es envío de datos todavía está ocupado.

Compruebe this Django ticket para obtener más información.

+0

Estaba teniendo este problema mientras usaba el servidor de desarrollo django (1.3 pre-alfa) y esta respuesta es correcta porque django no tiene la culpa (el navegador era Chrome/Safari). Pude resolver el problema enviando mis solicitudes ajax como POST en lugar de GET. Por algún motivo, ambos buscadores no esperaban la respuesta si la solicitud de ajax se realizaba a través de GET. – awesomo

+0

¡Correcto! La respuesta de @loretoparisi da una idea de lo que podría causar ese comportamiento. –

2

Tuve un problema posiblemente relacionado.

Al usar Safari y Chrome en Windows, en mi máquina local en mi servidor de ejecución django, , algunas vistas no respondían aleatoriamente a las solicitudes POST ajax.

La solución fue la siguiente:

Los datos pasaba a la vista a través de POST era par sólo una clave/val: "action = eliminar". Ahora, en realidad no estaba usando esta información en mi opinión. Una vez que asigné los datos a una var en mi vista, (es decir, foo = request.POST ['action']), la vista devolvería una respuesta a las solicitudes ajax todo el tiempo.

¡Absolutamente loco!

13

Recientemente me encontré con este problema con el servidor de desarrollo django v1.1.1 y Chrome 7.0.517.44.

La "solución" que descubrí siempre está haciendo una actualización (mantenga presionada la tecla Shift y haga clic en el botón de recarga en Chrome) en la página después de la carga inicial, lo que hace que Chrome ignore su caché para los recursos solicitados por la actualización

Como tal, esto me lleva a pensar que es un problema con la notoria tendencia de Chrome a almacenar en caché todo lo que pueda; incluso cuando no debería. Supongo que Chrome está haciendo una solicitud de recursos y luego retirando de inmediato la conexión de dicho recurso una vez que se da cuenta de que tiene el recurso en la memoria caché.

Esto sería casi una solución soportable, excepto que las solicitudes AJAX todavía causarán problemas.

3

Una tubería rota ocurre cuando el navegador cierra la conexión con el servidor. Este problema me sucedió antes en la solicitud de publicación de ajax asociada con <a href="... porque olvidé agregar e.preventDefault() en la función del administrador de clics. Entonces, lo que sucedió es que el navegador envía la solicitud de publicación y cierra la conexión y envía otra solicitud de obtención. Entonces verá que la solicitud de publicación fue cancelada por el navegador.

7

Esto puede deberse a un error en la función javascript que envía la llamada ajax.

Por ejemplo, la función puede ser activada por un evento de clic en un enlace, y si no se previene la acción predeterminada del enlace, obtendrá una solicitud secundaria de inmediato y el navegador cerrará la conexión anterior sin esperar la respuesta para terminar. Tuve el mismo problema cuando olvidé agregar return false al controlador de eventos.

El mismo síntoma puede ocurrir si el controlador de eventos que activa ajax arroja una excepción.

Depura cuidadosamente la función que realiza la solicitud ajax y el valor de retorno de esa función.

+1

¡GRACIAS! Acabo de pasar una hora averiguando que necesitaba ese "retorno falso" en mi jquery ajax. Solo se ha necesitado para el POST y, como tal, me ha echado de menos esta vez ... – InfinteScroll

0

En el caso de que esto ocurra con un cliente JavaScript, una solución podría ser la siguiente. Hay que añadir preventDefault y return false al principio y al final de su controlador de eventos como:

$('#btn_analyze').click(function(e) { 
    e.preventDefault() 
    $.post('/api/v1/analyzer/', 
     data, 
     "json").done(function(response) { 
     //... 
    }).fail(function() { 
     Logger.error(" Error ") 
    }) 

    return false 
}) // analyze click 
+0

Amigo, esto no es javascript ... – jmagnusson

+0

@jmagnusson bien, tuve el mismo problema con un cliente de JavaScript, por eso. Explicado en la respuesta entonces! – loretoparisi

+0

¡Gracias! Es exactamente lo que estaba causando el problema en Chrome. Firefox lo entendería bien. ¡Voto! –