Function drop_connection

src/github_api_tester.py:45–77

Drop the (HTTP/1.1) connection belonging to the current Quart request.

()

async def drop_connection():
    """Drop the (HTTP/1.1) connection belonging to the current Quart request."""
    # We need to do two things:
    # - Convince hypercorn (specifically, around HTTPStream.app_send())
    #   that it doesn't need to send a 500 and can just close the socket.
    # - Convince h11's state machine that it's okay to close the socket
    #   without sending a response.
    # We can't do this at the ASGI layer: hypercorn will insert the 500
    # for protocol compliance if the ASGI app doesn't provide a
    # response. We need to modify the actual HTTP server, either with a
    # pull request or by digging into its internals as follows:
    # - Grab the HTTPStream whose bound method app_send was passed into
    #   the Quart request
    # - Grab the H11Protocol whose bound method stream_send was passed
    #   into the HTTPStream's constructor
    # - Tell the H11Protocol's underlying h11 state machine to act as if
    #   the remote side errored, so it thinks dropping the connection is
    #   the appropriate next step and not misbehavior on our end
    # - Tell the HTTPStream to move the state machine forward with no
    #   further send on our side, which will drop the connection (and
    #   not consider it for keepalive)
    import hypercorn.protocol as hp

    http_stream: hp.http_stream.HTTPStream = request._send_push_promise.args[0].__self__
    protocol: hp.h11.H11Protocol = http_stream.send.__self__
    protocol.connection._process_error(protocol.connection.their_role)
    await http_stream.send(hp.events.EndBody(stream_id=http_stream.stream_id))
    await http_stream.app_send(None)

    # Some other things I tried, kept for reference:
    # http_stream.state = hypercorn.protocol.http_stream.ASGIHTTPState.RESPONSE
    # await http_stream._send_closed()
    # http_stream.state = hypercorn.protocol.http_stream.ASGIHTTPState.CLOSED


# The following GitHub API datatypes are complete enough to satisfy