Trailing slash stripped from request.url in loader during client navigation

[richardkall]

I'm using React Router as a...

framework

Reproduction

1. Go to https://stackblitz.com/edit/stackblitz-starters-xvygdk
2. Click the "About" link inside the preview, which points to /about/
3. Notice the missing trailing slash on the rendered request.url.
4. Reload the About page, notice the trailing slash now being appended to the request.url.

System Info

react-router@7.0.2 (app created using `npx create-react-router@latest`)

Used Package Manager

npm

Expected Behavior

• request.url in loader to contain a trailing slash, since that's the URL I'm at.
• request.url behaving consistently no matter if I'm client side navigating or SSR.

Why is this important?
We are fetching data inside the loader, and need to pass the pathname to an API. The API responds differently depending on if certain pages have trailing slash or not (tells the client to redirect etc.). This issue leads to redirect loops and blocks us from migrating to React Router 7.

Actual Behavior

• request.url is missing a trailing slash, although that is the URL I'm at.
• request.url contains a trailing slash during SSR, but strips it during client side navigation.

[ramiroazar]

I can confirm this is still an issue and is blocking us from handling trailing slashes correctly.

[mattbdc]

Can confirm still a problem

[mattbdc]

@ramiroazar Did you find any workaround?

[ramiroazar]

Sorry for the delay, @mattbdc.

In our case, we needed to remove trailing slashes like reactrouter.com, so we opted for the same implementation.

https://github.com/remix-run/react-router-website/blob/main/app/modules/http-utils/remove-slashes.ts#L3

Unfortunately, this still doesn't work when navigating with Link or useNavigate as outlined in this issue, so we've just had to resort to taking extra measures to ensure no internal navigation contains trailing slashes.

[mattbdc]

Thanks, yeah making sure all internal links are safe was my first thought as those that are external will trigger the server-side load where it works correctly. Still nasty as hell.

The unstable middleware means changing signatures everywhere on Hydrogen to use the keys for context - essentially we'd have to eject from being able to follow shopify Hydrogen template, that all said seeing as Hydrogen basically gives us surprisingly very little - doesn't even use search and discovery for example we are currently re-thinking the whole approach.

Update: not sure if the unstable middleware has changed between the above and rrv7, pretty sure we had to opt into keying every bit of context if used even if not threading anything along other than the seeded context, could be wrong

[ramiroazar]

For what it's worth, we've also adapted that same approach to just be a normal function that throws a redirect instead of middleware specifically and using it in the first line of the root loader works effectively the same.

https://github.com/Shopify/hydrogen/blob/ffb3afe63e1d16bf7484b19a45747934a52c5dd7/templates/skeleton/app/root.tsx#L69

[richardkall]

@brophdawg11 Let me know if I can provide anything else to help move this forward. Still a pretty big pain point for us. Thanks! 🙏

[brophdawg11]

The reason for this is that on data requests, we take the path and add .data making it more of a file-like extension which plays nicely with prerendering data files, so both navigating to both /about and /about/ result in a data request of /about.data.

Can you elaborate a bit on your use case? If you just want to ensure trailing slashes exist (or don't exist) on URLs, couldn't you instead do that in a client side middleware for client-side navs?

export const clientMiddleware: Route.ClientMiddlewareFunction[] = [
  ({ request }) => {
    let url = new URL(request.url);
    if (!url.pathname.endsWith('/')) {
      throw redirect(url.pathname + '/' + url.search);
    }
  },
];

[richardkall]

Can you elaborate a bit on your use case? If you just want to ensure trailing slashes exist (or don't exist) on URLs, couldn't you instead do that in a client side middleware for client-side navs?

Our use case is that our GraphQL API treats paths with or without trailing slashes differently. We have a news site where the API responds with different __typename's (page types) depending on which path (variable) we pass in the GraphQL query. Like this:

query PageQuery($path: String!) {
    page(path: $path) {
        __typename
    }
}

Different responses depending on which $path the client sends:

path	__typename
/sport/	SportsSection
/sport	Redirect (to /sport/)
/sport/article-slug	NewsArticle
/sport/article-slug/	Redirect (to /sport/article-slug)

I understand it might not be a common use case, but for us it's critical that the pathname is not modified during the request. Let me know if I can provide more info! Thank you.

[brophdawg11]

It looks like it's just returning redirects to guarantee a trailing slash on the URL in the browser? What's the advantage of letting the GQL server do that (and incurring an additional API call, or 2 in the case of client side navs) versus just doing that in middleware? Then you could just always append the trailing slash (if it didn't already exist) in your loader GQL call knowing that your middleware already ensured the browser URL had a trailing slash.

[richardkall]

It looks like it's just returning redirects to guarantee a trailing slash on the URL in the browser? What's the advantage of letting the GQL server do that (and incurring an additional API call, or 2 in the case of client side navs) versus just doing that in middleware? Then you could just always append the trailing slash (if it didn't already exist) in your loader GQL call knowing that your middleware already ensured the browser URL had a trailing slash.

Thanks for replying!

It's all part of a query returning all data required for that page, I just omitted it in the example. It can respond with all sorts of "page types", such as NotFound etc. Basically the API knows everything about the routing. The client renders what the API responds with, and knows nothing about whether it should be a trailing slash or not.

I’m happy to share more details if needed — including which website this affects. If so, is there a way to provide that information outside this public thread? It’s one of the most visited sites in my country, so I’d prefer not to post it openly.

[brophdawg11]

Nah no detail needed - I think in the simple naive case it seems like a client middleware could fix this specific case but I agree with the more general assertion that a loader URL should not differ between document and client side navs.

We already have a singular special URL for root data requests where we have no pathname to append .data to in /_root.data so I think we can latch onto that idea for trailing slash URLs.

• When the URL is /a/b/c, the data request would be /a/b/c.data
• When the URL is /a/b/c/, the data request would be /a/b/c/_.data

I've got stuff on my plate right now so I'm going to add the accepting prs label to this, so if you or someone else wants to take a stab I'd be happy to help review any PRs!