-
Notifications
You must be signed in to change notification settings - Fork 76
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
[5/n] [dropshot] add support for per-endpoint size limits #1171
[5/n] [dropshot] add support for per-endpoint size limits #1171
Conversation
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1 [skip ci]
|
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1 [skip ci]
I've rebased the stack on to main, resolving conflicts with #1115. |
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 assume this would be ... fine?
#[endpoint {
request_body_max_bytes = "100000".try_into().unwrap(),
....
}
Yeah?
This all looks good
dropshot_endpoint/src/lib.rs
Outdated
/// // Optional maximum request body size in bytes | ||
/// request_body_max_bytes = 1 * 1024 * 1024, |
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 know tags
indicates that it's optional, but all these are optional. I would suggest:
/// #[endpoint {
/// // Required fields
/// method = { DELETE | HEAD | GET | OPTIONS | PATCH | POST | PUT },
/// path = "/path/name/with/{named}/{variables}",
///
/// // Optional fields
/// // Tags to be included in the OpenAPI document
/// tags = [ "all", "your", "OpenAPI", "tags" ],
/// // Specifies the media type used to encode the request body
/// content_type = { "application/json" | "application/x-www-form-urlencoded" | "multipart/form-data" }
/// // A value of `true` marks the operation as deprecated
/// deprecated = { true | false },
/// // A value of `true` causes the operation to be omitted from the API description
/// unpublished = { true | false },
/// // Maximum request body size in bytes; may be any rust expression including a constant.
/// request_body_max_bytes = 1 * 1024 * 1024,
Small suggestion for clarity of the value, but I'm not in love with what I wrote...
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'll try and make this clearer, good catch.
Yeah, any expression that evaluates to a usize would work (doesn't need to be a const expression specifically). |
Created using spr 1.3.6-beta.1 [skip ci]
Created using spr 1.3.6-beta.1
dropshot_endpoint/src/lib.rs
Outdated
/// unpublished = { true | false }, | ||
/// // Optional maximum request body size in bytes | ||
/// // Maximum request body size in bytes (default: server config default_request_body_max_bytes) |
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 is good, but I think it would be nice to let people know that a CONSTANT would be fine here (the fact that any expression works is fine, but I think the interesting thing is that a constant works).
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 was trying to keep the comment short to be honest. I think the best thing to do here would be to use Markdown for all the configuration parameters, similar to the tag configuration section 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've expanded the docs and added a clearer hint about being able to use constants.
…#1173) In upcoming work (#1171), we're going to add optional per-endpoint size limits. To make it clear that per-endpoint limits always override whatever's specified in the configuration, rename this field. (Without the rename, it can be confusing to determine what happens if the per-endpoint limit is smaller than the configuration limit.) Also add a deserialize-time check to fail if `request_body_max_bytes` is specified, guiding users to the new name.
This is part of `RequestContext`, and returns metadata that's stored on the endpoint. In upcoming work (#1171) we're going to add per-endpoint size limits to this struct.
Created using spr 1.3.6-beta.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.
Nice! Nothing major here, just a few doc requests and a suggestion.
@@ -218,6 +224,9 @@ pub struct RequestEndpointMetadata { | |||
|
|||
/// The expected request body MIME type. | |||
pub body_content_type: ApiEndpointBodyContentType, | |||
|
|||
/// The maximum number of bytes allowed in the request body, if overridden. | |||
pub request_body_max_bytes: Option<usize>, |
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.
What do you think of calling this request_body_max_bytes_override
? (I'm honestly not sure. Sometimes I find that suffix clarifies that what might be here is an override of some other value that comes from some place else. Otherwise, you might think that if this were None
that there was 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.
Hmm, not sure -- personally I feel like if you're using this you're likely also aware of the default in the config, maybe? I generally lean towards shorter names over spelling things out completely, especially when there's a clear chain of implication.
@@ -707,7 +707,7 @@ | |||
//! |
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 belongs at L309, but, you know, thanks GitHub.
I think you want to add this to the synopsis at L309 and also add a note about it in that section (#[endpoint { ... }] attribute parameters
) around L322).
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.
Hmm, the synopsis doesn't cover all the arguments today so it would be a bigger change. I can make this change but it would be a substantial one that I would do separately.
(This is where I feel like not having everything in the lib.rs documentation, but instead having an external documentation site, might be useful.)
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.
Oh, so I just realized that versions
is specified in dropshot/src/lib.rs
but not in the dropshot_endpoint::endpoint
documentation. There are also several parameters described in endpoint
but not in dropshot/src/lib.rs
.
Yikes -- I think the list of arguments should only be specified in one spot!
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.
#1181 does that. I'd like to not block on it if that's ok, I think that's a bigger fix that should be done in a followup.
Created using spr 1.3.6-beta.1
Created using spr 1.3.6-beta.1
In the review for #1171 I realized that we were specifying the endpoint attribute params in two places, neither of which had a complete list. Put it all in one place: on documentation for the proc macro. Also move the documentation to `dropshot/src/lib.rs` to allow doctests to work.
For some endpoints like uploading update and support bundles, we would like to
have a larger request limit. Add support for that.
This is the other half of RFD 353, after #617. (A previous attempt was #618,
which I've abandoned.)
The PR consists of:
Depends on: