☰

不同的 http 错误代码和 html 主体

tag-icon • tag-icon amazon-web-services amazon-cloudfront amazon-api-gateway
不同的 http 错误代码和 html 主体

我们正在使用 AWS 来托管我们的应用程序。昨天我们遇到了一个问题，意外地从 API 网关中删除了“自定义域名”。问题已解决，服务重新开始运行。

删除 API 网关是我们注意到的唯一问题。但这导致了一个奇怪的副作用。我们正在 AWS 中针对我们的产品运行测试包并测试所有 HTTP 方法（其中一些返回 405 或 404）。现在，自从昨天的更改以来，我们遇到了一个问题，即所有以前返回 405 的方法现在都返回 403 和一个 html 主体。因此，现在返回 403 的方法是 COPY、LINK、UNLINK、PURGE、LOCK、UNLO​​CK、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>

我可以看到目标域名中提到了一个 cloudfront 实例，但当我寻找它时，我无法在 aws 控制台中找到它。由于我在列表中没有看到该条目，我们无法尝试此处提到的修复。（https://stackoverflow.com/questions/31253694/this-distribution-is-not-configured-to-allow-the-http-request）

这个问题非常奇怪，因为一切都像以前一样运行，但是这些 http 方法现在的行为不同了。

非常感谢所有的帮助。

谢谢

答案1

我认为这表明您的自定义域之前已配置为区域API，但当您重新配置自定义域时，您将其配置为边缘优化。

CloudFront 代表 API Gateway 免费提供边缘优化功能，并且自动附加到 API Gateway 端点的 CloudFront 分发在控制台中对您不可见。对于区域部署，您看到的响应甚至不可能实现，因为这些响应不涉及 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，HEAD
  • GET，，HEAD​OPTIONS
  • GET，，，，，，，HEAD​OPTIONS​PUT​POST​PATCH​DELETE

PUT如果您将、、或发送到配置为仅支持、和可能的缓存行为，POST则应该会显示此错误——换句话说，PATCHDELETEGETHEADOPTIONS“仅可缓存的请求”—— 但这里的情况并非如此。

此消息被不恰当地用于响应此集合之外的方法，这些方法无法通过 API 网关使用。

第二个问题是，这当然应该是405 Method Not Allowed，而不是403 Forbidden。

相关内容