Gunicorn: 添加 ASGI 支持？

@arcivanov我将仔细研究这个协议，看看需要为它做些什么:)

将尽快更新此票证。

任何更新？

@benoitc @berkerpeksag和我通过电子邮件聊天。 我所知道的工作还没有开始。 我还没有时间阅读更多关于 ASGI 的内容，所以我无法估计实现它的复杂性。 如果有人想为此贡献工作，我会热情地帮助、讨论和审查。

我正在大修 ASGI 规范，以使其对服务器更有意义，因此在完成之前我会谨慎执行任何操作（新规范正在此处起草，但根本不是最终规范：http：/ /channels.readthedocs.io/en/2.0/asgi.html - 它基本上更像 WSGI）

@andrewgodwin很酷，迫不及待地想用 asgi 试试 gunicorn

@andrewgodwin ASGI 状态是什么？

我最近尝试测试一个 ASGI 应用程序，这是我得到的：

import json

def app(scope):
    async def channel(receive, send):
        message = await receive()

        if scope['method'] == 'POST':
            response = message
        else:
            response = scope

        await send({
            'type': 'http.response.start',
            'status': 200,
            'headers': [
                [b'Content-Type', b'application/json'],
            ],
        })
        await send({
            'type': 'http.response.body',
            'body': json.dumps(response, default=bytes.decode).encode(),
        })
        await send({
            'type': 'http.disconnect',
        })
    return channel

> daphne app:app
2018-03-31 22:28:10,823 INFO     Starting server at tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,824 INFO     HTTP/2 support enabled
2018-03-31 22:28:10,824 INFO     Configuring endpoint tcp:port=8000:interface=127.0.0.1
2018-03-31 22:28:10,825 INFO     Listening on TCP address 127.0.0.1:8000
127.0.0.1:43436 - - [31/Mar/2018:22:28:17] "GET /" 200 347
127.0.0.1:43440 - - [31/Mar/2018:22:28:22] "POST /" 200 43
127.0.0.1:43446 - - [31/Mar/2018:22:28:42] "POST /" 200 54

> http -b get :8000/
{
    "type": "http"
    "http_version": "1.1",
    "method": "GET",
    "path": "/",
    "query_string": "",
    "root_path": "",
    "scheme": "http",
    "headers": [
        ["host", "localhost:8000"],
        ["user-agent", "HTTPie/0.9.9"],
        ["accept-encoding", "gzip, deflate"],
        ["accept", "*/*"],
        ["connection", "keep-alive"]
    ],
    "client": ["127.0.0.1", 43360],
    "server": ["127.0.0.1", 8000],
}

> http -b -f post :8000/ foo=bar
{
    "body": "foo=bar",
    "type": "http.request"
}

> http -b -j post :8000/ foo=bar
{
    "body": "{\"foo\": \"bar\"}",
    "type": "http.request"
}

https://github.com/django/asgiref/blob/master/specs/www.rst

@sirex ASGI 现在很稳定。 我不确定您是说达芙妮是否符合规范？

django 上的链接是关于 ASGI“规范”的最后一个链接，还是还有更多描述流程的内容？

@andrewgodwin我试图证明，如果 Daphne 支持 ASGI，那么 ASGI 必须准备好供其他框架/服务器采用。

@benoitc有两个 ASGI 规范页面：

https://github.com/django/asgiref/blob/master/specs/asgi.rst - 一般的 ASGI 规范。

https://github.com/django/asgiref/blob/master/specs/www.rst - 描述 HTTP 和 WebSockets 协议以及与 WSGI 兼容性的规范。

@sirex谢谢。 尽管这些规范在实施时并不是很有帮助。

无论如何，我发现https://channels.readthedocs.io/en/latest/很好。 我想我更喜欢 pep，但是一旦我们取消了对 python 2 的支持，我们就可以提出支持 asgi 的建议。

顺便说一句，删除了最后一条评论，因为它与该讨论无关。

我还没有打算让 ASGI 成为 PEP，因为我想首先确保它有足够的普遍支持（这个过程需要大量的时间和精力），但这就是意图，它应该像一个人一样编写。

一旦我们取消了对 python 2 的支持，我们就可以提出支持 asgi 的建议。

如果您确实开始考虑实现，那么值得从uvicorn开始，

（如果没有 gunicorn 提供的进程监控等，那么 uvicorn 成为一个更小的选项可能会很好。）

ASGI 规范文档现在可以在这里找到： https :

好的，现在有这个。 （作为第三方工人阶级。）

Uvicorn 0.2 不再依赖于 gunicorn 直接运行它，而是包含两个用于运行 ASGI 应用程序的 gunicorn 工作类。

对于本地开发人员，或者您不太关心流程监督的情况，您可以直接运行 uvicorn。 对于生产，我们记录使用 gunicorn 类作为首选选项。

http://www.uvicorn.org/#running -with-gunicorn

从 gunicorn 运行 ASGI 应用程序，使用 uvloop 和 httptools：

gunicorn app:App -w 4 -k uvicorn.workers.UvicornWorker

从 gunicorn 运行 ASGI 应用程序，使用 asyncio 和 h11（为了与 pypy 兼容）：

gunicorn app:App -w 4 -k uvicorn.workers.UvicornH11Worker

如果有任何希望将任一协议实现带入核心 gunicorn 包，那么我非常愿意考虑这一点。

现在gunicorn不再支持python 2 ，技术上可以添加ASGI支持

@tomchristie我对那

我对那会是什么样子很感兴趣。 作为替代方案，也许将协议提取为一个或多个单独的包？

我猜要么是 gunicorn 中的一个工人类，它依赖于uvicorn的 h11 和/或 httptools 协议。 或者在这里复制实现。

复制实现的有限部分以提供具有h11依赖项的 Gunicorn 内置 ASGI HTTP 支持可能是一个很好的基线？

也许将协议提取为一个或多个单独的包？

没有什么可以从uvicorn提取的 - 如果我们删除click并只使用 argparse，并稍微调整我们的 setup.py 依赖项，那么它的硬依赖项将为零，并提供各种选项不同的 HTTP 实现、WS 实现、事件循环。

我想要一流的 ASGI 支持，这是否意味着在 Gunicorn 中添加额外的依赖项，一个告诉您要安装什么、文档或其他内容的存根工作程序。

是的，请。 即将从 gunicorn 切换到 daphne .. 如果 gunicorn 可以支持 asgi
那会节省我很多时间。

@japrogramer http://www.uvicorn.org/#running -with-gunicorn

Django 3.0（定于 2019 年 12 月发布）将具有开箱即用的 ASGI 支持，因此这将是gunicorn直接支持它的另一个重要原因。 发布后，我们可能会看到用户兴趣大增。

@johnthagen在管道上。 但是，我们需要在本月开始之前清理一些门票并发布。