Inconsistent behaviour when responding to requests w/ invalid Content-Type

[raif-s-naffah]

Hi there,

The following code shows two requests where the Content-Type header is syntactically invalid and Rocket returning two different HTTP Status codes when only one (400) was expected.

use rocket::{http::Status, post, routes};
use rocket_multipart::MultipartReader;

#[post("/", data = "<data>", format = "multipart/mixed")]
fn post_mixed(data: MultipartReader<'_>) -> Result<String, Status> {
    todo!()
}

#[rocket::launch]
fn rocket() -> _ {
    rocket::build().mount("/statements", routes![post_mixed])
}

#[cfg(test)]
mod tests {
    use super::*;
    use rocket::{http::Header, local::blocking::Client};

    #[test]
    fn test_invalid_ct() {
        let client = Client::tracked(rocket()).expect("valid rocket instance");

        let req = client
            .post("/statements")
            .header(Header::new("Content-Type", "multipart/mixed"));
        let resp = req.dispatch();
        assert_eq!(resp.status(), Status::BadRequest);

        let req = client
            .post("/statements")
            .header(Header::new("Content-Type", "multipart/mixed;"));
        let resp = req.dispatch();
        assert_eq!(resp.status(), Status::NotFound);
    }
}

The 2 requests use invalid syntax for the CT header. The first is missing the mandatory boundary attribute required when multipart is specified. The second has an incomplete (";" parameter) term as described in RFC-2045, section 5.1.

is there a way of configuring Rocket to treat the two cases similarly and return a 400 status code when a route is matched but the mime type in the request is invalid?

TIA + cheers;
rsn

[the10thWiz]

There are two options. You could add a secondary route (or a blanket, low ranked route) that catches invalid content-types, and returns a 400.

The other option, and the one I think makes more sense long term, is to add support for this in Rocket. Rocket parses a number of headers by default, and I think a parse error in any of them should cause the default error type to be a 400, rather than the current default of 404. If you're interested, we would accept a PR that implements this behavior.

[raif-s-naffah]

hi @the10thWiz ,

thanks for taking the time to respond!

adding a "last chance" handler w/ the appropriate rank does the job!

totally agree w/ you that making Rocket consistent in its treatment of invalid requests so it returns 400 instead of 404 (which in REST based services carries a different meaning) is the better/right solution.

unfortunately however i do not have the time to submit a PR for this any time soon.

i'll close this question w/ this comment and leave you the option to raise this issue as a bug.

thanks again for your time + effort.