2

We are using AWS to host our applications. Yesterday we had an issue and were by accident deleted the "Custom domain names" from the API Gateway. The issue was resolved and the services started working again.

Deleting the API gateway was the only issue we could notice. But this caused a strange side effect. We are running test packs against our product in AWS and test all HTTP methods (some of them return 405 or 404). Now since the change yesterday we have an issue that all methods that previously returned 405 return now 403 and an html body. So the methods that return 403 now are COPY,LINK,UNLINK,PURGE,LOCK,UNLOCK,PROPFIND and VIEW.

The html body looks like this

<!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>

I could see in the target domain name there is a cloudfront instance mentioned but when I am looking for it I cannot find it in the aws console. As I do not see the entry in the list we cannot try out the fix mentioned here. (https://stackoverflow.com/questions/31253694/this-distribution-is-not-configured-to-allow-the-http-request)

This issue is very strange as everything is working as it was before but these http methods behave differently now.

All help is much appreciated.

Thanks

Oldfighter
  • 23
  • 3

1 Answers1

1

I believe this indicates that your custom domains were previously configured as regional APIs, but when you reconfigured the custom domains, you configured them as edge optimized.

CloudFront provides the edge-optimized feature on behalf of API Gateway, at no charge, and the CloudFront distribution that's automatically attached to an API Gateway endpoint isn't visible to you in the console. With a regional deployment, the response you're seeing wouldn't even be possible, because those don't involve CloudFront.

I assume you had to update DNS as part of the remedy to the previous issue. If you still have a record of the old alias targets from before the change, that might provide some confirmation.

An regional API has a target domain name that looks like d-example.execute-api.${region}.amazonaws.com while an edge optimized API has a target domain name with dexample.cloudfront.net. These are the values you would have configured in DNS.

As luck would have it, I have a test API that's deployed to two different custom domains, one regional and the other edge optimized, and I can confirm this explanation with the following. These two examples are for exactly the same API, same stage, same everything, except that there are two different custom domains, one is regional and the other is edge-optimized.

regional deployment

$ 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

edge optimized

$ 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>

I originally thought it might be possible (however unlikely) that API Gateway might have changed the way it deploys those hidden CloudFront distributions for edge-optimized deployments, so your new setup might have been the same as the old, from your perspective, but with different behavior internally. I now believe this to be unlikely, because these test APIs were last deployed quite some time back.

Side note: I'm a big fan of CloudFront, overall, but this behavior seems inappropriate, fundamentally incorrect, and perhaps it would even be fair to say embarrassingly inept. There are two problems with it.

First, it isn't accurate.

This distribution is not configured to allow the HTTP request method that was used for this request. The distribution supports only cachable requests.

The first part is close enough, but that second sentence is complete nonsense, and unhelpful.

The first problem is that this error message was almost certainly designed, originally, for an entirely different purpose. CloudFront can be configured to allow request methods from one of three selectable sets:

  • GET, HEAD
  • GET, HEAD, OPTIONS
  • GET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE

This error is supposed to be shown if you send PUT, POST, PATCH, or DELETE to a cache behavior configured to support only GET, HEAD, and possibly OPTIONS -- in other words, "only cachable requests" -- and that isn't the case, here.

This message is being used inappropriately to respond to methods outside this set, methods which aren't usable with API Gateway.

The second problem is that this, of course, should be 405 Method Not Allowed, and not 403 Forbidden.

Michael - sqlbot
  • 21,988
  • 1
  • 57
  • 81