Шлюз API CORS HTTP 415

Хорошо, я облазил все эти сети в поисках понимания моей проблемы; Вероятно, я прошел через более 80 потоков переполнения стека RE API-шлюз и тому подобное, но ни один из них, похоже, не помогает и не говорит достаточно близко к моей проблеме.

Я новичок в API Gateway и cors, но давайте посмотрим, смогу ли я сформулировать проблему, которую вижу:

Настройка прокси-сервера шлюза API для Kinesis firehose, заполняющего базу данных красного смещения. Прокси-сервер, пожарный шланг и шлюз Redshift запущены и работают при изолированном вызове, но при вызове с одного из наших клиентских сайтов мы получаем следующее сообщение об ошибке:

XMLHttpRequest cannot load [api_call_here]. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 403.

Итак, это явно подразумевает, что CORS необходим, верно? в консоли на ресурсе включаем cors, деплоим, новая ошибка:

XMLHttpRequest cannot load [api_call_here]. Request header field $cookies is not allowed by Access-Control-Allow-Headers in preflight response.

Ооооооооо, из нового метода OPTIONS, добавленного функцией включения CORS, в ответе на интеграцию разрешены заголовки, в разрешенных заголовках управления доступом добавьте «$Cookies», разверните.

Теперь я получаю новую ошибку, очень похожую на первую ошибку:

XMLHttpRequest cannot load [api_call_here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 415.

Обратите внимание, что у первой ошибки был код состояния HTTP 403, а у третьей — код состояния 415. Вот здесь у меня возникают проблемы. Если я перейду к методу GET, действующему как прокси-метод, шаблоны сопоставления тела, у меня будет выбрано «Когда шаблоны не определены (рекомендуется)».

Теперь я прочитал, что когда шлюз API не может найти соответствующий шаблон, он отклоняется с ошибкой 415, поэтому я изменил вышеупомянутую опцию на «Когда ни один шаблон не соответствует заголовку Content-Type запроса». Это заставило ошибку исчезнуть, но данные по-прежнему не сохраняются в красном смещении при вызове из источника. Опять же, когда я вызываю API напрямую из почтальона, бессонницы или просто старой адресной строки, записи добавляются красиво.

Открыв хром и посмотрев на заголовок, я вижу, что файл cookie выглядит как текст/html.

Что касается сопоставления шаблонов, я определил карту только для application/json; это может быть частью проблемы?

Кроме того, заголовок ответа, если смотреть с консоли Chrome, выглядит следующим образом:

content-length:37
content-type:application/json
date:Wed, 19 Apr 2017 23:43:35 GMT
status:415
via:1.1 [blahblabbleblah].cloudfront.net (CloudFront)
x-amz-cf-id:[blahblabbleblah]
x-amzn-requestid:[blahblabbleblah]
x-cache:Error from cloudfront

Я относительно новичок в этом, поэтому я не понимаю, как облачный фронт вписывается в это, особенно учитывая, что он жалуется на тип носителя, в то время как консоль жалуется на отсутствие заголовка access-control-allow-origin.

В любом случае, любая помощь в устранении третьей ошибки будет оценена по достоинству.