-
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
[3/n] rename request_body_max_bytes to default_request_body_max_bytes #1173
[3/n] rename request_body_max_bytes to default_request_body_max_bytes #1173
Conversation
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]
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.
looks good; some questions
#[derive(Clone, Debug, PartialEq, Serialize)] | ||
pub enum InvalidConfig {} | ||
|
||
fn deserialize_invalid_request_body_max_bytes<'de, D>( |
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.
do we prefer this to impl Serialize for InvalidConfig
?
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 pattern allows a custom error message to be passed in -- InvalidConfig
is a general marker value that shouldn't necessarily be tied with the specific error message.
I'll add a comment to this note.
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 also this returns an Option<InvalidConfig>
which wouldn't be possible to do via a type implementation.
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 also this returns an
Option<InvalidConfig>
which wouldn't be possible to do via a type implementation.
that's true... but I think impl Serialize for InvalidConfig
would probably suffice since the implementation of Serialize for Option will call 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.
Hmm, InvalidConfig
doesn't implement Serialize
at all (the skip_serializing
makes that moot). This code only does deserialization.
#[serde(default)] | ||
#[serde( | ||
from = "DeserializedConfigDropshot", | ||
into = "DeserializedConfigDropshot" |
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's the point of the into?
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.
It is possible to derive Serialize
on ConfigDropshot
directly, and it would work today, but in case there's more divergence between the in-memory implementation and the serializable implementation over time, that may no longer hold true. I've seen this be a recurring source of bugs in other places, and making the types that directly interact with serde be the same for serialization and deserialization has always been helpful.
default_handler_task_mode: HandlerTaskMode::Detached, | ||
log_headers: Default::default(), | ||
} | ||
} | ||
} | ||
|
||
#[derive(Clone, Debug, Deserialize, PartialEq, Serialize)] |
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.
does this need to be Serialize?
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 coupled with the into
comment.
Created using spr 1.3.6-beta.1
Going to go ahead and land this per chat message -- happy to address lingering comments in a followup. |
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
isspecified, guiding users to the new name.
Depends on: