Join GitHub today
[policy] [request-content-limit] Request Content Limit Policy does not support transfer-encoding #1547
The Request Content Limit Policy requires the Content-Length header to be present in the request. There are two scenarios where a request will fail but should not:
The Request Content Limit Policy should handle requests that use transfer-encoding. More specifically, in RequestContentLimitPolicy, the onRequest() method should be altered to not throw an Exception when the Content-Length header is present and it a method annotated with @OnRequestContent should be added which checked for the transfer-encoding header and wraps the ReadWriteStream and throws and exception when the content limit is reached.
In its current implementation, not all client requests are supported
Yes, we are already aware of this issue.
I agree with the first point but not with the second. As per the RFC:
In other words, it's not forbidden, but it's undefined behavior and should be avoided.
From my point of view, is it the responsibility of the user to not attach a request-content-limit policy to GET methods (also HEAD, TRACE and OPTIONS, ...)
I agree that the rfc discourages a body for GET, but i feel like this is something that happens in the world today (whether or not we agree with it). by not supporting it, you exclude gravitee from being used with apis which use it. (i think DELETE falls into the same bucket).
My concern is if a client decides to send a large payload with a GET request (regardless of whether the backend API supports it or not), I still want to be able to limit the size of that payload at the Gateway to protected the Gateway and the backend from content that is too big. If the policy can't handle a request without a Content-Length, then I can't put it on GET requests and thus protect against large payloads.