How do you use HttpRequest data?

[ttfkam]

What is a simple code example that prints out the contents of a header value with actix-web?

#[get("/header")]
async fn print_header(req: HttpRequest) -> impl Responder {
    // This is fine
    let some_header = req.headers().get("x-some-header").unwrap().to_str().unwrap();

    // This triggers a compilation error
    some_header
}

This snippet brings complaints from the compiler about lifetimes and req getting dropped prematurely. Unfortunately there's nothing in the docs in the way of examples for this fairly common use case. Nothing in cursory Google searches either that demonstrate a simple code example.

[fakeshadow]

This is how lifetime works in Rust.

Your some_header is referencing the HttpRequest which is owned by your print_header function.
When the function is end HttpRequest is dropped and it's memory is not valid anymore.

If you are still confused with how Rust's borrow checker work it best to start with The book

For this specific case, some_header is a &str and it needs to be a String to return it. So use .to_owned().

[ttfkam]

I realize my lack of experience with Rust was the issue, but "RTFM" is rarely a sufficient answer. Sometimes a code example works better than a link to an entire book where a newcomer may have previously seen but not absorbed. For the sake of the next person searching for an answer and only finding "that's not how Rust works," here's the complete code snippet that compiles:

#[get("/header")]
async fn print_header(req: HttpRequest) -> impl Responder {
    // Note the .to_owned() at the end, which converts to the str reference owned by req to a String owned by print_header
    // and therefore usable.
    let some_header = req.headers().get("x-some-header").unwrap().to_str().unwrap().to_owned();

    // Since this is owned by print_header now, ownership can be transferred to the calling context.
    some_header
}

For the record, to_owned() never appears in the Rust Book and only twice in Rust by Example, where the contexts that are ambiguous. While it does appear in API results, one would only see it if they already knew what they were looking for. Chicken, meet egg.
https://www.google.com/search?q=site%3Adoc.rust-lang.org+to_owned

[ttfkam]

Thank you for the to_owner() hint. You saved me a great deal of time as I would not have found it easily otherwise.

[fakeshadow]

Yea Ikr. People would complain even when you try to help.
https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html#dangling-references
This session shows exactly what your code does. It's more important to know the rule first than just some API to get ownership. You can always check the doc for std APIs.(Because there are many of them and you would hit some of them sooner or later)

[ttfkam]

Thank you for the more specific link. I saw the page, but it didn't click for me how it applied. I may have been either impatient and/or slow on the uptake.

I guess I should clarify. I knew that req was not owned by the current context. I knew that the compiler could not guarantee that its resources would not be deleted before the async function had returned. The issue at hand was that even with your book link, there is no reference to to_owned(). Knowing about a principle and being able to translate that to the correct syntax addressing that principle are often two very different things, especially for beginners. One of the reasons I asked the forum was to get an expert's opinion rather than simply cobble together something that happens to work.

Again, I am fully aware that my lack of experience with Rust was the root of the problem. I acknowledge that. Life's a learning curve, and I am on the low left hand side of that curve. Normally someone need not be an expert in a language (or even intermediate) to output headers in most web frameworks. I'll see about writing a PR with an example accessing HttpRequest so that future questions like this can be avoided. Cheers!

[fakeshadow]

Yea. It's my bad to not including an easy answer and our maintainer added that.