Gunicorn: ASGIサポートを追加しますか？

@arcivanovこのプロトコルを詳しく見て、何をする必要があるかを確認します:)

このチケットはできるだけ早く更新されます。

更新はありますか？

@ benoitc @ berkerpeksagと私はそれについて電子メールでおしゃべりしました。 私が知っている作業はまだ始まっていません。 ASGIについて詳しく読む時間がまだないので、これを実装することの複雑さを見積もることはできません。 誰かがこれに向けて仕事に貢献したいのであれば、私は熱心に助け、議論し、レビューしたいと思います。

とにかくサーバーにとってより意味のあるものにするためにASGI仕様をオーバーホールしている最中なので、それが完了するまで何もしないように注意します（新しい仕様はここでドラフトされていますが、最終的なものではありません：http：/ /channels.readthedocs.io/en/2.0/asgi.html-基本的にはWSGIに非常に似ています）

@andrewgodwin coolは、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

@sirexASGIは現在安定しています。 ダフネが仕様に準拠しているのか、準拠していないのかわかりませんか？

djangoのリンクはASGIの「仕様」に関する最後のものですか、それともフローを説明するものは他にありますか？

@andrewgodwin私は、DaphneがASGIをサポートしている場合、ASGIは他のフレームワーク/サーバーが採用する準備ができている必要があることを非難しようとしていました。

@ benoitc2つのASGI仕様ページがあります。

https://github.com/django/asgiref/blob/master/specs/asgi.rst-一般的なASGI仕様。

https://github.com/django/asgiref/blob/master/specs/www.rst-HTTPおよびWebSocketプロトコルとWSGIとの互換性を説明する仕様。

@sirexありがとう。 これらの仕様は、実装に関してはあまり役に立ちませんが。

とにかく私は大丈夫であるhttps://channels.readthedocs.io/en/latest/を見つけました。 私はpepを好むと思いますが、python 2のサポートを削除するとすぐに、asgiをサポートするものを提案できます。

ところで、最後のコメントはその議論とは関係がないので削除しました。

ASGIを最初に十分な一般的なサポートがあることを確認したいので（そしてそのプロセスには多くの時間と労力がかかります）、ASGIをPEPにするために移動しませんでしたが、それは意図であり、そのように書く必要があります。

Python 2のサポートを削除するとすぐに、asgiをサポートするものを提案できます。

あなたが実装について考え始める行う場合、それは価値が始まるだろうuvicorn接着剤が一緒にgunicorn、uvloop、およびhttptools。 その作業が、ある時点でサポートされているワーカークラスとしてgunicornにロールバックされることは理にかなっているかもしれません。

（uvicornが、gunicornが提供するプロセス監視などを行わずに、より最小限のオプションになるのは良いことかもしれません。）

ASGI仕様のドキュメントは、 https ：//asgi.readthedocs.io/en/latest/から入手でき

さて、これを今カバーしてください。 （サードパーティのワーカークラスとして。）

Uvicorn 0.2は、直接実行するためにgunicornに依存しなくなりましたが、ASGIアプリを実行するための2つのgunicornワーカークラスが含まれています。

ローカル開発者の場合、またはプロセスの監視について十分に気にしない場合は、uvicornを直接実行できます。 本番環境では、推奨オプションとしてgunicornクラスを使用してドキュメントを作成します。

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

uvloopとhttptoolsを使用して、gunicornからASGIアプリを実行します。

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

asyncioとh11（pypyの互換性のため）を使用して、gunicornからASGIアプリを実行します。

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

いずれかのプロトコル実装をコアgunicornパッケージに組み込むことを希望する場合は、それを検討することを非常に受け入れます。

gunicornはpython 2サポートしなくなったため、技術的にはASGIサポートを追加できます。

@tomchristie私はそれがどのように見えるかに興味があります。 別の方法として、プロトコルを個別のパッケージとして抽出することもできますか？

私はそれがどのように見えるかに興味があります。 別の方法として、プロトコルを個別のパッケージとして抽出することもできますか？

h11および/またはhttptoolsプロトコルをuvicornに依存していたgunicornのワーカークラスのどちらかだと思います。 または、ここで実装を複製します。

実装の限られた部分を複製して、 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月にリリース予定）では、 gunicornが直接サポートするもう1つの大きな理由になります。 それがリリースされた後、おそらくユーザーの関心が大幅に高まるでしょう。

パイプにある