#3089 closed defect (duplicate)
Intermittent connection resets with development server
Reported by: | 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)
Change History (7)
comment:1 by , 18 years ago
comment:2 by , 18 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 , 18 years ago
cephelo pointed out that #3496 looks similar, can you try the patch provided there?
comment:5 by , 18 years ago
Resolution: | → duplicate |
---|---|
Status: | new → 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.
by , 18 years ago
comment:6 by , 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.
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.
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...