Remove ContentLengthLimit
#1400
Conversation
Yes I think that would be good to add as well. I think that should be its own PR though.
Hm I didn't really consider that. I suppose yes, we would have to add the rejection variants from |
nylonicious
changed the title
|
I couldn't find any other nice way of adding |
The original implementation of check_max_body_size relied on the size_hint provided by Axum. However, we've encountered instances where check_max_body_size incorrectly returns a BAD_REQUEST response due to inaccurate size_hint values. This commit changes to use `DefaultBodyLimit`, which is the suggestion by axum. See also - tokio-rs/axum#1400 - tokio-rs/axum#1397
The original implementation of check_max_body_size relied on the size_hint provided by Axum. However, we've encountered instances where check_max_body_size incorrectly returns a BAD_REQUEST response due to inaccurate size_hint values. This commit changes to use `DefaultBodyLimit`, which is the suggestion by axum. See also - tokio-rs/axum#1400 - tokio-rs/axum#1397
The original implementation of check_max_body_size relied on the size_hint provided by Axum. However, we've encountered instances where check_max_body_size incorrectly returns a BAD_REQUEST response due to inaccurate size_hint values. This commit changes to use `DefaultBodyLimit`, which is the suggestion by axum. See also - tokio-rs/axum#1400 - tokio-rs/axum#1397
Closes #1399
Before I continue I wanted to ask if the implementation should live in the
Bytesextractor, and if so should we also check the method likeContentLengthLimitimpl used to? If the impl should live in in the Bytes extractor what with rejections, should I just extend it with the required fields or maybe add one variant toBytesRejectionnamed something likeBodyLimitRejectionand store more detailed rejection inside that variant?