Closed Caian closed 5 years ago
Some additional information:
local_apigw_service.py:146
);Maybe the data is not being decoded before asserting the content length?
EDIT: It appears that is_best_match_in_binary_types = False
in _should_base64_decode_body
even though is_base_64_encoded = True
so data never gets decoded.
In your SAM template, have you set BinaryMediaType
? And the media type specified in this setting must match the content-type in your response. This will set is_best_match_in_binary_types to True
and trigger a decode.
Hello,
No, I haven't set BinaryMediaType
, do you have any documentation for this option? In my case the content is plain text/html
that is automatically encoded as base64 by the Zappa framework. Should I set BinaryMediaType
to */*
? Is this related to #312?
Can you please elaborate on the logic behind this design? Because I am struggling to understand why does the list of binary media types have preference over the field in the response stating that the body is encoded as base64. Shouldn't be an OR operation instead?
Thank you.
@Caian The design is aimed to emulate the APIGateway Service. Have you run this on AWS? Can you provide a full example to make reproducing easier?
Closing due to no response.
Description:
I have a lambda code that returns a static base64-encoded HTML of around 21KB in size (AWS compliant JSON + encoded body), but when running with
sam local start-api
I only receive a string with the partial base64-encoded data as response and not the decoded HTML.There are no errors in the log, even with
--debug
.I think the entire response is being cut and the fields informing the base64 encoding are also being cut out because I have executed the lambda directly from docker using:
and the output appears correct.
Steps to reproduce the issue:
sam local start-api
;Observed result:
Expected result:
Additional environment details (Ex: Windows, Mac, Amazon Linux etc)
Linux Mint 18
Output of
sam --version
:SAM CLI, version 0.6.0
Optional Debug logs:
Thank you,
Caian