I've had a good day looking into this and can't work out what the f*ck is going on.

I've updated my django_src as of today, 31/05/07.

My sites are all running fine, but if I'm using Firefox 2.0.0.4 I'm getting the error below appear in my terminal. It doesn't happen with Safari, but it does screw AB up, only one request gets returned.

Change History (32)

What is the minimum that has to be done to cause the problem? What are you doing in Firefox to cause the error to occur? There is nothing repeatable in this bug report, so it's a bit hard to proceed further.

I confused myself yesterday by assuming that the development server runserver would behave in the same manner as lighttpd and fcgi when you throw AB at it, dumass as I am. Runserver can't handle AB tests, and if you think about it for one second you will realise this. I just assumed and then went to bad places from there.

I tracked ths issue down and it's nothing at all to do with Django

One of our designers had loaded webdesign into the tempalte that was being called in.

This webdesign randomises lorem ipsum output so that the desginers can imitate different types of text output, that was giving AB a real headache. Removed it and django runs like the wind again.

I sincerely apologise for posting this up here, it's the wrong place but I didn't know it at the time.

File "/usr/local/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 273, in run

self.finish_response()

File "/usr/local/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 312, in finish_response

self.write(data)

File "/usr/local/lib/python2.4/site-packages/django/core/servers/basehttp.py", line 396, in write

self._write(data)

File "/usr/local/lib/python2.4/socket.py", line 256, in write

self.flush()

File "/usr/local/lib/python2.4/socket.py", line 243, in flush

self._sock.sendall(buffer)

error: (32, 'Broken pipe')

It seems to work fine on my development box, but when I try to test django on a production server (using the servers IP instead of localhost - manage.py runserver 192.168.*.* 8000). I've also noticed that {{ request.user.first_name }} doesn't work in my templates when on the production server - but it does work on my dev box...

I can confirm this does not happen the first time a page is accessed using the development server (e.g. when you make a change to the code and the server reloads). The exception occurs the second and any subsequent page request.

Hi,
I was getting this error too (with Mozilla Firefox v2.0.0.5 and Mozilla Seamonkey v1.1.3 on Fedora7 served by Django v0.96, dev server), however what I found interesting was that I was able to replicate & eliminate (or decrease the frequency of the error, at least) in my app! I'll explain a little what I was up to.

I'm building a chat room app with Django and its AJAXed using YUI toolkit. Part of the app is a continuous loop, which polls the server for updates. This is simplifing things a bit, but the app has, lets say, a poll interval and a timeout period setting, so that if a request doesn't return from the server within the timeout period, the request is aborted.

What I found (and it kinda makes sense, with hindsight...) was that by making the timeout period much less than the poll interval, say half, the frequency of the error was much reduced. At the moment I'm not getting any errors. I think I may have been DoS-ing my own machine by sending too many requests, before the previous requests had completed!!

I don't know if this will help the ticket resolution, but the same error had me head scratching for a while.
Tom (Mayo, Ireland.)

I am getting exactly this same error. However, in my case the socket connection is coming from a JavaScript I'm running inside After Effects (the script is spawned by my Django app via AppleScript and After Effects defines a Socket object for its scripts). So, I don't think it's a browser issue. Same deal as above, the first time the view is called (in my case it's really just a function and not technically a "view" since it never sends an HttpResponse to the browser), the socket works perfectly; data is transmitted and received, and the sockets appear to be closed properly. The second time I hit this view, however, I get the same broken pipe error and trace in the Terminal as listed above and no socket is opened.

Since /favicon.ico is normally ignored by the logs messages it might make good sense to ignore the 'broken pipe' from this path too.
This is where the second patch comes in :) It's much cleaner as it uses the normal log_request routine. (and thus ignores the favicon path)

I am still having problems with this broken pipe issue.
And I am using the newest django distribution 0.96.2.
When I try to access my development server with ​http://192.168.0.3:8000/myurl/ I get the error displayed. And the patches didn't solve anything...

There is nothing to 'fix' here in your application, your just experiencing a browser issue/quirk.

This is exactly the reason i voted for changing these kinds of tracebacks to less scary looking errors and hiding the traceback behind --traceback. (this's what the switch it's for no ? :)

The reason for this patch is not to 'fix' the broken pipe issue. As it's not really an issue. But there seems to be a lack of clear consensus on how serious this is.

According to many sources the 'Broken Pipe' is a normal browser quirk. For example, the browser reads from the socket and then decides that the image it's been reading apparently didn't change. The browser now this (forcefully) closes the connection because it does not need more data. The other end of this socket (the python runserver) now raises a socket exception telling the program that the client 'Broke the socket pipe'.

If this is really only a non-issue, aka browsers do this often and it's not serious, then i suggested that we at least change this to a slightly less scary looking error. The idea here is to turn an exception (which is programming lingo) into an user error.

So here we are, 7 years later and this still happens. Google and StackOverflow point to this bug report but it seems a dead end now -- can someone point towards an active mailing list discussion or another, active ticket please?

I appreciate this is technically nobody's fault but Django happens to print the message so it gets the blame.

This is massively distracting during development when each time I reload a page I have to check whether it's Django printing its usual garbage or something *actually* exploded.

These strack traces all over the place are ugly and affect productivity so I hope it doesn't get swept under the rug.

I am not really happy with that patch which copies the simple_server.WSGIRequestHandler.handle() method from Python's version in order to override it. The copied version is not in sync with the latest Python and I'd prefer not to be in a position where we'd have to copy changes from there to Django.

One handler in WSGIServer, to catch the error when raised from
SocketServer.BaseServer's finish_request, and one in WSGIRequestHandler
(by creating a subclass of ServerHandler), to catch the error when
raised in wsgiref.handlers.BaseHandler's finish_response.