Open symroe opened 9 months ago
FWIW, we have no problems with this using mangum. I suspect if you run an empty project you'll find asgi works as expected.
If you search the project, there's nothing that specifically changes the handling for multipart/form-data
. The word form
barely shows up. There is handling for base64 encoded so that might be worth looking at to see how you're passing the POST
itself.
This seems to be an issue with Mangum :)
Getting the following response for multipart/form-data
requests behind api-gateway on fastapi:
{
"detail": "There was an error parsing the body"
}
Upon some investigation, I see that the response returned from adapter.py#L83 for a form-data POST request foo=bar
is as follows:
{'status': 400, 'headers': [(b'content-length', b'48'), (b'content-type', b'application/json')], 'body': b'{"detail":"There was an error parsing the body"}'}
Any workaround would be appreciated.
Thanks for this library, I'm finding it really useful :)
However, I've found what I think is a bug when used on Lambda via API Gateway and submitting a form via POST as
Content-Type: multipart/form-data;
.First off, the rest of the app is working, and other forms that don't use
multipart/form-data
work properly.When submitting the multipart form, Mangum is passing Django the base64 encoded body, not the decoded body. This means that Django can't parse the form data as it expects to. I first saw this raised as a CSRF error, but that's simply because Django can't parse the request body and assumes the CSRF token is missing.
I'm not sure how to debug this, or how to write a test for it even, and I'm not 100% sure this is a bug with Mangum and not Django.
I thought I'd log it here, as swapping to a different WSGI adaptor (
aws-lambda-wsgi
) fixes the problem for me.