Opened 5 years ago
Closed 5 years ago
#30619 closed Bug (fixed)
runserver fails to close connection if --nothreading specified.
Reported by: | Atsuo Ishimoto | Owned by: | nobody |
---|---|---|---|
Component: | HTTP handling | Version: | 2.2 |
Severity: | Normal | Keywords: | runserver |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | yes | Patch needs improvement: | yes |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Client: Chrome 75.0.3770.100/Firefox 67.0.4 on macOS 10.14.5.
Server: macOS 10.14.5., Python 3.7.3, Django 2.2.3
Running runserver with the --nothreading option may stop responding.
This is because Web browser uses multiple connection, and all of them has Connection: keep-alive header by default.
When the first request is finished, wsgi server continue to read the socket first request used because the connection is keep-alive.
So, the second connection is kept waiting without accepted by wsgi server, until the fist connection is closed. But the first connection will not be closed by browser for very long time.
Change History (6)
comment:1 by , 5 years ago
Has patch: | set |
---|
comment:2 by , 5 years ago
Component: | Core (Other) → HTTP handling |
---|---|
Description: | modified (diff) |
Keywords: | runserver added |
Needs tests: | set |
Patch needs improvement: | set |
Summary: | wsgi server doesn't respond if --nothreading specified → runserver fails to close connection if --nothreading specified. |
Triage Stage: | Unreviewed → Accepted |
comment:3 by , 5 years ago
Description: | modified (diff) |
---|
comment:4 by , 5 years ago
Description: | modified (diff) |
---|
comment:5 by , 5 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Yes, reproduces easily. Thank you for the report. I left a couple of comments on the PR, but it should be simple enough from here. 👍