Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#3089 closed defect (duplicate)

Intermittent connection resets with development server

Reported by: cephelo@… Owned by: Adrian Holovaty
Component: runserver Version: master
Severity: normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


With the latest SVN version I am still getting frequent connection resets using Firefox 2.0 when using the development server on Windows XP (SP2).

I seem to have it tracked down to a very odd behavior. Given the following view:

def test(request):
    return render_to_response("test.html")

When posting to this method, Firefox often gives me "The connection was reset The connection to the server was reset while the page was loading."

However, if I change the code to:

def test(request):
    return render_to_response("test.html")

the problem goes away.

This happens on both of my Windows XP machines.

Attachments (1)

test (5 bytes) - added by anonymous 11 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 11 years ago by dougvanhorn at the gmail dot com

I did a little more research around why request.POST fixes this problem with Firefox.

I whittled the code down to the 'safe_copyfileobj' call in the '_get_raw_post_data' method on the django.core.handlers.wsgi.WSGIRequest object (~ line 169).

Specifically, the problem goes away when the read method on the object found in self.environwsgi.input? is called.

    #safe_copyfileobj(self.environ['wsgi.input'], buf, size=content_length)

Now I have to find out what the 'environ' property is and where it comes from and why not reading breaks firefox...

I'll keep plugging away, but I thought this might help...

comment:2 Changed 11 years ago by dougvanhorn at the gmail dot com

One last update.

self.environwsgi.input? looks like it is the standard input socket being read from the client (which is Firefox 2.0). By the time it's used by the _get_post method on the WSGIRequest, I believe it's queued up to the Message Body of the POST. If one or more bytes is read, Firefox is happy. If no bytes are read, Firefox is unhappy.

IE 6.0 handles the situation without issue. I haven't tested other browsers as those are the two browsers I have on my machine (Windows XP).

After a brief search of the HTTP spec, I found Section 8.2.4, which talks about client behavior if the server prematurely closes a connection, but I don't think it's relevant in this situation.

So, to summarize, if the Message Body is not read at all on a POST from a Firefox client, the client will choke. My guess is that it's a problem with Firefox, and it'll go away on it's own.

Hope this helps.

comment:3 Changed 11 years ago by Michael Radziej <mir@…>

cephelo pointed out that #3496 looks similar, can you try the patch provided there?

comment:4 Changed 11 years ago by anonymous


comment:5 Changed 11 years ago by Michael Radziej <mir@…>

Resolution: duplicate
Status: newclosed

No feedback? Then I assume it's a duplicate of #3496. If you find that the patch does not solve the problem, please reopen the ticket.

Changed 11 years ago by anonymous

Attachment: test added

comment:6 Changed 11 years ago by Malcolm Tredinnick

In case anybody reads this in the future, it isn't a dupe of #3496, but it isn't a Django bug, either. This problem is if the browser sends content and the server side doesn't read it. If you are expecting data in your view, you should read it (failure to do so is a programmer error and we can't guard against that). If you aren't, then having the browser throw an error when content is sent at the wrong moment is as good an error as any.

Note: See TracTickets for help on using tickets.
Back to Top