search

smithy-lang / smithy-rs

Code generation for the AWS SDK for Rust, as well as server and generic smithy client generation.
Apache License 2.0
491 stars 187 forks source link

More efficient mime type parsing in server SDKs; avoid `mime` crate #2666

Open david-perez opened 1 year ago

david-perez commented 1 year ago

We're currently creating one OnceCell per operation backing a static mime::Mime type for the operation's expected (if present) client Accept header value, only to then decompose it into type + subtype and perform a case-insensitive string comparison check against the actual incoming Accept header value.

It would be more efficient to directly compare &strs and avoid incurring the atomic read.

A simpler, more efficient, and type-safe approach would be to directly switch to something like mediatype, which is const-constructible and zero-copy. Note that mime is not actively maintained.

See https://github.com/awslabs/smithy-rs/pull/2607#discussion_r1173687692 and https://github.com/awslabs/smithy-rs/pull/2629, the PR where we started using OnceCells for this.

hlbarber commented 1 year ago

https://github.com/awslabs/smithy-rs/pull/2629 already uses const in the following cases https://github.com/awslabs/smithy-rs/pull/2629/files#diff-da9c47cae3f2f75fc01b3625ee430f56f2f495870a77302c3c148e98f7341bd4R198-R200.

The migration to a const constructable struct would follow the same pattern.

82marbag commented 10 months ago

https://github.com/hyperium/mime/issues/153 proposes to solve these issues in mime and actively maintain the crate. We work with other of their crates, if it's worth seeing what the proposal will look like and possibly continue with mime