Sometimes, API failures occur due to firewall-level validations.
Recently, we encountered an instance in the AU Production environment where certain APIs were blocked due to the presence of special characters in the request. If such an issue arises, it is recommended to check the firewall logs to quickly identify the root cause. This approach helps reduce debugging time and speeds up resolution.
Example Issue in YBL:
In YBL, we observed an intermittent issue where an API worked at times but failed unexpectedly. Upon investigation, we found that the firewall was blocking the request, resulting in the following error response:
php-template
CopyEdit
<HTML><HEAD>
<TITLE>Internal Server Error</TITLE>
</HEAD><BODY>
<H1>Internal Server Error - Read</H1>
The server encountered an internal error or misconfiguration and was unable to complete your request.<P>
Reference #3.85d70b17.1742205398.6d63ec8
<P>https://errors.edgesuite.net/3.85d70b17.1742205398.6d63ec8</P>
</BODY></HTML>
This issue was not traceable in vConnect, requiring the Designer Team to investigate further based on a raised ticket.
Upon deeper analysis, the team discovered that the request size was exceeding the firewallβs limit, leading to automatic blocking. The root cause was Base64-encoded data being sent in the request, which significantly increased the payload size.
Recommendation:
If a similar issue arises, the first step should be to check the firewall logs for blocked requests. This will help in quickly identifying whether the issue is due to:
- Special characters in the request
- Large request payloads exceeding firewall limits
This proactive approach can reduce debugging time and accelerate resolution.
Let me know if you need further details.