Trailing slashes became significant and my project doesn’t work anymore

[strowbeary]

Hello !
I’m using the master branch and have bugs with the way trailing slashes are handled when rocket try to find the route that match with the request uri.
It's a problem I didn't have before with the rc.3 and I'm worried for the next release to introduce bugs in a lot projects using rocket.
Is there any tips to adapt actual code to the new matching conditions ?

For example my homepag, defined as #[get("/")] and mounted with /org/premiere prefix, will only match when the request uri is /org/premiere/ and not /org/premiere like before.

[SergioBenitez]

This isn't a bug, but we have changed the way route paths mount and match on master to be more consistent, precise, and ultimately correct. See #2533 (comment) for how mount points and route paths interact. The gist is that if you want a get("/") mounted at /foo to be visible at /foo, then mount it to "/foo" and not /foo/. You could also consider using the the URI normalizer.

PS: I am very worried about the breakage this week cause and am exploring a manner in which we can introduce this change in such a way that it can be adopted piecemeal.

[SergioBenitez]

On our side, the work required to adapt to the new algorithm is enormous.

We wrote our uris without trailing slashes most of the time and we use Redirect::to(format!(...)) to redirect between the pages.

Using format! is unequivocally a mistake. If you ever change a route path, your redirect will break. I would advocate for using uri! irrespective of your issues here.

To adapt we have to add trailing slash to most of our routes, make corresponding changes to the view templates, and transform all the bad redirections to use uri!() macro.

No this isn't true at all. You can now choose between trailing slashes and not - something you couldn't do before - at the cost of needing to be explicit about which one, or choosing both and mounting twice. You also don't need to use uri!, though it's obviously the better choice, you just need to make sure those URIs are correct.

Besides fixing your formats, which where arguably incorrect to begin with, the main change you need to make is to ensure that your mount points don't end with a /. That should take care of 90% of the conversion. The rest should be covered by using the normalizer. And if it it's not, that's a bug. The total amount of work should be minimal.

I don't blame Rocket's changes, we did badly since the beginnning

I talked with my team and we thought of something.

You could be writing a recommandation on how to write the routes uris to be correct with the new match algorithm and explain that the uri normalizer is here to make the transition less painful.

Yes, this is definitely the plan. Actually, the plan is:

1. Not include these changes in the 0.5 release. The 0.5-rc branch already excludes these changes, and I would advocate for using that branch in the interim.
2. Make the router user-pluggable, with the default set to this new router and a second included router that works like the old one.
3. Deprecate the old router in a major release while keeping it the default.
4. Change to the new router in the next major release, but keep the old one as an option.

[strowbeary]

Ok thank you for the advices, i'm using the master branch because of a probleme with form validation with custom validators with the rc.3 (we discussed about that in an issue earlier)
I'll look after the next release.
Actually we chose to solve our problem with a temporary solution. the only bug that remain is the route mounted as #[get("/")] but i changed the redirections and links to that route with the required trailing slash (even with the normalizer fairing mounted).

[SergioBenitez]

Ok thank you for the advices, i'm using the master branch because of a probleme with form validation with custom validators with the rc.3 (we discussed about that in an issue earlier)

I'll look after the next release.

Actually we chose to solve our problem with a temporary solution. the only bug that remain is the route mounted as #[get("/")]

Can you tell me more? What's the mount point, what's the route, and which effective path is Rocket generating? How did it differ from what you'd expect? The former two you can see in code (at the mount point and route delectation) and the latter should be in the console log. If you could provide this trio of info, it'd be very helpful. If there's a bug, I'd like to squash it.

[strowbeary]

The path generated by Rocket is
/org/premiere/

I mount the route as following:

rocket.mount("/org/premiere", routes![home])

And my route is declared as

#[get("/")]
async fn home() -> RawHtml<String> {
    ...
}

[SergioBenitez]

Are you sure this is what's happening? I just tried this exact thing:

#[launch]
fn rocket() -> _ {
    #[get("/")] fn home() {}

    rocket::build().mount("/org/premiere", routes![home])
}

And it works exactly as expected:

📬 Routes:
   >> (home) GET /org/premiere
[...]
🚀 Rocket has launched from http://127.0.0.1:8000
GET /org/premiere:
   >> Matched: (home) GET /org/premiere
   >> Outcome: Success
   >> Response succeeded.