-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a config option to limit request body size #276
Conversation
...vice/src/main/java/org/apache/polaris/service/throttling/RequestThrottlingErrorResponse.java
Show resolved
Hide resolved
...rc/main/java/org/apache/polaris/service/throttling/StreamReadConstraintsExceptionMapper.java
Show resolved
Hide resolved
polaris-service/src/test/resources/polaris-server-integrationtest.yml
Outdated
Show resolved
Hide resolved
public long getMaxDocumentBytes() { | ||
return maxDocumentBytes; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should have a default value.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking a bit more about class StreamReadConstraints
. -1
is the right default value, which means no limit.
public Builder maxDocumentLength(long maxDocLen) {
if (maxDocLen <= 0L) {
maxDocLen = -1L;
}
this.maxDocLen = maxDocLen;
return this;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for pulling this up, this actually makes me more strongly interested in 0. Please see my new comment below.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also find 0-as-unlimited a little confusing. I agree that if we make the default -1 it might imply that 0 is different from -1, but I also think a default of 0 is going to raise some questions.
Maybe we should just disallow 0, since StreamReadConstraints
doesn't support what 0 would intuitively mean ("reject all requests")
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the code from StreamReadConstraints, that means both 0 and -1 are considered no limits. But I think it does make sense to have -1 for unlimited and disallow 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok I updated it to default to -1, explained what -1 is, and restricted 0 with an exception/useful comment. I agree that -1 is a better indicator of "no limit" and restricting 0 solves some ambiguity.
I agree with the reasons for wanting to make -1 the default value, but I'd like to offer a counterargument for why it may make sense to keep it at 0 in this case:
|
I'm fine with either -1 or 0. My main concern with using 0 is that there is a chance that it might be misunderstood as a valid limit rather than indicating "no limit." In contrast, -1 is less ambiguous in this context. Additionally, I recommend defining a constant for clarity:
|
polaris-server.yml
Outdated
@@ -167,3 +167,5 @@ logging: | |||
archivedLogFilenamePattern: ./logs/polaris-%d.log.gz | |||
# The maximum number of log files to archive. | |||
archivedFileCount: 14 | |||
|
|||
maxDocumentBytes: 0 # Don't set a limit |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- This comment would ideally not be inline
- Do we really want to call this
maxDocumentBytes
? What is a "Document" in the context of a Polaris instance? - Whatever we call it, we might put a small comment explaining what this is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Renamed to maxRequestBodyBytes and updated/moved the comment.
Just updated a couple of things:
|
// we block 0 to prevent ambiguity. | ||
throw new IllegalArgumentException( | ||
String.format( | ||
"maxRequestBodyBytes may not be 0. Use %d to specify no limit.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: "maxRequestBodyBytes must be a positive integer or %d
to specify no limit."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
@@ -146,6 +149,23 @@ public void setFeatureConfiguration(Map<String, Object> featureConfiguration) { | |||
this.configurationStore = new DefaultConfigurationStore(featureConfiguration); | |||
} | |||
|
|||
@JsonProperty("maxRequestBodyBytes") | |||
public void setMaxRequestBodyBytes(long maxRequestBodyBytes) { | |||
if (maxRequestBodyBytes == 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Maybe we should constrain this to a positive integer or -1 while we're at it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to restrict all but -1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with one minor question.
@@ -146,6 +149,23 @@ public void setFeatureConfiguration(Map<String, Object> featureConfiguration) { | |||
this.configurationStore = new DefaultConfigurationStore(featureConfiguration); | |||
} | |||
|
|||
@JsonProperty("maxRequestBodyBytes") | |||
public void setMaxRequestBodyBytes(long maxRequestBodyBytes) { | |||
if (maxRequestBodyBytes == 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider throwing an exception when the configured value for maxRequestBodyBytes is less than -1 (e.g., -2, -100)? While the underlying library can technically handle these values, I believe we should restrict any negative number except for -1, which is already treated as "unlimited." This is consistent with our approach of throwing an exception for a value of 0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated to restrict all but -1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM with some optional nits. Thanks for the change!
* limits | ||
*/ | ||
public class RequestThrottlingErrorResponse { | ||
public enum Error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error
is a name from java.lang
- can you choose something different here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated
// same, so | ||
// we block all but -1 to prevent ambiguity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This formatting looks a bit odd. Can it be 2 lines?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated.
I've just been letting spotless take the wheel with these, but I guess it's ok with either style? We should probably update it to prefer a single format if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 with a minor suggestion
if (maxRequestBodyBytes <= 0 && maxRequestBodyBytes != -1) { | ||
// The underlying library that we use to implement the limit treats all values <= 0 as the | ||
// same, so we block all but -1 to prevent ambiguity. | ||
throw new IllegalArgumentException( | ||
String.format( | ||
"maxRequestBodyBytes must be a positive integer or %d to specify no limit.", | ||
REQUEST_BODY_BYTES_NO_LIMIT)); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor suggestion:
Preconditions.checkArgument(condition, message);
Thanks @andrew4699 for working on this. Thanks @snazy @eric-maynard for the review. |
Description
Adds a config option to limit the request body size. This is useful to prevent DoS-style attacks before the request moves further through the request handlers.
Type of change
How Has This Been Tested?
Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration
Checklist:
Please delete options that are not relevant.