0

Okay, I've been all over these interwebs looking for some insight to my issue; I've probably been through over 80 stack overflow threads RE api gateway and such, but none of them seem to help or speak close enough to my issue.

I'm new to API Gateway and cors, but lets see if i can articulate the issue that i am seeing:

Setting up a API gateway proxy to Kinesis firehose hydrating a redshift database. The proxy, firehose, and redshift gateway are up and working when called in isolation, but when called from one of our customer sites, we get an error as follows:

XMLHttpRequest cannot load [api_call_here]. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 403.

Okay, so that strongly implies that CORS is needed, right? in the console on the resource, enable cors, deploy, new error:

XMLHttpRequest cannot load [api_call_here]. Request header field $cookies is not allowed by Access-Control-Allow-Headers in preflight response.

Ooooooooookay, from the new OPTIONS method added by the enable CORS feature, in integration response, allowed headers, under access control allowed headers add '$Cookies', deploy.

Now i get a new error, very similar to the first error:

XMLHttpRequest cannot load [api_call_here]. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin [origin_website_here] is therefore not allowed access. The response had HTTP status code 415.

Notice the first error had HTTP status code 403, and this third one has status code 415. This is where I'm having issues. If I go into the GET method acting as the proxy method, body mapping templates, I have "When there are no templates defined (recommended)" selected.

Now, I read that when API gateway fails to find a matching template it rejects with a 415 error, so I changed aforementioned option to "When no template matches the request Content-Type header". That made the error disappear, but the data is still not being persisted to redshift when called from the origin. Again, when I call the api directly from postman, insomnia or just a plain old address bar, the records are added nicely.

Opening up chrome and looking at the header i see that the cookie is coming across as text/html.

Regarding the template mapping up there, i have only defined a map for application/json; could that be part of the problem?

Also, the response header as viewed from chrome's console is as follows:

content-length:37
content-type:application/json
date:Wed, 19 Apr 2017 23:43:35 GMT
status:415
via:1.1 [blahblabbleblah].cloudfront.net (CloudFront)
x-amz-cf-id:[blahblabbleblah]
x-amzn-requestid:[blahblabbleblah]
x-cache:Error from cloudfront

I'm relatively new to this so i dont see how cloudfront fits in with this, especially give that it is complaining about media type while the console is complaining about no access-control-allow-origin header.

At any rate, any help as to how to resolve the third error would be most appreciated.

sideshowbarker
  • 81,827
  • 26
  • 193
  • 197
zentechinc
  • 369
  • 1
  • 5
  • 15
  • 3
    Cloudfront handles some front-end logistics for API Gateway. API-GW creates and configures a hidden CloudFront distribution for each API you create, and requests pass through CloudFront to API-GW. In this case, `X-Cache: Error from cloudfront` means nothing more than the fact that CloudFront is returning a response with an HTTP status code >= 400. It's not an error "in" or "at" or "triggered by" or "generated by" CloudFront. The CloudFront aspect can be disregarded -- API-GW or the proxied service behind it is actually throwing the error because it doesn't like the `Content-Type`. – Michael - sqlbot Apr 20 '17 at 11:41

2 Answers2

0

What is the content-type in your requests from the browser? If content-type header isn't specified in the request, then API Gateway assumes "application/json" by default.

Opening up chrome and looking at the header i see that the cookie is coming across as text/html.

I am not sure if you meant that "Content-type" header's value in the request is set to "text/html". If yes, that's the problem. You will either need a matching template, or you will need to pass through by default by choosing "When no template matches the request Content-Type header".

Balaji
  • 1,028
  • 8
  • 12
0

I have some issue with AWS API GW with SQS integration. Problem was that incorrect content type in mapping template, I wrote application/json but correct is application/x-www-form-urlencoded

The request body will never be passed through to the integration. Requests with a Content-Type header that don't match any templates will be rejected with a HTTP 415 response.

1XTR
  • 11
  • 1
  • 1