Modifying "HTTP Method not allowed"
Article ID: 144547
Updated On:
Products
Issue/Introduction
The customer stumbled upon a use-case which is somewhat security related and was addressed to us that we should correct it.
We have about 100 policies in service which are mainly handled by one global policy which does all of the validations and routing in a general matter. The allowed HTTP methods then are defined for each individual policy separately via the default check boxes we can select in service properties.
The problem arises once a client is actually using an invalid method. The CA API Gateway by default returns an automatic payload with status 500 which is straight up wrong, it should be 405 and return in the "Allow" header, which methods are allowed.
In addition to that, should the client use an "unknown" method like "COPY" which is identified as "OTHER" by the CA API Gateway, the payload returned currently is like this:
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<soapenv:Fault>
<faultcode>soapenv:Server</faultcode>
<faultstring>Error in assertion processing</faultstring>
<faultactor><url></faultactor>
<detail>
<l7:policyResult
status="HTTP method OTHER not allowed: <url>" xmlns:l7="http://www.layer7tech.com/ws/policy/fault"/>
</detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
This is very confusing for the client so our goal was to modify it to our needs. (Returning 405 possibly with Allow header with allowed methods and without any payload)
Turns out, this is a bit more complicated than expected. I was expecting that I could figure out which methods are enabled for one service for instance by comparing the request.http.method variable with a multivalued variable or something returned by the called service but it appears that no such variable exists that lists all enabled methods for a service.
This would mean, we would have to manually update each of these policies and add each method there separately resulting in each service having custom configurations, partially making our current solution with the global policy inefficient.
Do you know of any easier way we could handle this? I'm not sure if version 9.4 has better options. I read a couple articles that mention we should do it within the message-received global policy by accessing the database of the CA API Gateway but this is not really an approach I want to go for.
We defined the SEP_Global_policy as a policy without a service (some sort of self-global policy) which we then just include on all the different services we have via the Include Policy Fragment assertion (that's the only assertion we use in 99% of the services).
Since we also use the global message_completed policy, I uploaded the policy for that as well.
Environment
Release : 9.3
Component : API GTW ENTERPRISE MANAGER
Resolution
Suppose one of the APIs raised error as the HTTP method was not supported so how will you know which API call is failed?
You can create a policy which will use the following statement
"The API \${request.http.uri} failed as \${\$request.http.method} is not supported" and the final response status code would be say 500 (Internal Server Error) or any other status code for that matter. This way the end user would have some idea about what's going on without going to the log and checking the error details. There are various other context variables which you can use to frame the custom message.
Please check the tech-docs for the exhaustive list.
Feedback
