-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
APIGW: binary support for non-proxy integration #12215
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
2052964
to
768d6df
Compare
349b657
to
294e374
Compare
768d6df
to
4d05456
Compare
4d05456
to
3afb9e3
Compare
LocalStack Community integration with Pro 2 files 2 suites 29m 22s ⏱️ Results for commit 3afb9e3. |
Currently, only patch changes are allowed on master. Your PR labels (aws:apigateway, semver: minor) indicate that it cannot be merged into the master at this time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Awesome! 🚀 this adds great parity with aws!
The s3 tests just shows how far we have gone now! The logic of the convert_body
methods is super well covered in unit tests as well 🙏
if is_binary_request: | ||
if content_handling and content_handling == ContentHandlingStrategy.CONVERT_TO_TEXT: | ||
body = base64.b64encode(body) | ||
# if the content handling is not defined, or CONVERT_TO_BINARY, we do not touch the body and leave it as | ||
# proper binary | ||
else: | ||
if not content_handling or content_handling == ContentHandlingStrategy.CONVERT_TO_TEXT: | ||
body = body.decode(encoding="UTF-8", errors="replace") | ||
else: | ||
# it means we have CONVERT_TO_BINARY, so we need to try to decode the base64 string | ||
try: | ||
body = base64.b64decode(body) | ||
except ValueError: | ||
raise InternalServerError("Internal server error") | ||
|
||
return body |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice digging! There are a few hoops to jump through here as well 🚀
Motivation
Follow up from #12199, is reviewable
but will come out of draft once the base is merged to avoid the rebase review madness.This PR implements the full Binary media support for REST APIs. The AWS documentation will do a much better job explaining what this means exactly, but in big line, it allows you to define some behavior in how your payload in being pass through to your integration: it can be pass as is, converted to a safe UTF-8 string, or base64 decoded or encoded.
There are precise tables on the behavior, but I tend to not trust the documentation so much, so I took it upon myself to write AWS validated tests, which was to be honest, quite a pain again 😅
The behavior in itself is not too complicated, it is mapping some table to if conditions (which might be simplified, if you see it during the review, please say so, I didn't optimize the conditions).
Some changes in behavior is how the
responseTemplates
VTL rendering actually needs the value to be a string, and so if it comes out of the "converter", it needs to be of the right type. We might want to add better log statements to help the user understand why it would fail for them.I've also sneaked some
TODO
removal, and a small change inupdate_integration_response
, this API op really needs to be validated and fixed.Resources:
Changes
Content-Type
headersmodify the method(ported back to base PR) to check if a request if of "binary" type (AWS terms), meaning it matches thebinaryMediaTypes
UpdateIntegrationResponse
to support our test case