A request or response message might trigger the "Invalid HTTP Message" IDP rule in Sentry resulting in the "No Matching Request Filter" error. This is a very common support issue that is easily identified and resolved.
To resolve the problem, ensure that the client is specifying the correct Content-Type HTTP Header and/or using the appropriate HTTP Method. Alternatively you can adjust the HTTP Request Filters defined for the policy.
More information..
By default, WSDL and XML policies in Sentry are configured to allow a specific Content-Type HTTP Header and a specific HTTP Method. The Content-Types and HTTP Methods allowed are both defined in the HTTP Request Filters enabled for the policies. These can be accessed from the Virtual Directory page of a WSDL or XML policy.
For a SOAP 1.1 service the default "SOAP 1.1 Filter" is typically used. This allows for a Content-Type of text/xml and an HTTP Method of POST.
For a SOAP 1.2 service the default "SOAP 1.2 Filter" is typically used. This allows for a Content-Type of application/soap+xml and an HTTP Method of POST.
With WSDL policies, the specific HTTP Request Filters are derived from the WSDL itself and therefore are editable but new HTTP Request Filters cannot be created.
With XML policies, the user can choose from the default list of HTTP Request Filters or create their own and enable as many HTTP Request Filters as necessary.
If a request comes into Sentry that has the wrong Content-Type or is using the wrong HTTP Method, the processing fails with the following error being logged to the System log:
Error Code 0600D:
IDP Rule: 'Invalid HTTP Message', IDP Group 'System Group', Associated Policy: System, Triggered 1 time(s) on Request, Policy: Test WSDL Policy, Client IP: 10.1.2.3, User: -. No matching request filter.
The following SOAP Fault (or something similar depending on your custom error templates) is returned to the calling client application:
To see the Content-Type and Method being used by the client, you can enable DEBUG level logging for the Sentry System log and look for the following entry which shows the incoming HTTP Headers for the request message:
Logging Code 09140:
Received an HTTP request:
Protocol: HTTP/1.1
Scheme: http
Method: POST
Client: 10.1.2.3
Request URL: http://10.1.2.4/testPolicy/test.asmx
Listener Policy: TestPolicyListener
Virtual Directory: /testPolicy/test.asmx/*
Auth Type:
Cookies:
Header Info:
User-Agent: Crosscheck Networks SOAPSonar
Content-Type: text/xml;charset=utf-8
SOAPAction: "http://testSentry/testPolicy/echo"
Host: 10.1.2.3
Content-Length: 362
Connection: keep-alive
To see the Content-Type and Method being used by the client, you can enable DEBUG level logging for the Sentry System log and look for the following entry which shows the incoming HTTP Headers for the request message:
Logging Code 09140:
Received an HTTP request:
Protocol: HTTP/1.1
Scheme: http
Method: POST
Client: 10.1.2.3
Request URL: http://10.1.2.4/testPolicy/test.asmx
Listener Policy: TestPolicyListener
Virtual Directory: /testPolicy/test.asmx/*
Auth Type:
Cookies:
Header Info:
User-Agent: Crosscheck Networks SOAPSonar
Content-Type: text/xml;charset=utf-8
SOAPAction: "http://testSentry/testPolicy/echo"
Host: 10.1.2.3
Content-Length: 362
Connection: keep-alive
To resolve the problem, ensure that the client is specifying the correct Content-Type HTTP Header and/or using the appropriate HTTP Method. Alternatively you can adjust the HTTP Request Filters defined for the policy.
0 Comments