I understand that by design, API Gateway maps 429 errors from Lambda to 500 responses.
Is there a way to map 429 to something else like 202?
I tried to create an integration response mapping from this regex: .*
which should map virtually everything to my defined status code, but i still receive 500 errors, from the API gateway.
Pasting my response from the AWS Forum post:
There is no way to map Lambda's 429 to any status code. It will always
be considered as 500. Curious to know, why do you want to map 429 to
202 (which means 'Accepted')?
Lambda 429 now maps to the INTEGRATION_FAILURE API Gateway response, so you can map it to any code you want, but keep in mind that will make any other integration error return that code as well. See https://forums.aws.amazon.com/thread.jspa?threadID=309901
Related
I am using KrakenD to make a call to a Salesforce endpoint
/services/data/v56/jobs/ingest/{{_jobId}}/batches
This backend endpoint doesn't return any data in the response body and as a result the call fails with a 500. From the logs -
[00] [KRAKEND] 2023/01/27 - 23:39:45.615 ▶ ERROR [ENDPOINT: /ingest/:jobId/batches] EOF
How do I solve this error? How can I tell KrakenD to expect the empty response body?
I am not using any custom plugins.
You should check the encoding defined at the backend section (by default, it's JSON) and select one that suits your backend responses. Here you'll find some recommendations: https://www.krakend.io/docs/backends/supported-encodings/#how-to-choose-the-backend-encoding
If you are expecting empty responses, you could use no-op (https://www.krakend.io/docs/endpoints/no-op/)
in recaptcha document, it says that if a site key exceeds 1000 QPS, then some requests may not be processed, I am wondering how I can identify this error if this happens? I assume a http code of 429 is thrown by google server?
The reCAPTCHA-specific quota page links to a more general Google API quota page that says
If you exceeded a quota with an HTTP/REST request, Google Cloud returns an HTTP 429 TOO MANY REQUESTS status code.
If you exceed a quota with an API request, Google Cloud returns an HTTP 413 REQUEST ENTITY TOO LARGE status code.
If you exceeded a quota using gRPC, Google Cloud returns a ResourceExhausted error. How this error appears to you depends on the service.
If you exceeded a quota using a Google Cloud CLI command, the gcloud CLI outputs a quota-exceeded error message and returns with the exit code 1.
Since you mention HTTP, I imagine you're in one of the first two categories. If you're going through their REST interface, you'll get 429. If you're going through the API, you'll get 413.
The 429 responses issued by API Gateway (when lowering the max concurrent requests and exceeding it) do not have the CORS headers, so the ajax request in the browser just throws error without any info that could selectively make it trigger a retry.
Any workaround but for retrying any error in the client app / i.e. any work around to have AWS include the CORS headers in the 429 response? CORS is enabled in API gateway, the OPTIONS method is there and responds the headers, and a lambda responds them itself (proxy integration) - all works well but for the 429.
I had a similar issue that was resolved by this answer. You need to create a custom response for 4** and 5** templates. You can do it manually in the AWS console, like so:
Remember to redeploy the API after changing this.
If API Gateway returns 429 you're probably hitting the limit for Lambda's lambda concurrency (or at least that was in my case). The CORS headers are not being sent to the client, since API Gateway blocks the request before hitting your Lambda.
I made python function using AWS lambda and connected lambda with API Gateway
After then, I tested API. It worked well.
Testing in API Gateway was Successful
Now I tried to using this API with AJAX.
Javascript AJAX Code was like this
How ever result was
"jquery-3.4.1.js:9837 GET https://9i1jhuewmj.execute-api.ap-northeast-2.amazonaws.com/test/transaction?jpgname=image.jpg net::ERR_FAILED"
How can i solve this problem??
Hope for your wisdom!
Thank you
I think there are a few things. The content-type header being returned is application/json but the response is not JSON.
But I think the main problem is that the HTTP status being returned is 301. This tells the browser that this resource has been moved and the browser typically expects the response to contain information on where things are moved to so it can redirect.
I suspect if you change your configuration so that a more normal response code (i.e. 200) is returned, this will work better.
I am currently trying to setup AWS Api Gateway, to proxy to another api, that has fully functional methods, response content, status codes etc. This is fairly simple to setup, but I have noticed that the Api Gateway always returns 200 OK no matter what the origin api responds with.
Fx. if there was a bad request (in the origin api) which results in a error message in JSON and a 400 Bad Request, the Api Gateway will respond with a the exact same error message, but a status code of 200 OK
If I remove all settings from the Message Response in the API Gateway web-interface, I get an internal error in the API Gateway. Can it be true that I have to map all the different status codes from the origin api manually in the Api Gateway?
I would prefer if it was possible to just let the status code (as well as the response, which currently works great) pass through, and not have the Api Gateway touch it in any way.
Proxy integration can be used to achieve this. In this case, it is HTTP Proxy. Lambda Proxy integration can also be used but will need some code logic in lambda. API GW will then return the result as-is.
You are correct that currently when using API Gateway you are required to map all response codes in your integration responses. We have heard this "pass through" request from other customers and we may consider including this in future updates to the service.