As part of Threat protection policies we have implemented both Json & XML policies. But these are executed only if content type (either application/Json or application/xml) is provided as part of request. Client can send the request with out content-type explicitly. Hence do we need to make content types are mandatory or any other technical suggestion on this for implementation
Solved! Go to Solution.
To be precise, you need to add some conditional logic to ensure the requests have a valid content-type header.
For example, if you support both json and xml you could use something like:
<Step> <Condition>(request.header.content-type != "application/json") and (request.header.content-type != "application/xml")</Condition> <Name>RF-InvalidContentType</Name> </Step> <Step> <Condition>request.header.content-type == "application/json"</Condition> <Name>TP-JSON</Name> </Step> <Step> <Condition>request.header.content-type == "application/xml"</Condition> <Name>TP-XML</Name> </Step>
Hope that helps.
To be precise, you need to add some conditional logic to ensure the requests have a valid content-type header.
For example, if you support both json and xml you could use something like:
<Step> <Condition>(request.header.content-type != "application/json") and (request.header.content-type != "application/xml")</Condition> <Name>RF-InvalidContentType</Name> </Step> <Step> <Condition>request.header.content-type == "application/json"</Condition> <Name>TP-JSON</Name> </Step> <Step> <Condition>request.header.content-type == "application/xml"</Condition> <Name>TP-XML</Name> </Step>
Hope that helps.
Thanks for your inputs. We thought there will be Apigee proxy level setting to mandate content -types since this is common behaviour across all API's. Now we have to go with implementation as you suggested