The usage of the `&str` type is potentially misleading. about rocket

[sgrif]

As mentioned, I think that considering a documentation bug would be a major mistake. It sets up the expectation that everything could have hidden gotchas in the docs. Most people will just try what they expect to work, which may or not make it obvious to them what is happening. This is extremely subtle behavior that is not made at all explicit by the API

I think a much better approach would be to provide a Raw type which the user can use to request undecoded request data.

[SergioBenitez]

I've reconsidered my position.

Here's the design I'd like to move to: Add a new type &RawStr, that's used anywhere an &str is used now. The type should act like an &str in all possible regards. Furthermore, it should expose convenient methods like .url_decode() and .html_escape().

[Bobo1239]

I fully support sgrif's arguments. I'm going to use the framework for a toy project and this is definitely something I wouldn't have expected. A Raw type as suggested seems like a much cleaner solution.

[liigo]

Keep in mind 'Principle of Least Surprise'.
I was surprised by this issue(feature).

[SergioBenitez]

This is now implemented! It was implemented across a few commits, but primarily in 709acf1, 0c44e44, and f5ec470.

[SergioBenitez]

This is by design. You can use an &str if you're okay with the raw data for whatever reason, or a String and pay the allocation + verification costs. The issue here is really one of documentation. It seems that I missed documenting the provided implementations and providing a cautionary tale, as there is for FromParam.

[sgrif]

I also didn't realize that the same behavior occurred in FromParam. I would hope this API decision will be reconsidered. In general I think most people will assume that str and String are roughly interchangeable, as that's the expectation that is set up by the entire Rust ecosystem. A note somewhere in the docs is not a great way to communicate that behavior, especially with a strong type system that can be used for communication.

[mike820324]

@SergioBenitez
While I'm playing with this issue, I'm wondering, is it possible to just add a new public trait UrlDecoder and implement the trait for the &str.

Now the user only need to do is import the UrlDecoder trait and call the url_decode function of type str.

[mike820324]

Moreover, we can also implement the UrlDecoder trait for String type, and hence reduce some of the common logic in

• https://github.com/SergioBenitez/Rocket/blob/master/lib/src/request/param.rs#L213
• https://github.com/SergioBenitez/Rocket/blob/master/lib/src/request/form/from_form_value.rs#L170