1

In my django app I call location.reload(); in an Ajax routine in some rare circumstances. That works well with Chrome, but with Firefox4 I get an error: [Errno 32] Broken pipe twice on my development server (Django 1.2.5, Python 2.7), which takes about 10 sec.
And the error seems to eat the message I'm trying to display using the django messages framework.

No I replaced this line with

var uri = location.href;
location.href = uri;

Now the reload still takes some 10 sec, but Firefox displays the message.

So far, it works. But to me this looks like a dirty hack. So my questions are:

  1. Can anybody explain (or guess) what the error is in the first place?
  2. Do you see any problems where this 'solution' could bite me in the future?

(Note: I'm not the first to experience that problem).

Community
  • 1
  • 1
jammon
  • 3,404
  • 3
  • 20
  • 29
  • Are you using django-sentry? If so, what settings do you have in your local configuration? – Tom May 12 '11 at 16:07

2 Answers2

3

First of all, that's an issue with some specific browsers (and, probably, long processing on the server side) not a problem in django.

From the bug report on django:

This is common error which happens whenever your browser closes the connection while the dev server is still busy sending data. The best we could is to have a more explicit error message.

It actually can happen on other systems, eg from cherrypy

There is nothing to worry about as this just means that the client closed the connection before the server. After this traceback, your CherryPy server will still keep running normally.

So that's an introduction to your first question:

  1. Can anybody explain (or guess) what the error is in the first place?

Well, it's simply the browser closing the connection - kind of a client-side timeout. This Django + WebKit = Broken pipe answer does answer that question.

Why does it work by changing location.href and not using location.reload()? Well I would guess, but that's ONLY a guess, that Firefox behaves slightly differently and a reload will timeout differently.

I think the message is consumed because the request is already being sent when the browser pulls the trigger and shuts the connection.

The dev server is single threaded, and that might also be a factor in the issue.

I usually do my development on a real (local) server (nginx+apache+mod_wsgi, nothing fancy) - that avoid running into silly issues that would never happen on production.

  1. Do you see any problems where this 'solution' could bite me in the future?

Well, it might not work on a browser that would check if href has changed before reloading. Or it might hit the cache instead of doing a real request (you can force avoiding the cache with reload()). And behaviour might not be consistent on all browsers. But again, you are already hitting a browser quirk, so I wouldn't worry about it too much by itself.

By the way, you could simply do:

location.href = location.href

I would rather worry that the processing takes 10s! That really should not happen. edit So it looks like it's the browser itself provoking the long processing time AND the broken pipe error. sounds like (bad) parallel requests on the singlethreaded django server to me. endedit

Test on a real webserver, optimize your code; if that's not enough launch the long tasks on a background process with celery+rabbitmq; in any case don't lose time on an issue which is not really an issue!

You will probably be able to live with location.reload() and a little tweaking OR maybe just a real test environment!

Community
  • 1
  • 1
Stefano
  • 18,083
  • 13
  • 64
  • 79
  • Thank you for your detailed answer. You're right, I will install a 'real' local server and see if the problem persists. The long processing time is only when the error occurs, it is reasonably short in other browsers or situations. – jammon May 12 '11 at 17:00
  • hello jammon, sorry one week vacation. I am wondering if the issue might really just be bad pipelining of multiple connections on some specific browsers... I wish I had it happening on my local server so I could really dig it down. Don't hesitate come back should you have more details, hope you are running fine with a 'real' local server setup! – Stefano May 18 '11 at 16:38
0

The broken pipe error can also be down to lack of support for certain functionality in the Django debug server - one notable issue is Django's lack of support for Range HTTP requests (see here for details: Byte Ranges in Django) which are commonly used when delivering [streaming] media content.

It's probably worth investigating the actual HTTP interchange using a packet capture program such as Wireshark so you can see where and when the problem is occurring.

Community
  • 1
  • 1
Pierz
  • 7,064
  • 52
  • 59