#aws-api-gateway
#aws-api-gateway
Вопрос:
Я пытаюсь настроить AWS Api Gateway в качестве обратного прокси-сервера для моего фактического развернутого API. Я понимаю, что я делаю это, создавая ресурс «прокси», а затем указывая URL-адрес моей конечной точки http — как описано здесь , создайте и протестируйте API с интеграцией HTTP-прокси через прокси-ресурс
Это отлично работает, когда я пытаюсь использовать API через функцию «Test» в редакторе ресурсов. Я могу совершать вызовы любых открытых ресурсов, используя методы GET, и видеть успешные ответы.
Однако, когда я развертываю API API Gateway, я больше не могу получить доступ к чему-либо, используя «URL-адрес вызова», который он мне дает — я просто получаю:
{
"Message": "No HTTP resource was found that matches the request URI 'http://<myuniqueid>.execute-api.eu-west-1.amazonaws.com/api/Sector/100'.",
"MessageDetail": "No type was found that matches the controller named 'Sector'."
}
Если я уберу флажок «Использовать интеграцию HTTP-прокси» из «Запроса на интеграцию», я смогу заставить его работать, но почему он не работает как прокси?
Комментарии:
1. Не могли бы вы рассказать подробнее? (Как и необработанный запрос / ответ в обоих случаях) Похоже, проблема в том, что ваша конечная точка возвращает неверный ответ при использовании прокси-типа ресурса, поскольку сообщение об ошибке, которое вы предоставили, не принадлежит API gateway. Возможно, при использовании прокси-ресурса отправляются дополнительные заголовки.
Ответ №1:
Я подозреваю, что это вызвано известной проблемой с интеграцией HTTP-прокси. При использовании интеграции с HTTP-прокси API Gateway передает все заголовки в конечную точку интеграции, включая заголовок узла. Многие существующие конечные точки http требуют использования заголовка HOST, который соответствует их DNS-имени, и в таких случаях прохождение через заголовок HOST шлюза API может запутать конечную точку.
ОБНОВЛЕНИЕ: мы определили обходной путь для этой проблемы.
В вашем запросе на интеграцию явно добавьте заголовок с именем «Host» и присвоите ему значение DNS-имени конечной точки интеграции. Это заменит заголовок узла, пересылаемый из входящего запроса клиента, на указанный вами заголовок узла. Это должно позволить вашей серверной конечной точке функционировать правильно.
Комментарии:
1. Спасибо @MikeD. Это была именно та проблема, с которой мы столкнулись.