Okay here is a BIG one. This refactors out all of the logic for each event source into their own classes. This helps encapsulate all the messy logic for each event source into one place. It also makes it easier to add new event sources as we choose. I namespaced the handlers with "AWS" with thoughts that this could actually apply to other serverless implementations over on Azure, GCP, etc. if needed.

I wanted to get this in front of you sooner rather than later so you could take a look. It needs a couple more lines of coverage and I'm going to go back and look through some of the issues to make sure I have them covered in tests and they're still working (regression is no good)

It might be easier to look at the repo at my commit, not just the changes.

Let me know what you think, big changes like this are scary but it feels a lot cleaner.

I've removed the existing WebSocket support as part of https://github.com/jordaneremieff/mangum/issues/127 with the intention of developing it outside of this package, then later migrating it back in (if it makes sense to do so). My main concern is that I want to avoid impacting the stability of the HTTP implementation which is the primary use-case, and the maintenance burden was too much for the amount of capacity I have to spare currently. I also want to re-design it with broadcast support as an initial requirement rather than a feature added on later.

I think a new project might use Mangum as a dependency, or could end up looking something like this:

from mangum import Mangum
from mangum_ws import MangumWebSocket

def handler(event, context):
    if 'eventType' in event['requestContext']:
        asgi_handler = MangumWebSocket(app)
    else:
        asgi_handler = Mangum(app)

    return asgi_handler(event, context)

Not really sure. I haven't been motivated to take this up for awhile, but if anyone wants to give it a shot I can help where possible.

from fastapi import FastAPI
from mangum import Mangum

app = FastAPI()

@app.get("/")
def hello_world():
    return {"hello": "world"}

handler = Mangum(app)

ERROR:

[ERROR] TypeError: __call__() takes 2 positional arguments but 4 were given
Traceback (most recent call last):
  File "/var/task/mangum/__init__.py", line 123, in __call__
    raise exc
  File "/var/task/mangum/__init__.py", line 118, in __call__
    response = self.asgi(*args, **kwargs)
  File "/var/task/mangum/__init__.py", line 178, in asgi
    response = asgi_cycle(self.app, body=body)
  File "/var/task/mangum/__init__.py", line 38, in __call__
    asgi_instance = app(self.scope, self.receive, self.send)

I tried this, but could not import AWSLambdaAdapter

from mangum.platforms.aws.adapter import AWSLambdaAdapter

Can you please provide a working example of this?

(First off, awesome package. Being able to use an actual framework on Lambda without writing any 'transformation' code myself has been incredible.)

I'm attempting to use Starlette's GZipMiddleware with FastAPI right now, and our front-end is sending a accept-encoding: gzip, deflate, br header.

When I configure the middleware like so...

APP = FastAPI()
# ... other middleware
APP.add_middleware(
    GZipMiddleware,
    minimum_size=512,
)
HANDLER = Mangum(APP, enable_lifespan=False)

... I receive the following error.

Exception in ASGI application

Traceback (most recent call last):
  File "/var/task/mangum/protocols/http.py", line 39, in run
    await app(self.scope, self.receive, self.send)
  File "/var/task/fastapi/applications.py", line 142, in __call__
    await super().__call__(scope, receive, send)  # pragma: no cover
  File "/var/task/starlette/applications.py", line 134, in __call__
    await self.error_middleware(scope, receive, send)
  File "/var/task/starlette/middleware/errors.py", line 178, in __call__
    raise exc from None
  File "/var/task/starlette/middleware/errors.py", line 156, in __call__
    await self.app(scope, receive, _send)
  File "/var/task/starlette/middleware/base.py", line 26, in __call__
    await response(scope, receive, send)
  File "/var/task/starlette/responses.py", line 200, in __call__
    await send({"type": "http.response.body", "body": b"", "more_body": False})
  File "/var/task/starlette/middleware/errors.py", line 153, in _send
    await send(message)
  File "/var/task/mangum/protocols/http.py", line 97, in send
    self.response["body"] = body.decode()
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8b in position 1: invalid start byte

I had initially thought it might be due to the minimum_size parameter but removing that did not work. If I removed the middleware completely then my Lambda works perfectly fine.

I'm a little confused by the "body": b"" part, since this Lambda is returning data, and when I test locally running the same APP with uvicorn I have no issues - body is compressed and status code is 200.

Is there something I need to do to configure Mangum for compression? Am I reading the stack trace wrong?

** FastAPI 0.48.0 Mangum 0.7.0 Python 3.6.8

With the current implementation, any exception in the ASGI app will make mangum return a response with 500, even though the application may have already correctly generated a valid response. In those cases we want to return the valid response and log the error, rather than fail.

One example where this would manifest: failures in BackgroundTasks in FastAPI.

This makes it inline with running FastAPI (and other ASGI) applications standalone where failures in the background tasks will return not make the whole request fail.

Hi. There is an issue in reading font files from the AWS API gateway proxied to AWS Lambda. It is reading it as a text file.

in protocols/http.py body is not encoded in base64 body = base64.b64encode(body) and giving error in self.response["body"] = body.decode()

It should return header with content-type as font/*

• add event source types
• add event source detection
• use event source type in scope creation

This PR is a one-step closet to support different event sources.

Also, we should construct responses according to the request type, that work is out of the PR scope though.

I've found that if I send a get request to FastAPI like GET eg.com/something?name=John+Smith then the database query generated uses literally John+Smith. Same situation using %20.

It seems that Mangum is doing a second round of url-encoding on the query strings, so when FastAPI (or whatever might sit in the middle) decodes the query string it gets the once-encoded version back.

I'm working with an Application Load Balancer.

I'm not 100% sure what the correct behaviour should be, or whether the URL encoding behaviour should be different between API gateway and ALB.

I'll create a pull request with a failing test for this in a moment.

Some references:

https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html "If the query parameters are URL-encoded, the load balancer does not decode them. You must decode them in your Lambda function."

with ALB source, serverless-wsgi decodes and then encodes the query strings before passing off to WSGI: https://github.com/logandk/serverless-wsgi/blob/f8d5a92f63901ed25d1a09ae19fcaa791e22436f/serverless_wsgi.py#L82-L93

Related issues from serverless-express https://github.com/vendia/serverless-express/issues/241 https://github.com/vendia/serverless-express/issues/219

We are using the logger from aws-lambda-powertools-python. It's a logging tool from AWS, that can be quite helpful when it comes to debugging, especially when using CloudWatch Log Insights.

I would like to use this logger with Mangum as well.

I was thinking the constructor could accept a logger_class parameter, which when set is used instead of logging.getLogger. Alternatively, following logging.setLoggerClass, a function that can set which logger is used in adapter.get_logger.

I tried using logging.setLoggerClass directly, but that results in a RecursionError; the AWS logger doesn't inherit logging.Logger properly, but instead instantiates an internal logger from logging.getLogger. If you think I should report the recursion error on the AWS repo instead, please let me know. I am quite new to Python, and don't know whether this behavior acceptable.

Issue #132

This is an attempt to re-introduce WebSockets support in the project. It's still just a draft, but I wanted to put something together as soon as possible to discuss and shape the solution. The implementation is basically the same as the one present in this branch. The PR was getting way too big, and I decided to drop the support to broadcast for now. Maybe we can handle this in another PR/issue.

I've left a few TODO comments in the code on points where we should keep an eye, but overall my main questions would be these:

• What's the best approach to instantiate the WebSocketCycle? Right now, I'm picking the protocol based on the lambda event. I think it's the best solution from the user standpoint, as the configuration stays the same as it already is, and we can support both HTTP and WebSocket connections in the same ASGI app. But it's possible to use a separate adaptor class as well.
• The Scope format is slightly different for the WebSocket connection, but I kept using the same as HTTP.
• Binary payloads seem to be unsupported by API GW. They suggest a workaround, though. Not sure if we should try to support this.
• Subprotocols won't be supported, as the application is only called on the MESSAGE event (but the HTTP headers are exchanged on CONNECT).

This comment [1] explains how to use Mangum with the serverless framework. Since serverless supports multiple providers (e.g., Azure), would it be possible that Mangum enables ASGI support for other providers too?

[1] https://dev.to/anilgrexit/comment/gkfo

One API endpoint I have receives a base64-encoded PNG. Can I return the data via mangum with content-type image/png without having to first base64-decode it?

Hooking up a Mangum lambda to CloudFront as EventType: origin-request returns a 502 response: "The Lambda function result failed validation: The function tried to add, delete, or change a read-only header."

According to the documentation, the Content-Length Header is one of the read-only headers for origin-request events. Not quite sure why. But it's certainly one of the headers returned when calling the lambda. I use the lambda to handle API requests, so it needs IncludeBody, which is only available with origin-request.

I was able to get around this by hijacking the response:

def handler(event, context):
    response = Mangum(app, lifespan="off")(event, context)
    if 'headers' in response:
        response['headers'].pop('content-length')
    return response

Discussed in https://github.com/jordaneremieff/mangum/discussions/256

def handler(event, context):
    if event.get("some-key"):
        # Do something or return, etc.
        return

    asgi_handler = Mangum(app)
    response = asgi_handler(event, context) # Call the instance with the event arguments

    return response

def handler(event: LambdaEvent, context: LambdaContext) -> dict:
    if "requestContext" in event:
        logger.debug("HTTP API")
        response = fastapi_handler(event, context)
    else:
        logger.debug("Not HTTP API")
        loop = asyncio.get_event_loop()
        response = loop.run_until_complete(app_logic())
    return response

Summary

• Mangum supports events from AWS API Gateway and AWS ALB.
• Mangum has a api_gateway_base_path argument to strip the prefix of the http path before passing to the underlying app
• api_gateway_base_path works as expected for API Gateway events
• As far as I can tell, api_gateway_base_path does not work for ALB events.

I looked at https://mangum.io/http/ and the GitHub issues and couldn't find this mentioned anywhere.

My Setup

• Python 3.9
• mangum 0.12.4
• starlette 0.17.1

Simplified version of my lambda handler:

def public_foo_function:
    print("Public foo function")

def private_bar_function:
    print("Private bar function")

app = Starlette(
    routes=[
        Route(
            path="/public/foo",
            endpoint=public_foo_function,
        ),
        Route(
            path="/private/bar",
            endpoint=private_bar_function,
        ),
    ]
)

mangum = Mangum(
    app,
    api_gateway_base_path="/prefix",
)

def main(event, context):
    return mangum(event, context)

An external API Gateway v2 HTTP has a route /prefix/public/{proxy+} integrated with the lambda. An internal ALB has a listener rule /prefix/private/* integrated with the lambda.

Requests to <api gateway url>/prefix/public/foo arrive in the lambda and public_foo_function is called, as expected.

From within my VPC, internal requests to <alb url>/prefix/private/bar arrive in the lambda and Starlette returns Not Found 404. This is unexpected.

As a workaround, if I change the private route in Starlette app from /private/bar to /prefix/private/bar, private_bar_function is called.

Considerations

api_gateway_base_path does have 'api gateway' in the name, and ALB is not an API Gateway. So there's an argument it could be intentional?

But, I expected mangum to behave consistently for all of its supported input events.

I was trying to use ASGI in aliyun fc, a serverless service that is similar to aws lambda, and found this library.

it seems that Mangum only supports aws for now. Will this project accept PR for supporting another vendor apart from AWS?

Hi! Thank you for creating this framework. I'm currently using ariadne to manage a graphql lambda.

For every execution I get a stack trace:

ERROR:mangum.lifespan:Exception in 'lifespan' protocol.
Traceback (most recent call last):
  File "/Users/lilja/Library/Caches/pypoetry/virtualenvs/backend-dmp__8h8-py3.8/lib/python3.8/site-packages/mangum/protocols/lifespan.py", line 93, in run
    await self.app({"type": "lifespan"}, self.receive, self.send)
  File "/Users/lilja/Library/Caches/pypoetry/virtualenvs/backend-dmp__8h8-py3.8/lib/python3.8/site-packages/ariadne/asgi.py", line 94, in __call__
    raise ValueError("Unknown scope type: %r" % (scope["type"],))
ValueError: Unknown scope type: 'lifespan'

However, the lambda/mangum executes as the rest of the code as usual and I have correct graphql output.

I'm not up-to-speed with asgi stuff and don't really know what this means, is there a way to silence this error? Should I create a github issue with the other framework in question?

raised error in question: https://github.com/mirumee/ariadne/blob/master/ariadne/asgi.py#L113

How I use mangum

async def setup() -> GraphQL:
    session = ClientSession()
    schema_file = os.environ.get("SCHEMA_FILE", "../schema.graphql")

    async with session:
        engine = await setup_graphql(session, schema_file)
        return GraphQL(engine, debug=production)


def lambda_handler(event: Dict[str, Any], context: Any):
    graphql_app = asyncio.get_event_loop().run_until_complete(setup())
    handler_fn = Mangum(graphql_app)
    return add_cors_headers(handler_fn(event, context))


def add_cors_headers(ret_value: Dict[str, Dict]) -> Dict[str, Dict]:
    ret_value["headers"]["Access-Control-Allow-Origin"] = "*"

    return ret_value