Just before we dive in, we’d like to note that further insights on this topic are availble on the “Microsoft Learn” website.
Using the “validate-content” policy, not only can you validate the request’s size, but also ensure that the incoming or outgoing body aligns with the API specification. Currently, this supports both JSON & XML payloads.
Where can you use it?
Everywhere! Whether it’s coming in, going out, or oops…an error. This policy can be used in the “inbound“, “outbound“, and “error” sections, encompassing all scopes.
Size does matter… But there’s flexibility!
In this blog post, we’ll delve deeper into the topic of size validation. By default, the maximum allowable size is 100KB. However, this can be increased to 4MB by reaching out to support, as highlighted on the Microsoft Learn website.
For one of our projects, our messages contained embedded PDFs and images. It’s worth noting that base64 encoding inflates the size by about 33%. This means the standard 100KB isn’t adequate for our needs. For this particular case, we then initiated a support ticket to raise the limit to 4MB. Interestingly, out of 10,000 messages, only a handful, maybe 5 exceeded 4MB, reaching sizes of 5MB or 6MB.
Going our own way
Various online resources suggest creating an “Azure function” or similar for validation. However, this wasn’t the route we wanted to take.
Digging deeper into the policies and referencing the information from the Microsoft Learn pages, we found a workaround in APIM for larger messages. There’s a mandatory field labeled “max-size”, along with the essential attribute “size-exceeded action”, offering three choices: “ignore”, “prevent” and “detect”.
Choosing “detect” will simply log any “validation errors” without affecting the request or response cycle.
If you pick “prevent“, it verifies the payload size, potentially blocking the request or response. However, we preferred the “ignore” alternative. This ignores the payload size validation but doesn’t hinder the request or response processing. Importantly, it continues to perform other checks, like matching against the policy’s defined schema. This method lets us validate messages surpassing the “max-size” without needing an external function.
I trust this information will aid many in schema validation, even if they choose to bypass size validation. Just remember, size isn’t everything: it’s all about playing by the rules (or knowing which one to ignore 😉).
