Opened 17 years ago

Closed 17 years ago

Last modified 17 years ago

#3089 closed defect (duplicate)

Intermittent connection resets with development server

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

Description

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):
    request.POST
    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 17 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 by dougvanhorn at the gmail dot com, 17 years ago

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)
    (self.environ['wsgi.input']).read(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 by dougvanhorn at the gmail dot com, 17 years ago

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 by Michael Radziej <mir@…>, 17 years ago

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

comment:4 by anonymous, 17 years ago

cggbmnghmfgmhfgmn

comment:5 by Michael Radziej <mir@…>, 17 years ago

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.

by anonymous, 17 years ago

Attachment: test added

comment:6 by Malcolm Tredinnick, 17 years ago

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