Django Broken pipe in Debug mode

DjangoBroken Pipe

Django Problem Overview


I have django 1.3 on the remote server behind Nginx.

If I run django with apache + mod_wsgi, I can watch errors in apache log files. It's ok but I'd like to have in console.

If I run django own development server, I get errors with stacktrace in console only when DEBUG = False. In DEBUG mode console outputs

Exception happened during processing of request from (..., ...)
Traceback (most recent call last):
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 284, in _handle_request_noblock
    self.process_request(request, client_address)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 310, in process_request
    self.finish_request(request, client_address)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 323, in finish_request
    self.RequestHandlerClass(request, client_address, self)
  File "/usr/local/python/lib/python2.7/site-packages/django/core/servers/basehttp.py", line 570, in __init__
    BaseHTTPRequestHandler.__init__(self, *args, **kwargs)
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 641, in __init__
    self.finish()
  File "/usr/local/python/lib/python2.7/SocketServer.py", line 694, in finish
    self.wfile.flush()
  File "/usr/local/python/lib/python2.7/socket.py", line 301, in flush
    self._sock.sendall(view[write_offset:write_offset+buffer_size])
error: [Errno 32] Broken pipe

I want to figure out why? Why does django just output unnamed Exception? Why does it depend on DEBUG variable.

This errors occurs mostly outside views when I have no access to request object. So I can't catch it in middleware or using logging handler.

UPDATE. I noticed if I request to django server directly I never get Broken pipe. So may the issue occur while Nginx proxy django?

Django Solutions


Solution 1 - Django

This isn't really an issue with your site, more with the Django devserver: see this Django ticket. To put it bluntly, just ignore it as it is a known error, and won't be fixed.

In that ticket's comments a quite clear explanation is given:

>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'.

Solution 2 - Django

Nginx directive proxy_intercept_errors off; (disabled by default) is what I needed

Solution 3 - Django

The nginx directive (checked answer) didn't work for me, but combining monkey patches from Igor Katson and Michael_Scharf did:

def patch_broken_pipe_error():
    """Monkey Patch BaseServer.handle_error to not write
    a stacktrace to stderr on broken pipe.
    http://stackoverflow.com/a/22618740/362702"""
    import sys
    from SocketServer import BaseServer
    from wsgiref import handlers

    handle_error = BaseServer.handle_error
    log_exception = handlers.BaseHandler.log_exception

    def is_broken_pipe_error():
        type, err, tb = sys.exc_info()
        return repr(err) == "error(32, 'Broken pipe')"

    def my_handle_error(self, request, client_address):
        if not is_broken_pipe_error():
            handle_error(self, request, client_address)

    def my_log_exception(self, exc_info):
        if not is_broken_pipe_error():
            log_exception(self, exc_info)

    BaseServer.handle_error = my_handle_error
    handlers.BaseHandler.log_exception = my_log_exception

patch_broken_pipe_error()

Solution 4 - Django

Here is a way to prevent the to print the message to stderr. Just monkey patch the BaseServer.handle_error function. This is how I do it:

def patch_broken_pipe_error():
    """Monkey Patch BaseServer.handle_error to not write
    a stacktrace to stderr on broken pipe.
    https://stackoverflow.com/a/7913160"""
    import sys
    from SocketServer import BaseServer

    handle_error = BaseServer.handle_error

    def my_handle_error(self, request, client_address):
        type, err, tb = sys.exc_info()
        # there might be better ways to detect the specific erro
        if repr(err) == "error(32, 'Broken pipe')":
            # you may ignore it...
            logging.getLogger('mylog').warn(err)
        else:
            handle_error(self, request, client_address)

    BaseServer.handle_error = my_handle_error


patch_broken_pipe_error()

Solution 5 - Django

I was able to get rid of this by > proxy_buffering off;

This stops response buffering of proxied server. This leads to other issues of the back-end application being locked for long if the client is on a extremely slow connection.

To make it conditional for particular requests, use X-Accel-Buffering=no in the response header.

Solution 6 - Django

I came up with a quick and dirty monkey patch (i don't know if it supresses any useful errors), that gets rid of this annoying error when using "./manage.py runserver" or running LiveServerTestCase tests.

Just insert it anywhere in your code, where you need that:

# Monkeypatch python not to print "Broken Pipe" errors to stdout.
import SocketServer
from wsgiref import handlers
SocketServer.BaseServer.handle_error = lambda *args, **kwargs: None
handlers.BaseHandler.log_exception = lambda *args, **kwargs: None

Solution 7 - Django

My BrokenPipe error disappears when I remove the "/" in the path in "urls.py"

urlpatterns = [
    path('', views.index)
]

Solution 8 - Django

I fixed it. If you use links i.e, anchor tag, inside the page, you have to face the "Borken Pipe" problem. Just use inside the link tag href='#'. Don't leave the href attribute blank. It will avoid that type of error.

Solution 9 - Django

In Django 3.2+ the "error" is an INFO reported by logging similar to:

INFO - Broken pipe from ('127.0.0.1', 59895)

@igor-katson has a good quick and dirty monkey patch. Updated for 3.2+ it can be:

# Suppress broken pipe errors
from django.core.servers.basehttp import WSGIServer
WSGIServer.handle_error = lambda *args, **kwargs: None

If you have a conditional check for being in development (runserver) mode in your settings.py, you could put this code there. It will squelch that annoying log entry.

Keep in mind, WSGIServer.handle_error also reports non-socket errors. If you had some other connectivity issue to debug this may get in the way.

Solution 10 - Django

Now currently it should be (in settings.py):

# Miscellaneous patch code

def patch_broken_pipe_error():
    """Monkey Patch BaseServer.handle_error to not write
    a stacktrace to stderr on broken pipe.
    http://stackoverflow.com/a/22618740/362702"""
    import sys
    from socketserver import BaseServer
    from wsgiref import handlers

    handle_error = BaseServer.handle_error
    log_exception = handlers.BaseHandler.log_exception

    def is_broken_pipe_error():
        type, err, tb = sys.exc_info()
        return repr(err) == "error(32, 'Broken pipe')"

    def my_handle_error(self, request, client_address):
        if not is_broken_pipe_error():
            handle_error(self, request, client_address)

    def my_log_exception(self, exc_info):
        if not is_broken_pipe_error():
            log_exception(self, exc_info)

    BaseServer = my_handle_error
    handlers.BaseHandler.log_exception = my_log_exception

patch_broken_pipe_error()

Note the lowercase socketserver import line.

Solution 11 - Django

I came across this issue as well while using tilelite. It's actually caused by a known, and now fixed, bug in python. You can resolve this issue by applying the following patch:

http://bugs.python.org/issue14574

Otherwise, you can download one of the more recent builds of python.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionSan4ezView Question on Stackoverflow
Solution 1 - DjangojroView Answer on Stackoverflow
Solution 2 - DjangoSan4ezView Answer on Stackoverflow
Solution 3 - DjangoRick MohrView Answer on Stackoverflow
Solution 4 - DjangoMichael_ScharfView Answer on Stackoverflow
Solution 5 - DjangoraneView Answer on Stackoverflow
Solution 6 - DjangoIgor KatsonView Answer on Stackoverflow
Solution 7 - DjangoThuta_YeAgView Answer on Stackoverflow
Solution 8 - DjangoGopi KirupanithiView Answer on Stackoverflow
Solution 9 - DjangoRobView Answer on Stackoverflow
Solution 10 - DjangoAbstract Space CrackView Answer on Stackoverflow
Solution 11 - DjangoJason HuntleyView Answer on Stackoverflow