API Gateway - Post multipart\form-data

Question

I have an API within my API Gateway and am doing an HTTP proxy through to an endpoint that POST's multipart/form-data files.

If I call the http endpoint directly (not through the API gateway) - using postman, it works as expected, however, using the API gateway endpoint (through postman) fails.

I have compared both requests (through fiddler and CloudWatch logs) which seem to be identical:

Request for direct API call (working):

POST https://domainname/api/v1/documents HTTP/1.1

Host: api.service

Connection: keep-alive

Content-Length: 202

Authorization: AuthToken

Postman-Token: a75869d6-1d64-6b9f-513d-a80ac192c8e1

Cache-Control: no-cache

Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop

docMetaInfo: some extra data needed

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryB85rsPlMffA2fziS

Accept: */*

Accept-Encoding: gzip, deflate, br

Accept-Language: en-US,en;q=0.8

------WebKitFormBoundaryB85rsPlMffA2fziS

Content-Disposition: form-data; name=""; filename="Test.txt"

Content-Type: text/plain

This is a test Text File

------WebKitFormBoundaryB85rsPlMffA2fziS--

Request from the API Gateway (not working):

POST https://GATEWAY_domainname/api/v1/documents HTTP/1.1

Host: api-Gateway.service

Connection: keep-alive

Content-Length: 202

Authorization: AuthToken

Postman-Token: e25536fa-3dfa-ddcb-8ca6-3f3552d2bc40

Cache-Control: no-cache

Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop

docMetaInfo: some extra data needed

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarybX9MyWBsuLGm6QIC

x-api-key: *********************

Accept: */*

Accept-Encoding: gzip, deflate, br

Accept-Language: en-US,en;q=0.8

------WebKitFormBoundarybX9MyWBsuLGm6QIC

Content-Disposition: form-data; name=""; filename="Test.txt"

Content-Type: text/plain

This is a test Text File

------WebKitFormBoundarybX9MyWBsuLGm6QIC--

I have tried a few things from the gateway side, including changing the Integration Request to map a new body for the same content-type, no luck.

As far as I am aware, I should only need to passthrough this call, hence why it's becoming a little confusing - there should be no need for data manipulation/interception?

The error I get is 400 - bad request (complaining about the file not being found), but as you can see in the request, it's there.

Any ideas?

Logs from CloudWatch on the same APIGateway POST

Error is still 400 - no file found

Answer 1

AWS API Gateway now supports binary payloads. You can proxy the payload directly to the lambda function by using multipart/form-data as a binary media type for the API. For parsing multipart body, there will be a lot of libraries. This parse-multipart is for Node.js.