Skip to content

Code-generate const Mime values for each expected Content-Type in a request #3703

Open
@david-perez

Description

@david-perez

Currently, we re-parse expected request Content-Type header values into mime::Mimes every time we service a request. It'd be more efficient if aws_smithy_http_server::protocol::content_type_header_classifier_smithy took in directly a const Mime type.

Note that we already do this to check the Accept header (against the Content-Type of the response):

val verifyAcceptHeaderStaticContentTypeInit =
writable {
httpBindingResolver.responseContentType(operationShape)?.also { contentType ->
val init =
when (contentType) {
"application/json" -> "const $staticContentType: #{Mime}::Mime = #{Mime}::APPLICATION_JSON;"
"application/octet-stream" -> "const $staticContentType: #{Mime}::Mime = #{Mime}::APPLICATION_OCTET_STREAM;"
"application/x-www-form-urlencoded" -> "const $staticContentType: #{Mime}::Mime = #{Mime}::APPLICATION_WWW_FORM_URLENCODED;"
else ->
"""
static $staticContentType: #{OnceCell}::sync::Lazy<#{Mime}::Mime> = #{OnceCell}::sync::Lazy::new(|| {
${contentType.dq()}.parse::<#{Mime}::Mime>().expect("BUG: MIME parsing failed, content_type is not valid")
});
"""
}
rustTemplate(init, *codegenScope)
}
}

It's probably better if we decide on #2666 before tackling this issue, to avoid throwaway work.

Originally source of this issue is #3690 (comment).

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions