[Django] #30619: wsgi server doesn't respond if --nothreading specified
Django
-----------------------------------------+------------------------
Reporter: atsuoishimoto | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
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 web application with single-threaded wsgi server 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30619>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: new
Component: Core (Other) | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Atsuo Ishimoto):
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:1>
Django
--------------------------------+------------------------------------
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
Changes (by Carlton Gibson):
* needs_better_patch: 0 => 1
* component: Core (Other) => HTTP handling
* needs_tests: 0 => 1
* keywords: => runserver
* stage: Unreviewed => Accepted
Old description:
> 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 web application with single-threaded wsgi server 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.
New description:
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.
--
Comment:
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. 👍
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:2>
Django
Reporter: Atsuo Ishimoto | Owner: nobody
Component: contrib.humanize | Version:
Severity: Normal | Resolution: worksforme
Keywords: ruby-on-rails | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by LemonAndroid):
* status: new => closed
* needs_better_patch: 1 => 0
* component: HTTP handling => contrib.humanize
* needs_tests: 1 => 0
* version: 2.2 =>
* type: Bug => Uncategorized
* keywords: runserver => ruby-on-rails
* has_patch: 1 => 0
* resolution: => worksforme
Old description:
> 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.
New description:
--
Comment:
ROR
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:3>
Django
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by LemonAndroid:
Old description:
> 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.
New description:
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:3>
Django
--------------------------------+------------------------------------
Type: Bug | Status: closed
Component: HTTP handling | Version: 2.2
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Changes (by LemonAndroid):
* status: new => closed
* resolution: => wontfix
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:4>
Django
--------------------------------+------------------------------------
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution: wontfix
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by Carlton Gibson:
Old description:
New description:
Client: Chrome 75.0.3770.100/Firefox 67.0.4 on macOS 10.14.5.
2 Server: macOS 10.14.5., Python 3.7.3, Django 2.2.3
3
4 Running runserver with the `--nothreading` option may stop
responding.
5
6
7 This is because Web browser uses multiple connection, and
all of them has Connection: keep-alive header by default.
8
9 When the first request is finished, wsgi server continue
to read the socket first request used because the connection is `keep-
alive`.
10
11 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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:5>
Django
--------------------------------+------------------------------------
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: closed
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution: wontfix
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by Carlton Gibson:
Old description:
> Client: Chrome 75.0.3770.100/Firefox 67.0.4 on macOS 10.14.5.
> 2 Server: macOS 10.14.5., Python 3.7.3, Django 2.2.3
> 3
> 4 Running runserver with the `--nothreading` option may
> stop responding.
> 5
> 6
> 7 This is because Web browser uses multiple connection, and
> all of them has Connection: keep-alive header by default.
> 8
> 9 When the first request is finished, wsgi server continue
> to read the socket first request used because the connection is `keep-
> alive`.
> 10
> 11 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.
New description:
Client: Chrome 75.0.3770.100/Firefox 67.0.4 on macOS 10.14.
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:6>
Django
--------------------------------+------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by Carlton Gibson:
Old description:
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:3>
Django
Reporter: Atsuo Ishimoto | Owner: dhh
Type: | Status: assigned
Cleanup/optimization |
Component: CSRF | Version: 2.2
Severity: Release blocker | Resolution:
Keywords: ruby-on-rails | Triage Stage:
| Someday/Maybe
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Changes (by LemonAndroid):
* status: new => assigned
* cc: LemonAndroid (added)
* component: HTTP handling => CSRF
* keywords: runserver => ruby-on-rails
* owner: nobody => dhh
* stage: Accepted => Someday/Maybe
* type: Bug => Cleanup/optimization
* severity: Normal => Release blocker
Old description:
> 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.
New description:
ip block?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:4>
Django
-------------------------------------+-------------------------------------
Reporter: Atsuo Ishimoto | Owner: dhh
Type: | Status: assigned
Cleanup/optimization |
Component: CSRF | Version: 2.2
Severity: Release blocker | Resolution:
Keywords: ruby-on-rails | Triage Stage:
| Someday/Maybe
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by LemonAndroid:
Old description:
> ip block?
>
> [rubyonrails.org]
New description:
ip block?
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:5>
Django
Reporter: Atsuo Ishimoto | Owner: nobody
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Keywords: runserver | Triage Stage: Accepted
Needs tests: 1 | Patch needs improvement: 1
Changes (by LemonAndroid):
* type: Bug => Uncategorized
Old description:
> 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.
New description:
haha
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:4>
Django
--------------------------------+------------------------------------
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by LemonAndroid:
Old description:
> 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.
New description:
x
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:4>
Django
--------------------------------+------------------------------------
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
Keywords: runserver | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Description changed by Carlton Gibson:
Old description:
> 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.
New description:
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.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:4>
Django
Reporter: Atsuo Ishimoto | Owner: nobody
Type: Bug | Status: new
Component: HTTP handling | Version: 2.2
Severity: Normal | Resolution:
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Changes (by Carlton Gibson):
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:5>
Django
-------------------------------------+-------------------------------------
Type: Bug | Status: closed
Component: HTTP handling | Version: 2.2
Keywords: runserver | Triage Stage: Ready for
| checkin
Has patch: 1 | Needs documentation: 0
Needs tests: 1 | Patch needs improvement: 1
Changes (by Mariusz Felisiak <felisiak.mariusz@…>):
* status: new => closed
* resolution: => fixed
Comment:
In [changeset:"a9c6ab03560424ed7dff24849c8ddaa3e1eae62e" a9c6ab03]:
{{{
#!CommitTicketReference repository=""
revision="a9c6ab03560424ed7dff24849c8ddaa3e1eae62e"
Fixed #30619 -- Made runserver --nothreading use single threaded
WSGIServer.
Browsers often use multiple connections with Connection: keep-alive.
If --nothreading is specified, the WSGI server cannot accept new
connections until the old connection is closed, causing hangs.
Force Connection: close when --nothreading option is used.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/30619#comment:6>