Мы используем AWS для размещения наших приложений. Вчера у нас возникла проблема, и мы случайно удалили «Пользовательские доменные имена» из шлюза API. Проблема была решена, и сервисы снова заработали.
Единственной проблемой, которую мы могли заметить, было удаление шлюза API. Но это вызвало странный побочный эффект. Мы запускаем тестовые пакеты для нашего продукта в AWS и тестируем все методы HTTP (некоторые из них возвращают 405 или 404). Теперь, после вчерашнего изменения, у нас возникла проблема, заключающаяся в том, что все методы, которые ранее возвращали 405, теперь возвращают 403 и тело html. Итак, методы, которые теперь возвращают 403, - это COPY, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND и VIEW.
Тело html выглядит так
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD>
<BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
This distribution is not configured to allow the HTTP request method that was used for this request. The
distribution supports only cachable requests.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: -uuNI4Ef393df_9X0h1oT0Elk5NztraTw-hLixxxxxxxxxxxxxxxxxxx
</PRE>
<ADDRESS>
</ADDRESS>
</BODY>
</HTML>
Я мог видеть, что в имени целевого домена упоминается экземпляр облачного интерфейса, но когда я его ищу, я не могу найти его в консоли aws. Поскольку я не вижу записи в списке, мы не можем попробовать упомянутое здесь исправление. (https://stackoverflow.com/questions/31253694/this-distribution-is-not-configured-to-allow-the-http-request)
Эта проблема очень странная, поскольку все работает, как и раньше, но теперь эти методы http ведут себя по-другому.
Любая помощь очень ценится.
Спасибо
Я считаю, что это указывает на то, что ваши пользовательские домены ранее были настроены как региональный API, но когда вы перенастроили пользовательские домены, вы настроили их как оптимизированный край.
CloudFront предоставляет функцию оптимизации границ от имени API Gateway бесплатно, а дистрибутив CloudFront, который автоматически подключается к конечной точке API Gateway, не виден вам в консоли. При региональном развертывании ответ, который вы видите, был бы невозможен, потому что он не связан с CloudFront.
Я предполагаю, что вам пришлось обновить DNS как часть решения предыдущей проблемы. Если у вас все еще есть записи о старых псевдонимах целей до изменения, это может дать некоторое подтверждение.
У регионального API есть целевое доменное имя, которое выглядит как d-example.execute-api.${region}.amazonaws.com в то время как API, оптимизированный для периферии, имеет целевое доменное имя с dexample.cloudfront.net. Это значения, которые вы бы настроили в DNS.
К счастью, у меня есть тестовый API, развернутый в двух разных пользовательских доменах, один региональный, а другой оптимизированный для периферии, и я могу подтвердить это объяснение следующим образом. Эти два примера предназначены для точно такой же API, тот же этап, все одинаково, за исключением того, что существует два разных пользовательских домена: один региональный, а другой оптимизированный для периферии.
$ curl -X PROPFIND -v https://regional.example.com
< HTTP/1.1 405 Method Not Allowed
< Date: Sat, 28 Sep 2019 00:05:11 GMT
< Content-Type: null
< Content-Length: 23
< Connection: keep-alive
< x-amzn-RequestId: c03bcb0f-0a79-488a-a658-0123456789ab
< x-amz-apigw-id: Base64Stuff=
Unsupported HTTP method
$ curl -X PROPFIND -v https://edge-optimized.example.com
< HTTP/1.1 403 Forbidden
< Server: CloudFront
< Date: Sat, 28 Sep 2019 00:05:19 GMT
< Content-Type: text/html
< Content-Length: 694
< Connection: keep-alive
< X-Cache: Error from cloudfront
< Via: 1.1 example.cloudfront.net (CloudFront)
< X-Amz-Cf-Pop: IAD79-C2
< X-Amz-Cf-Id: BlahBlahBase64==
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: BlahBlahBase64==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>
Первоначально я думал, что возможно (хотя и маловероятно), что API Gateway мог изменить способ развертывания этих скрытых дистрибутивов CloudFront для развертываний, оптимизированных для периферии, поэтому ваша новая установка могла быть такой же, как и старая, с вашей точки зрения, но с различное поведение внутри. Теперь я считаю, что это маловероятно, потому что эти тестовые API в последний раз были развернуты довольно давно.
Примечание: в целом я большой поклонник CloudFront, но такое поведение кажется неуместным, в корне неверным и, возможно, было бы даже справедливо сказать, что это досадно неуместно. С этим есть две проблемы.
Во-первых, это неточно.
Это распределение не настроено для разрешения метода HTTP-запроса, который использовался для этого запроса. Дистрибутив поддерживает только кешируемые запросы.
Первая часть достаточно близка, но это второе предложение - полная чушь и бесполезная.
Первая проблема заключается в том, что это сообщение об ошибке почти наверняка изначально было разработано для совершенно другой цели. CloudFront можно настроить так, чтобы разрешить методы запроса из одного из трех выбираемых наборов:
GET, HEADGET, HEAD, OPTIONSGET, HEAD, OPTIONS, PUT, POST, PATCH, DELETEЭта ошибка должна отображаться, если вы отправляете PUT, POST, PATCH, или DELETE к поведению кеша, настроенному для поддержки только GET, HEAD, и возможно OPTIONS -- другими словами, "только кешируемые запросы" - а здесь это не так.
Это сообщение используется ненадлежащим образом для ответа на методы, не входящие в этот набор, методы, которые нельзя использовать с API Gateway.
Вторая проблема в том, что это, конечно, должно быть 405 Method Not Allowed, и нет 403 Forbidden.