Websockets

Websockets は、101 のプロトコルスイッチング応答またはその他の応答を介して Websocket にアップグレードできる GET リクエストとして始まります。何をするか、またはどう応答するかを選択することは、他のフレームワークでは多くの場合不可能であり、Quart の動機となるものの 1 つです。さらに、Websocket はリクエストと非常によく似ているため、Quart は Websocket とリクエストの間に類似の機能を持たせることを目指しています。

リクエストの類似

Websockets は GET リクエストに非常によく似ており、単に Flask リクエスト API を拡張して Websocket 機能を含めるという誘惑がありました。これは、事実上の Flask 標準となっている Flask-Sockets や Flask-SocketIO のユーザーには驚きを与える可能性があります。したがって、既存のリクエスト機能と一緒に Websocket 機能を導入することにしました。

Websockets は GET リクエストと非常によく似ているため、リクエストに対して利用可能なすべての機能の類似物を生成することが理にかなっています。たとえば。before_request() と before_websocket() があり、リクエストコンテキストの横にWebsocket コンテキストがあります。

レスポンスまたはアップグレード

応答方法またはアップグレードするかを選択できることの有用性は、認証を検討するときに最もよく示されます。次の例では、一般的な login_required デコレータを使用して、Websocket の不正使用を防ぐことができます。

def login_required(func):
    @wraps(func)
    async def wrapper(*args, **kwargs):
        if websocket.authentication == (...):
            return await func(*args, **kwargs)
        else:
            abort(401)
    return wrapper

@app.websocket('/ws')
@login_required
async def ws():
    while True:
        await websocket.receive()
        ...

Quart は、フレームワークユーザーに完全な制御を与えるため、accept() を介して受け入れ応答 (101) を手動で送信することもできます。

メモ

この機能は、Websocket Denial Response 拡張を実装している ASGI サーバーでのみ使用できます。サーバーがこの拡張をサポートしていない場合、Quart はサーバーに応答せずに接続を閉じるよう指示します。推奨される ASGI サーバーである Hypercorn はこの拡張をサポートしています。