AWS API Gateway — тестирование работает, ошибки развернутого API. Почему?

#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. Это была именно та проблема, с которой мы столкнулись.