Non-XML Messages

Certain assertions expect an XML payload and will fail if such a Content-Type is not detected at runtime. If your published service is expected to process both XML and non-XML messages, or process messages without payloads (such as GET or DELETE requests), then you should structure your policy to separate XML processing from non-XML processing. This will prevent inconsequential assertion failures from affecting the outcome of your policy.
gateway
Certain assertions expect an XML payload and will fail if such a Content-Type is not detected at runtime. If your published service is expected to process both XML and non-XML messages, or process messages without payloads (such as GET or DELETE requests), then you should structure your policy to separate XML processing from non-XML processing. This will prevent inconsequential assertion failures from affecting the outcome of your policy.
For example, the Protect Against Document Structure Threats assertion is designed to detect XML threats and will fail when processing a non-XML message. However, failing in this manner has little consequence, since non-XML messages cannot contain an XML threat.
Assertions that Require XML
The following assertions require that a message be XML:
(Non-SOAP) Check Results from XML Verification
(Non-SOAP) Decrypt XML Element
(Non-SOAP) Encrypt XML Element
(Non-SOAP) Sign XML Element
(Non-SOAP) Verify XML Element
Add or Remove XML Elements(s)
Apply XSL Transformation
Document Structure Threats
Evaluate Request XPath
Evaluate Response XPath
Require XPath Credentials
Validate XML Schema
Assertions that Require SOAP
The following assertions not only require that the request be in XML but that it be SOAP:
Add WS-Addressing
Add or Remove WS-Security
Add Security Token
Add Timestamp
Configure WS-Security Decoration
Encrypt Element
Encode to MTOM Format
Enforce WS-Security Policy Compliance
Enforce WS-I BSP Compliance
Enforce WS-I SAML Compliance
Evaluate WSDL Operation
Exchange Credentials using WS-Trust
Process SAML Authentication Request 
Process RSTR Response
Require Encrypted Element
Require Encrypted UsernameToken Profile Credentials
Require SAML Token Profile
Require Signed Element
Require Timestamp
Require WS-Addressing
Require WS-Secure Conversation
Require WS-Security Kerberos Token Profile Credentials
Require WS-Security Signature Credentials
Require WS-Security UsernameToken Profile Credentials
Sign Element
Use WS-Federation Credential
Validate SOAP Attachments
Example of a Branching Policy
The following sample illustrates how you might implement branching in your policy, to separate the processing of XML requests from non-XML requests:
1
  At Least One Assertion Must Evaluate to True
2
  All Assertions Must Evaluate to True
3
  Compare Expression: Proceed if ${request.http.header.content-type} contains "text/xml"
4
  All Assertions Must Evaluate to True
5
  
<portion of policy relating to XML messages>
6
  All Assertions Must Evaluate to True
7
  Compare Expression: Proceed if ${request.http.header.content-type} does not contain "text/xml"
8
  All Assertions Must Evaluate to True
9
  
<portion of policy relating to non-XML messages or empty payloads>
10
  
<portion of policy common to both>
The following table explains the above example in more detail:
Line
Description
1
The "At least" branching ensures that either line 2 (message is XML) or line 6 (message is non-XML) is executed.
2
This "All assertions" folder groups the portion of the policy to be processed if the request is XML.
3
Tests whether the message is XML by examining the Content-Type header. If true, processing continues with line 4. If false, then the Compare Expression assertion fails and the "All assertions" in line 2 fails. Processing then continues with line 6.
4
This "All assertions" folder groups the assertions to be processed for XML requests.  
5
This portion of the policy contains the assertions listed under "Assertions that Require XML" or "Assertions that Require SOAP" above.
6
This "All assertions" folder groups all the assertions to be processed if the request is non-XML or if line 4 fails.
7
Tests whether the message is non-XML by examining the Content-Type header. If true, processing continues with line 8. If false, then the Compare Expression assertion fails and the "All assertions" in line 6 fails. Processing then continues with line 10.
8
This "All assertions" folder groups the assertions to be processed for non-XML requests.
9
This portion of the policy contains the assertions not listed under "Assertions that Require XML" or "Assertions that Require SOAP" above.
10
List policy logic common to both XML and non-XML messages here.