Шлюз AWS API base64Decode создает искаженный двоичный файл?

Я пытаюсь вернуть 1px gif из метода AWS API Gateway.

Поскольку двоичные данные теперь поддерживаются, я возвращаю изображение / gif, используя следующее отображение «Ответ интеграции»:

$util.base64Decode("R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7")

Однако, когда я смотрю на это в Chrome, я вижу, что возвращается следующий двоичный файл:

Вместо:

Может ли кто-нибудь помочь мне понять, почему это искажено и неправильной длины? Или что я мог сделать, чтобы вернуть правильный двоичный файл? Есть ли что-то еще, что я всегда мог вернуть этот 1px GIF без использования функции base64Decode?

Большое спасибо заранее, это причиняет мне много боли!

РЕДАКТИРОВАТЬ

Этот становится незнакомцем. Похоже, проблема не в base64Decode, а в общей обработке двоичного кода. Я добавил лямбда-бэкэнд (ранее я использовал Firehose) послеэтот блог и этоВопрос переполнения стека, Я устанавливаю изображения как двоичныйMediaType в соответствии с этимстраница документации.

Это позволило мне передать следующий пиксель изображения / bmp из Lambda через API шлюза, и он работает правильно:

exports.handler = function(event, context) {

  var imageHex = "\x42\x4d\x3c\x00\x00\x00\x00\x00\x00\x00\x36\x00\x00\x00\x28\x00\x00\x00\x01\x00\x00\x00\x01\x00\x00\x00\x01\x00\x18\x00\x00\x00\x00\x00\x06\x00\x00\x00\x27\x00\x00\x00\x27\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\xff\xff\xff\xff\x00\x00";
  context.done(null, { "body":imageHex });

};

Однако следующие изображения, представляющие изображение / png или изображение / gif, искажаются при прохождении:

exports.handler = function(event, context) {

//var imageHex = "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00\x00\xff\xff\xff\x21\xf9\x04\x01\x00\x00\x00\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x01\x44\x00\x3b";
//var imageHex = "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\xff\xff\xff\x00\x00\x00\x21\xf9\x04\x01\x00\x00\x00\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02\x44\x01\x00\x3b";
  var imageHex = "\x47\x49\x46\x38\x39\x61\x01\x00\x01\x00\x80\x00\x00\x00\x00\x00\x00\x00\x00\x21\xf9\x04\x01\x00\x00\x00\x00\x2c\x00\x00\x00\x00\x01\x00\x01\x00\x00\x02\x02\x44\x01\x00\x3b\x0a"
  context.done(null, { "body":imageHex });

};

Кажется, это та же проблема, что идругой вопрос переполнения стека, но я надеялся, что это будет исправлено с помощью бинарной поддержки API шлюза. К сожалению, image / bmp не работает для моего варианта использования, так как он не может быть прозрачным ...

Если это кому-нибудь поможет,это был хороший инструмент для преобразования между base64 и hex.

 Dave Maple02 янв. 2017 г., 21:39
Как выглядят заголовки ответа в Chrome?
 Dave Maple03 янв. 2017 г., 00:16
Какой бэкэнд для вашего шлюза API? Это лямбда?
 rjmurt02 янв. 2017 г., 23:09
Спасибо, заголовки ответа:HTTP/1.1 200 OK Content-Type: image/gif Content-Length: 52 Connection: keep-alive Date: Mon, 02 Jan 2017 22:08:55 GMT x-amzn-RequestId: 0d3f620c-d138-11e6-941a-0f16afc9bdc4 X-Amzn-Trace-Id: Root=1-586acf77-93ce6c87faa62ee76758abf5 X-Cache: Miss from cloudfront Via: 1.1 227087338674ca3d3d23a79539f2998b.cloudfront.net (CloudFront) X-Amz-Cf-Id: 9V1XUr1cPqjm7Bj2HOFfakLlFM5MWo_Ucuv9cdk35xsBz_xhcPvixQ==  И ответ возвращается как:data:image/gif;base64,R0lGODlhAQABAO+/vQAAAAAA77+977+977+9Ie+/vQQBAAAAACwAAAAAAQABAAACAUQAOw==

Ответы на вопрос(2)

Решение Вопроса

Похоже, что это была известная проблема ранее:https://forums.aws.amazon.com/thread.jspa?messageID=668306򣊒

Но это должно быть возможно теперь, когда они добавили поддержку двоичных данных:http://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-payload-encodings.html

Похоже, это то, что нам нужно: «Установите для свойства contentHandling ресурса IntegrationResponse значениеCONVERT_TO_BINARY чтобы преобразовать полезную нагрузку ответа из строки в кодировке Base64 в ее двоичный двоичный объект ". Тогда нам не нужноbase64Decode() функция.

Сейчас работаем над тестом, чтобы увидеть, работает ли это.

РЕДАКТИРОВАТЬЯ наконец смог заставить это работать. Вы можете увидеть двоичное изображение здесь:https://chtskiuz10.execute-api.us-east-1.amazonaws.com/prod/rest/image

Вот моя лямбда-функция, которая возвращает кодированный в Base64 PNG в виде строки:https://gist.github.com/davemaple/73ce3c2c69d5310331395a0210069263

Я обновил ответ метода следующим образом:

Я обновил ответ интеграции, чтобы включить жестко закодированный заголовок изображения / png:

Последний шаг был хитрым: настройкаcontentHandling свойство "CONVERT_TO_BINARY". Я не мог понять, как это сделать в консоли AWS. Мне пришлось использовать CLI API для достижения этой цели:

aws apigateway update-integration-response \
    --profile davemaple \
    --rest-api-id chtskiuzxx \
    --resource-id ki1lxx \
    --http-method GET \
    --status-code 200 \
    --patch-operations '[{"op" : "replace", "path" : "/contentHandling", "value" : "CONVERT_TO_BINARY"}]'

Надеюсь, это поможет.

 Dave Maple02 мая 2017 г., 15:13
@Sabreena - попробуйте эти шаги:docs.aws.amazon.com/cli/latest/userguide/installing.html
 Sabreena03 мая 2017 г., 08:29
@Dave Maple - Могу ли я отправить аудиофайл в виде multipart / form-data через шлюз API на s3? пожалуйста, проверьтеstackoverflow.com/questions/43733254/...
 tkiethanom17 янв. 2017 г., 19:26
@DaveMaple Вам повезло, что вы задали динамический тип контента? Когда ответ возвращается в двоичном виде, шлюз API испытывает проблемы с извлечением моего интеграционного файла. По очевидным причинам.
 Dave Maple03 янв. 2017 г., 15:07
дайте мне знать, если у вас все получится, как только у вас будет возможность просмотреть.
 Dave Maple18 янв. 2017 г., 00:23
Хорошо, извините @tkiethanom: я могу установить тип контента вimage/png используя лямбда-прокси, смотрите суть здесь:gist.github.com/davemaple/47cf6e4dc8b1e23c3562c41a900a69f0, Я просто не могу получить ответ, преобразованный в двоичный файл.
 Dave Maple17 янв. 2017 г., 23:47
я много чего пробовал @tkiethanom :: пока сол. без интеграционного ответа я не нашел пути.
 Dave Maple07 янв. 2017 г., 00:52
@tkiethanom: на этих выходных постараюсь настроить тест, чтобы увидеть, что отличается в интеграции прокси.
 rjmurt03 янв. 2017 г., 09:48
Спасибо за вашу помощь, Дэйв, я добавил подробности моего расследования выше. Было бы очень интересно услышать, как вы поживаете!
 Dave Maple03 янв. 2017 г., 20:48
серьезно - документы могут использовать небольшое обновление в этой области (это довольно новая функциональность в их защите).
 Dave Maple06 янв. 2017 г., 03:01
@tkiethanom: он работает, если тело ответа является допустимым закодированным в base64 изображением, заголовки ответа метода установлены, тип контента установлен в соответствии с типом изображения, и вы выполнили операцию исправления, чтобы установить для contentHandling значение CONVERT_TO_BINARY. Я однажды получил эту ошибку, но думаю, что она исправлена ​​после обновления патча.
 Dave Maple23 янв. 2017 г., 16:20
Вы можете сделать это с помощью AWS skd или cli @HassanSiddique, но не через веб-интерфейс. У принятого ответа есть n пример, использующий cli.
 tkiethanom18 янв. 2017 г., 01:23
@DaveMaple Я нахожусь в подобной ситуации, когда я использую Lambda Proxy для установки Content-Type, настройка CONVERT_TO_BINARY больше не работает. Поэтому я пытаюсь найти способ экспортировать динамический Content-Type в двоичном виде.
 Sabreena02 мая 2017 г., 12:57
Не могли бы вы объяснить последний шаг? Я не знал, как найти aws cli и как добавить свойство contentHandling в CONVERT_TO_BINARY.
 tkiethanom06 янв. 2017 г., 03:03
На самом деле это сработало для меня. Таким образом, команда CLI в основном позволяет обойти тот факт, что при выборе лямбда-функции на экране «Создать метод» вы не можете установить раскрывающийся список «Обработка содержимого». Раскрывающийся список появляется только при выборе службы AWS.
 rjmurt03 янв. 2017 г., 20:46
Вау, это сработало! Я не могу отблагодарить тебя достаточно. Я бы этого не заметил!
 Hassan Siddique23 янв. 2017 г., 16:00
Я хочу добавить свойство contentHandling к "CONVERT_TO_BINARY" в ответе на интеграцию, но не смог найти какой-либо путь в веб-консоли aws. Кто-нибудь сделал это или любой другой обходной путь, пожалуйста, сообщите.
 Dave Maple06 янв. 2017 г., 03:06
@tkiethanom :: это именно так. Он доступен в интеграции службы AWS, но не отображается в качестве опции в консоли при лямбда-интеграции.
 tkiethanom07 янв. 2017 г., 00:49
После дальнейшего изучения я не смог заставить это работать при установке флажка Lambda Proxy Integration. К счастью, я могу использовать свою лямбду без интеграции прокси, но я хотел указать на это, если кто-то еще столкнется с этой проблемой.

Для тех, у кого есть проблемы с этим: я также бился головой о стену, пытаясь получить двоичное изображение через API-шлюзинтеграция с прокси отлямбда, но потом я заметил, что там прямо в разделе «Двоичная поддержка» Lambda Console написано:

API-шлюз будет смотреть наТип содержимого а такжепринимать Заголовки HTTP, чтобы решить, как обращаться с телом.

И я добавилAccept: image/png к заголовкам запроса и все заработало. О радость и радость! Нет необходимости вручную изменять обработку контента на CONVERT_TO_BINARY или копаться в кли. Конечно, это исключает использование, например,<img src= напрямую (не могу установить заголовки).

Итак, чтобы получить двоичный файл через API-шлюз от лямбды с интеграцией прокси:

Перечислите все поддерживаемые двоичные типы контента в лямбда-консоли (и разверните)Заголовок Accept запроса должен включать заголовок Content-Type, возвращаемый из лямбда-выраженияВозвращенное тело должно быть в кодировке base64Объект результата также должен иметьisBase64Encoded свойство установлено вtrue

Код:

callback(null, {
    statusCode: 200,
    headers: { 'Content-Type': 'image/png' },
    body: buffer.toString('base64'),
    isBase64Encoded: true
}
 istvanp13 апр. 2018 г., 06:04
Это сработало для меня. Кроме того, вы можете установить Binary Media Types (в настройках API) на*/* и тогда вам не нужно будет устанавливать заголовок Accept. Однако предостережение заключается в том, что это не позволяет вам использовать вывод текста.

Ваш ответ на вопрос