#amazon-web-services #aws-api-gateway
#amazon-web-services #aws-api-gateway
Вопрос:
В настоящее время я нахожусь в процессе перемещения веб-службы за AWS API gateway, и у меня возникли проблемы с загрузкой jpeg.
На данный момент шлюз является простым прокси-сервером. Есть ЛЮБОЙ ресурс, который просто передает все в службу по тому же пути (сейчас он в основном предназначен только для обеспечения поддержки https по старому URL, пока служба перемещает домены). Для обработки содержимого прокси-сервера установлено значение passhrough, поэтому он не должен ничего перекодировать.
Но когда я теперь загружаю jpg в запросе form-data, загруженные изображения есть, но их нельзя открыть. При попытке открыть их я получаю сообщение об ошибке: Not a JPEG file: starts with 0xef 0xbf
Теперь я понимаю, о чем вы думаете, вы хотите сказать мне, что мой jpg на самом деле является png. Поверьте мне, это не так. Конвейер, доставляющий эти изображения, работал надежно в течение многих лет, я могу открывать JPG-файлы перед их загрузкой, а также я не могу открыть файлы на сервере, если переименую их в .png. Каким-то образом API gateway, похоже, повреждает проходящие данные формы.
Итак, я выполнил некоторые операции с изображением до и после прохождения через шлюз. Содержимое идентично, за исключением первых байтов в файле. Перед тем, как изображение проходит через шлюз, начало файла выглядит следующим образом:
FF D8 FF E1 FF FE
После загрузки это заменяется на:
EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD EF BF BD
В противном случае файлы идентичны. Почему шлюз должен это делать и как мне это остановить? (согласно журналам шлюза, заголовок типа содержимого входящего запроса — image / jpeg, поэтому с этим тоже не должно быть проблем …)
Комментарии:
1. Возможно, они находятся в base64. Вы пробовали их декодировать?
2. Я добавил еще немного информации. Это определенно двоичный файл, но по какой-то причине заголовок файла, похоже, заменяется.
3. API gateway имеет настройку для двоичного содержимого . Вы настроили его для загрузки?
4. Хорошо, нет, вы имели в виду типы двоичных носителей в настройках API, о которых я не знал, пока не прочитал, что было написано в вашей ссылке. Как только я добавил image / jpeg и multipart / form-data в список, это сработало! Так что это чертовски много. Если вы хотите, вы можете сформулировать правильный ответ, иначе я сделаю это сам через некоторое время.
5. Спасибо. Рад, что это сработало. Я опубликую ответ:-)
Ответ №1:
На основе комментариев.
Проблема была вызвана тем, что не были настроены типы двоичных носителей в API gateway:
В API Gateway запрос и ответ API содержат текстовую или двоичную полезную нагрузку. Текстовая полезная нагрузка представляет собой строку JSON в кодировке UTF-8. Двоичная полезная нагрузка — это что угодно, кроме текстовой полезной нагрузки. Двоичной полезной нагрузкой может быть, например, файл JPEG, файл GZip или XML-файл.
Для интеграции прокси-серверов AWS Lambda:
вы должны base64-кодировать ответ вашей функции. Вы также должны настроить binaryMediaTypes для вашего API.