parsing a string into a uri according to schema?

[hesxenon]

Assuming we have something like

#[put("/foo")]
fn put_foo() {
  todo!("should redirect to foo entry with generated id")
}

#[get("/foo/<id>")]
fn get_foo(id: &str) {
  todo!("should show foo with <id>")
}

how would I test that put_foo actually includes a Location header with a value that matches the template for get_foo?

I'm kinda new to rust as a whole but am loving it so far (shocker, I know ;) ) so sorry if I'm missing something obvious here.

[martynp]

Firstly there is a redirect responder already:

https://api.rocket.rs/v0.5/rocket/response/struct.Redirect

use rocket::response::Redirect;

#[get("/hello/<name>/<age>")]
fn hello(name: String, age: u8) -> String {
    format!("Hello, {} year old named {}!", age, name)
}

#[get("/hi/<name>/<age>")]
fn hi(name: String, age: u8) -> Redirect {
    Redirect::to(uri!(hello(name, age)))
}

#[get("/bye/<name>/<age>")]
fn bye(name: String, age: u8) -> Redirect {
    Redirect::to(uri!("https://rocket.rs/bye", hello(name, age), "?bye#now"))
}

For testing there are probably two main approached, first you could set up a 'system' test and use something like Robot Framework or Cucumber to test things are working.

The other option would be to use the local client and inspect the response (https://api.rocket.rs/v0.5/rocket/local/). The local client would allow the test to live with the code.

[hesxenon]

I knew about the redirect responder :) but that also has to set that header and yes, I wanted to use the local client, as outlined in the testing section of the docs. So the main problem I have is "how to parse a string according to a template", something like "Uri::parse_into(&location_header, details.route.uri)"

…

On Fri, Jan 2, 2026, 18:06 Martyn P ***@***.***> wrote: Firstly there is a redirect responder already: https://api.rocket.rs/v0.5/rocket/response/struct.Redirect use rocket::response::Redirect; #[get("/hello/<name>/<age>")]fn hello(name: String, age: u8) -> String { format!("Hello, {} year old named {}!", age, name)} #[get("/hi/<name>/<age>")]fn hi(name: String, age: u8) -> Redirect { Redirect::to(uri!(hello(name, age)))} #[get("/bye/<name>/<age>")]fn bye(name: String, age: u8) -> Redirect { Redirect::to(uri!("https://rocket.rs/bye", hello(name, age), "?bye#now"))} For testing there are probably two main approached, first you could set up a 'system' test and use something like Robot Framework or Cucumber to test things are working. The other option would be to use the local client and inspect the response (https://api.rocket.rs/v0.5/rocket/local/). The local client would allow the test to live with the code. — Reply to this email directly, view it on GitHub <#2982 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACOHZTRXLZKD22MSW5NDHJD4E2QQVAVCNFSM6AAAAACQRE3H36VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMZZGI2TGOA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[martynp]

So a simple implementation might look like:

#[macro_use]
extern crate rocket;

use rocket::response::Redirect;

#[put("/foo")]
fn put_foo() -> Redirect {
    Redirect::to(uri!(get_foo(6)))
}

#[get("/foo/<id>")]
fn get_foo(id: u8) -> String {
    format!("Foo is #{}!", id)
}

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

#[cfg(test)]
mod test {
    #[test]
    fn test_redirect() {
        use rocket::local::blocking::Client;
        let client = Client::tracked(super::rocket()).expect("valid `Rocket`");
        let response = client.put("/foo").dispatch();
        dbg!(&response.headers().get_one("location"));
    }
}

This would output:

[src/main.rs:28:9] &response.headers().get_one("location") = Some(
    "/foo/6",
)
test test::test_redirect ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s

In the test itself you could use some regex to check the pattern.

I don't think you could go much further without understanding how the rest of the system works - at which point a system level test may be more appropriate.

You could also use some environment vars which are used for a 'test' mode to set id to an expected value before the test is run.

[hesxenon]

hmmm, a system level test might indeed be a better approach, but then I'd have to setup a whole other thing which I'd like to avoid.

In the test itself you could use some regex to check the pattern.

That's exactly what rocket does internally though, isn't it? Why can't I re-use that same unit?

After digging around in rockets source code it seems that the RouteUri.metadata prop could rather easily be used to do that since that already has the segments of a given path.

We can create typed uris, rocket can parse them internally - so what about something like parse_uri!(get_foo, location_header)?

[martynp]

I think it really depends on what you expect to go wrong - if the question is does the redirect happen correctly then using an independent approach to testing is better.

As a function in the framework I would expect that the redirect and uri generation functions work as expected and then focus testing on the implementation at a higher level.

For belt and braces you could check to see if the tests within the framework are sufficient to validate those features and then submit improvements if they fall short - even if nothing needs to be fixed, more tests are always better.