Code

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#3089 closed defect (duplicate)

Intermittent connection resets with development server

Reported by: cephelo@… Owned by: adrian
Component: django-admin.py 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:

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 7 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 7 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)
    (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 Changed 7 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 7 years ago by Michael Radziej <mir@…>

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

comment:4 Changed 7 years ago by anonymous

cggbmnghmfgmhfgmn

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

  • Resolution set to duplicate
  • Status changed from new to closed

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 7 years ago by anonymous

comment:6 Changed 7 years ago by mtredinnick

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.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.