Question & Answer
Question
Each XML Firewall or Multi-Protocol Gateway service has a processing policy that consists of one or more rules. These rules specify the criteria by which that rule is selected and the actions that are performed as the request or response passes through that service. But, what happens if none of the rule criteria is matched by any of the rules in the policy? The behavior of the service depends on many factors, including the request type, the response type, the type of service object, and so on. When no processing policy rules of a processing policy are matched, the default behavior might not be the behavior that you want. Instead of using the default behavior, you can control the behavior with "match all" rules.
Cause
When you define a DataPower service, if no processing policy rules are matched within that service, then the request takes the default actions for that service. The default actions are based on the service type, and the request and response types. In some cases, the actions might be to respond back with a 500 response code. In other cases, the request might be allowed to pass through the service.
To control the default behavior, add a "match-all" rule with the specific behavior to the end of the list of rules for that processing policy.
Answer
When you create a service, add a processing policy rule to the bottom of the list of rules. This rule should match all requests, and it should define the behavior you want to have when no other rules match. Repeat for a response rule.
For example, consider configuring a match-all rule by specifying "*" for the URL to match on. All requests that are not handled by one of the preceding rules are handled explicitly by this match-all rule. This match-all rule can perform any operation on that request. If you want to pass the request through to the back end, you can do so. If you want to reject the request, you can do that as well.
To handle both request side and response side traffic, add a "match all" rule both to the client to server and to the server to client directions.
Some additional considerations depend on the request or response type and, in some cases, the service type:
- Pass Through (unprocessed)
- Use the default configuration that disables the HTTP GET method.
- Handle the request with a "match all" rule.
- Handle the request with a rule that matches explicitly the HTTP GET method.
If you specify the request type to be "Pass Through", that request passes through the service to the back end. Likewise, if you specify "Pass Through" for the response type, the response from the back end passes through the service back to the original client. If "Pass Through" is specified, then the match-all rule for that direction is not required as it is ignored.
HTTP GET
The HTTP GET request also, by default, passes through the service if it is not explicitly matched. There are several ways to prevent an HTTP GET request from passing through a service:
JSON
The JSON request or response type defaults to pass the request through when the payload or body contains NULL or valid JSON. IBM reserves the right to change this behavior in the future.
NON-XML (pre-processed)
When the Multi-Protocol Gateway service receives the NON-XML request or response types, by default the service allows the requests and responses to pass through the service. However, when the XML Firewall service receives the NON-XML request or response types, the service rejects requests or responses and returns a 500 response code.
In summary, when you create a DataPower service, explicitly add a "match all" rule in each direction that delivers the behavior that you want. Use this "match all" rule to reject requests and responses that fall outside of the parameters for which the service was intended.
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21640935