Unable to set "contentHandling"
I've found that setting the 'x-amazon-apigateway-binary-media-types' to */* causes 500 errors.
Using the API to set the content handling to "CONVERT_TO_TEXT" resolves the issue, but there doesn't seem to be a way to define that in the SAM CORS configuration, so the requests will always fail. (See below for error)
The error from API gateway is as follows:
14:52:31 Method request body before transformations: [Binary Data]
14:52:31 Execution failed due to configuration error: Unable to transform request
14:52:31 Gateway response type: API_CONFIGURATION_ERROR with status code: 500
14:52:31 Gateway response body:
{
"detail": "Internal server error",
"title": "API_CONFIGURATION_ERROR",
"status": 500
}
This is the output of the API integration in a working case:
{
"integrationResponses": {
"200": {
"responseTemplates": {
"application/json": null
},
"selectionPattern": "",
"statusCode": "200"
}
},
"contentHandling": "CONVERT_TO_TEXT",
"timeoutInMillis": 29000,
"passthroughBehavior": "NEVER",
"requestTemplates": {
"application/json": "{\"statusCode\": 200}"
},
"cacheNamespace": "******",
"type": "MOCK",
"cacheKeyParameters": []
}
Hi @tayler-kemsley! Thank you for bringing this up. If I understand this right, it looks like we would need to surface another CORS field, contentHandling, that would be added to the x-amazon-apigateway-integration resource in the output CloudFormation. Would SAM need to make any other template changes to match the working case that you posted?
I read up a little on resource conversions in apigw, but I'm still not very familiar with them.
Hi @keetonian, yes I believe thats correct. Interestingly, I couldn't even find a way to set contentHandling in the web console so it seems to be a fairly forgotten about parameter! As far as I can see, this is the only template change that would be required.
To be completely honest, I'm not that familiar with them either. The working examples above were the result of a lot of trial and error.
Also note I made a small amendment to my original comment, markdown was trying to use the * in */*!
If I understand this right, it looks like we would need to surface another CORS field, contentHandling, that would be added to the x-amazon-apigateway-integration resource in the output CloudFormation.
Just wanted to clarify that this isn't a CORS field so much as an API Gateway configuration setting.
@tayler-kemsley Figured out a workaround that you may be able to use, see https://github.com/awslabs/serverless-application-model/issues/566#issuecomment-419311289
@0xdevalias Thanks, yeah I ended up with a very similar approach to you.
PR for fixing BinaryMediaTypes is in update #954
Removed "waiting-for-release" label as this issue is not solved by the referenced PR.
By default in lambda proxy integrations, ContentHandling is set to CONVERT_TO_TEXT. For Binary types, we need to be able to set it to CONVERT_TO_BINARY.
Sample event structure:
Events:
Image:
Type: Api
Properties:
Method: get
Path: /
ContentHandling: CONVERT_TO_BINARY
This will, if the BinaryMediaTypes property is set on the API, allow the api in this method to return binary content, such as images.
The change needed to support content handling is pretty minor if someone would like to have a go at it.
hey all. any update on this issue? don't #1001 and #1098 resolve what's remaining from this?
I'm having the same issue. I 'm returning and image from lambda but it is not always converting.
If I use < img src= "url_image"> -> it works. Setting binary-media type to image/*
If I try to access url_image from a browser it doesn't works unless setting binary-media type to / o text/html
Hi AWS Team,
Have you planned to add ContentHandling: CONVERT_TO_BINARY to API Event? is it something you consider to do? in any case can you provide a workaround for that?
Thanks
Hi, any update on this?
It's really unfortunate seeing all this activity from 2019 and the PRs ended up getting closed and not merged. I don't agree with the conclusion reached, this table response format https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings-workflow.html defines the behavior of API GW under different scenarios and it's not equivalent to isBase64Encoded: true (referenced here: https://github.com/aws/serverless-application-model/pull/1098#issuecomment-525131945)
This take https://github.com/aws/serverless-application-model/pull/1001#pullrequestreview-265560370 is still true today.