Is there a way to configure rate limit rule on a specific API action on Azure API management. The desired solution is to return HTTP 429 (too many request) if the end user receives a certain response from the backend, after X attempts.
See increment-condition on rate-limit-by-key policy: https://learn.microsoft.com/en-us/azure/api-management/api-management-access-restriction-policies#LimitCallRateByKey
In Azure APIM, rate limiting can be done based on a key or subscription. So rate limit based on the back end response over a number of times is not possible.
It is also not a good practice to keep track of response status between the calls.
You can possibly make use of retry policy to verify the response from back end service. https://learn.microsoft.com/en-us/azure/api-management/api-management-advanced-policies#Retry. You can use the retry result to send back 429 response.
Related
I'm using the Laravel middleware rate limiter to limit HTTP requests to a particular route. I need some way of generating a log message or alert when that limit is exceeded. I have not been able to find an event that Laravel emits or an easy way to hook a call to my code into that process.
Is there a conventional way to do this that someone could tell me?
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.
Is there any way to get the response body in Azure Logic App even when we get 500 Internal Server Error?
I have made the Logic App in a way that I'm setting the response code to 500 on an issue, and I'm adding some error related information in the response body. I tried returning 504 Gateway timeout as well, in case of a timeout issue I could face, but I'm always receiving a null response body in case of non-200 response codes.
If we are not able to see the response body in case of an error by design, is there a better way to set and fetch error related information from the response object?
Yes you can get the response body in Azure Logic App by adding the response action. According to this Add a Response action section of the Microsoft document.
When you use the Request trigger to handle inbound requests, you can model the response and send the payload results back to the caller by using the built-in Response action.
Following steps would help you to get the response body.
In the Logic App Designer, under the step where you want to add a Response action, select New step.
The under Choose an action, in the search box, enter response as your filter, and select the Response action.
Now add any values that are required for the response message. For the Body, you can select the trigger body output from the dynamic content list.
I would suggest to read the Receive and respond to inbound HTTPS requests in Azure Logic Apps document for more information.
Alternatively you can also create alerts whenever HTTP 500 errors occur in your App and use Application Insights to view it using Azure Monitor. I would also suggest to read this Handle errors and exceptions in Azure Logic Apps Microsoft document for more information.
According to the HTTP 1.1 spec, browsers should retry a request if they pass a certain time limit or if an error response is received. POST requests are no exception.
Occasionally, slow connections combined with a processor heavy request can cause an ajax POST request to time out, and the browser will fire a second POST request with the same data. This leads to unexpected and erroneous behaviors. Is there any way to prevent that browser timeout from triggering and firing a second POST request?
Based on my understanding you can't restrict the client to stop automatic retries.
The best option is to handle the identical requests in the server side by using unique GUID's.
https://blogs.oracle.com/ravello/beware-http-requests-automatic-retries/comment-submitted?cid=b956dee8-7352-4d88-ad40-71ff9fd1eb53
I'm getting the following error intermittently when invoking the custom search api from a server side setup:
HttpError 403 when requesting https://www.googleapis.com/customsearch/v1?q=John+Doe+john%40simpler.com&alt=json&cx=&key= returned "There is a per-IP or per-Referer restriction configured on your API key and the request does not match these restrictions. Please use the Google Developers Console to update your API key configuration if request from this IP or referer should be allowed.
I'm using a server api key, and have confirmed that the configured server ip address is correct. And about 50% of the time my request come back fine, too. I'm issuing the request from the server like this:
service = build("customsearch", "v1",
developerKey=api_key)
custom_search_context = <my_context>
res = service.cse().list(
q=search_query_string,
cx=custom_search_context,
).execute()
My requests per sec are well with in the configured limit of 10/sec and daily purchased limit of 5000 requests.
One more thing I noticed is that Google counts a forbidden request towards the daily limit, too.
Any pointers on why I'm being presented with the error only intermittently would be very helpful
The error can be raised when you're exceeding a request/second limit. Can you confirm that your request rate is below your configured user rate limit? It might be worth noting that the limit is enforced even if you don't explicitly provide a user value in your requests.