I have an api proxy with the default fault rule configured and alwaysEnforce set to false. The default fault rule gets executed for http 404 errors, or if there is a raise fault configured from the api proxy flows.
One of the requests with a file upload (coming from a UI) is failing due to file size being very large. Apigee throws 405 error in this case. The UI expects CORS headers to be part of the response and I set those in the default faultrule while sending the error response.
This the default faultrule configuration in the proxy endpoint
<DefaultFaultRule name="DefaultFaultRule"> <AlwaysEnforce>true</AlwaysEnforce> <Step> <FaultRules/> <Name>AddCORSHeaders</Name> </Step> <Step> <FaultRules/> <Name>ReturnGenericError</Name> </Step> <AlwaysEnforce>false</AlwaysEnforce> </DefaultFaultRule>
Trace file attached.
Trace shows error.state=REQ_HEADERS_PARSED. How do you capture this to trigger the fault rule?
However, I noticed that the default fault rule does not get triggered in the above scenario. Any pointers on how to handle this?
[Using Apigee private cloud 4.18.05.06]
Solved! Go to Solution.
According to the docs:
A DefaultFaultRule acts an exception handler for any error that is not explicitly handled by another FaultRule.
If you want the DefaultFaultRule steps to always execute then set:
<AlwaysEnforce>true</AlwaysEnforce>
In your snippet you have <AlwaysEnforce>true</AlwaysEnforce> at the top and <AlwaysEnforce>false</AlwaysEnforce> at the bottom which I suspect is what Apigee is interpreting the value to be.
Can you add the cors in your response flow in proxy endpoint or target endpoint?
We do add the cors normally in response flow.
According to the docs:
A DefaultFaultRule acts an exception handler for any error that is not explicitly handled by another FaultRule.
If you want the DefaultFaultRule steps to always execute then set:
<AlwaysEnforce>true</AlwaysEnforce>
In your snippet you have <AlwaysEnforce>true</AlwaysEnforce> at the top and <AlwaysEnforce>false</AlwaysEnforce> at the bottom which I suspect is what Apigee is interpreting the value to be.
oh, good answer! So, something like this:
<DefaultFaultRule name="DefaultFaultRule"> <AlwaysEnforce>true</AlwaysEnforce> <Step> <Name>AddCORSHeaders</Name> </Step> <Step> <Name>ReturnGenericError</Name> </Step> </DefaultFaultRule>
It's a bit of an unhappy situation that Apigee tolerates more than one AlwaysEnforce
element.
I wonder if this error would be caught if you ran your proxy through the apigeelint tool. I'll have to check if apigeelint does schema validation.
EDIT. I added a pull request for appigeelint to check for this.
@Kurt Googler Kanaskie, Thanks for catching that.
I removed the <AlwaysEnforce>false</AlwaysEnforce> tags, and that solved the issue for http 405 errors on the proxy endpoint. I noticed that I had to set AlwaysEnforce = true for the default faultrule to be triggered for the http 405 error; with AlwaysEnforce changed to false the default faultrule was not triggered. I was expecting it to be triggered, since I have not other specific faultrules defined other than for API Key failed.
But the issue still persists when target endpoint throws http 503, even though I have a default faultrule in the target endpoint as below. Does the defaultFaultRule work differently on the target endpoint side?
<DefaultFaultRule name="DefaultFaultRule"> <AlwaysEnforce>true</AlwaysEnforce> <Step> <FaultRules/> <Name>AddCORSHeaders</Name> </Step> <Step> <FaultRules/> <Name>ReturnGenericError</Name> </Step> </DefaultFaultRule>