Почему API-шлюз портит мой двоичный файл? - PullRequest
0 голосов
/ 27 августа 2018

У меня есть AWS API Gateway, выступающий в качестве прокси для бэкэнд-сервиса:

{
  "apiKeySource": "HEADER", 
  "name": "-", 
  "createdDate": 1513820260, 
  "binaryMediaTypes": [
      "application/zip", 
      "application/octet-stream"
  ], 
  "endpointConfiguration": {
      "types": [
          "EDGE"
      ]
  }, 
  "id": "-"

}

Определение интеграции здесь:

{
  "integrationResponses": {
      "200": {
          "responseTemplates": {
              "application/json": null
          }, 
          "statusCode": "200"
      }
  }, 
  "passthroughBehavior": "WHEN_NO_MATCH", 
  "timeoutInMillis": 29000, 
  "uri": "http://${stageVariables.backend}:7000/{proxy}", 
  "connectionType": "INTERNET", 
  "httpMethod": "ANY", 
  "cacheNamespace": "iv06s3", 
  "type": "HTTP_PROXY", 
  "requestParameters": {
      "integration.request.path.proxy": "method.request.path.proxy", 
      "integration.request.header.X-Source-IP": "context.identity.sourceIp"
  }, 
  "cacheKeyParameters": [
      "method.request.path.proxy"
  ]
 }

У меня есть конечная точка, которая генерирует Zip-файл на лету и возвращает его запрашивающей стороне.

Когда я получаю доступ к конечной точке напрямую, файл в порядке. Когда я получаю к нему доступ через API-шлюз, он поврежден.

Повреждение принимает форму байтов в исходном файле, конвертируемом в 0xEFBFBD. Это UTF-8 'символ замены' .

В моем запросе Accept установлено значение application/zip, а в ответе Content-Type: application/zip.

Я ожидаю, что API-шлюз должен распознать это как двоичный тип носителя и оставить файл в покое, но кажется довольно ясным, что он обрабатывает его как текстовое содержимое.

Что я делаю не так?

1 Ответ

0 голосов
/ 29 октября 2018

Установка «Binary Media Type» на «multipart / form-data» решила аналогичную проблему для меня. См. Здесь: AWS Api Gateway, поскольку HTTP-прокси ограничивает двоичные загруженные файлы изображений

...