High Payload Response Failures
Article ID: 200819
Updated On:
Products
Issue/Introduction
We are noticing an issue in our one cluster where we are seeing that the high response payloads i.e json/xml higher than default 2.5 mb are failing, while on other cluster it is processed successfully.
io.xmlPartMaxBytes=2621440 is same on both clusters.
The response content type is application/json.
On the working cluster we are able to parse even 5 MB files without issue.
-- error in logs
2020-10-01T05:33:23.733+0000 WARNING 21107 com.l7tech.server.policy.variable.ServerVariables: Unsupported variable: size (Unable to read stream: the specified maximum data size limit would be exceeded)
com.l7tech.common.io.ByteLimitInputStream$DataSizeLimitExceededException: Unable to read stream: the specified maximum data size limit would be exceeded
Environment
Release : Any/All
Component : API GATEWAY
Resolution
There are a few factors that are at play with respect to this behavior. I do not believe that these values target an attachment or portion of the message unless specifically targeted at a variable that focuses on a specific attachment (such as request.parts.n). Each of the following configuration options apply the entire message unless configured otherwise:
1. The current value of io.xmlMaxPartBytes
2. The current use of the Limit Message Size assertion
3. The maximum message size assigned to the inbound listen port
These sizes are enforced based on a couple conditions:
1. Whether or not "Perform WS-Security Processing" is enabled for a particular service
2. Whether or not the service policy acts upon the request or response message
If the service policy acts upon a request or response message that exceeds io.xmlMaxPartBytes then the request will fail. Acts upon includes but is not limited to: Any threat protection assertion, XPath evaluation, regular expression evaluation, message transformation.
Subsequently, this limitation is overridden by using Limit Message Size assertion. The Gateway will enforce the message size on a per-service basis as long as that assertion is used even if none of the previously mentioned operations are performed.
The assertion is overridden by enabling "Perform WS-Security Processing..." within the Service Properties dialog. If this is enabled then io.xmlMaxPartBytes overrides the value of Limit Message Size assertion (regardless of which is lowest). This occurs because the WS-Security processing specified above occurs before the service policy itself (and before Limit Message Size would take over as the authority).
Here are some examples of common message resizing issues:
1. If you have a service policy that just streams a request or response and does not act upon the message then there are no limits to the message size enforced by the Gateway. No assertions are necessary unless you need to protect the backend web service from message size-related attacks.
2. If you have a service policy that performs message transformation or evaluation then you will should use the Limit Message Size assertion to set the maximum size on a per-service basis.
3. If you have a Gateway that will always handle large messages and inspect, evaluate, or transform the request or response--regardless of the published service being consumed--then you should set io.xmlMaxPartBytes to an adequately large number.
4. If you have a service on the Gateway that requires WS-Security processing then you should set io.xmlMaxPartBytes to an adequately large number.
5. If you have multiple services on the Gateway that require WS-Security processing then you should publish a "pre-security" global policy fragment and add the Limit Message Size assertion.
Feedback
