Django + WebKit = tubo Roto

StackOverflow https://stackoverflow.com/questions/2868059

  •  01-10-2019
  •  | 
  •  

Pregunta

Estoy corriendo el servidor de desarrollo de Django 1.2 y obtener estos mensajes de error tubería rota cada vez que carga una página de él con Chrome o Safari. Mi compañero de trabajo está recibiendo el error, así cuando se carga una página de su servidor de dev. No tenemos estos errores al usar Opera o Firefox. 

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? Voy loca por esto!

¿Fue útil?

Solución

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

  

Este es error común que ocurre   cada vez que el navegador se cierra la   conexión mientras el servidor está dev   Todavía se está enviando datos de disponibilidad.

este billete de Django para obtener más información.

Otros consejos

Sólo recientemente se encontró con este problema con el servidor de Django v1.1.1 dev y Chrome 7.0.517.44.

La "solución" que he descubierto siempre está haciendo una actualización de disco (Shift espera 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 lo ignoran de caché para todos los recursos solicitados por el actualización.

Como tal, este me lleva a creer que es un problema con notoria tendencia de Chrome para caché todo lo que sea posible; aun cuando no debe. Mi conjetura es que Chrome está haciendo una petición de recursos y luego dejar caer inmediatamente la conexión de dicho recurso una vez que se da cuenta de que tiene el recurso almacenado en caché.

Esto casi sería una solución soportable, excepto alguna petición Ajax siguen causando problemas.

Esto puede ser debido a un error en la función de 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 evita que la acción predeterminada de enlace, se obtendrá una solicitud secundaria de inmediato y el navegador se cerrará la conexión anterior sin esperar a la respuesta a la meta. Yo tenía el mismo problema cuando se me olvidó añadir return false al controlador de eventos.

El mismo síntoma puede ocurrir si el controlador de eventos de disparo ajax lanza una excepción.

Depuración cuidadosamente la función que realiza la solicitud Ajax y el valor de retorno de la función.

Una tubería rota que sucede cuando el navegador se cierra la conexión con el servidor. Este problema sucedió conmigo antes de ajax solicitud posterior asociado con <a href="... porque se me olvidó añadir e.preventDefault() en la función de controlador click. Así que lo que sucedió es que el navegador envía la solicitud POST y cerrar la conexión y enviar una nueva solicitud GET. Por lo que verá como la solicitud de correos fue cancelada por el navegador.

He tenido un problema posiblemente relacionado.

Durante el uso de Safari y Chrome en Windows, en mi máquina local en mi Django de ejecución del servidor, algunos Las vistas eran al azar no devolver una respuesta a las peticiones POST ajax.

La solución fue la siguiente:

Los datos I que pasaba en a la vista a través de POST era sólo una clave / pair val: "action = Quitar". Ahora, yo no estaba realmente utilizando estos datos en mi opinión. Una vez que me asignaron los datos a una var en mi opinión, (es decir foo = request.POST [ 'action']), la vista sería devolver una respuesta a las peticiones ajax cada vez.

Por supuesto! Loca

En el caso de que esto ocurra con un cliente JavaScript, una solución podría ser el siguiente. Usted tiene que agregar 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
Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top