Improve URL handling with support for trailing slashes

[ljbw]

Trailing slashes in URL are legit: https://developers.google.com/search/blog/2010/04/to-slash-or-not-to-slash

However the workaround for this package is pretty ugly: https://medium.com/@elbijay/trailing-slashes-for-inertia-and-laravel-74718fae51e2

Not only that, but the above solution calling setContent will double the request rendering. Without this code, only one view and one http client is created for each request.

This PR improves URL handling to properly preserve trailing slashes in URLs, which is important for SEO and compatibility with certain routing configurations. It also ensures proper handling of proxy prefixes with trailing slashes (which is how this bug was introduced originally)

EDIT: Hopefully this doesn't decrease the chances that this will get merged, but I added a second commit to solve this PR. Since the logic for determining the URL is now in it's own function, it is much easier to write clean code for each of these situations.

[pascalbaljet]

Thanks for this! I reverted the urldecode part as discussed in #663; we need to find another solution there. I've also refactored back to using:

Str::start(Str::after($request->fullUrl(), $request->getSchemeAndHttpHost()), '/');

As I don't want to revert the changes made in #592. Your new tests still passed with these changes!

[RobertBoes]

@pascalbaljet Also commenting this here for visibility. I believe this introduces a significant breaking change.

Laravel itself does basically everything without trailing slashes. For example, if you use a paginator, the links it'll generate are without a trailing slash. Redirects are done without a trailing slash. route('name') would generate a URL without trailing slash. Currently, Inertia will always use an URL without trailing slash, so this actually helps mitigate an incorrect webserver setup. This means Inertia follows how Laravel does URL generation. With this PR, more inconsistency is introduced.

[harryqt]

With this PR, more inconsistency is introduced.

I don't think so.

[jorqensen]

which is important for SEO

In your own blog post, you write:

For SEO purposes, it doesn’t really matter which way you go, but you should be consistent.

So I don't really follow the argument for SEO. Also as @RobertBoes mentioned, this seems to battle how URL generation in Laravel works, for things like route(). Shouldn't the Laravel adapter follow Laravels conventions for consistency?

I appreciate the attempt to solve #663 though.

[ljbw]

Thanks @pascalbaljet I really appreciate the support. I was careful about not disturbing the changes in #592 with this code but your solution works as well, so no complaints.

It appears that others are worried that this PR will make trailing slashes the standard. It will not - all this PR does is make it possible to use them if you need to, without that very ugly and expensive workaround mentioned in the description. If your URLs don't have trailing slashes, then they'll be returned without them. If your URLs do have trailing slashes, they will now no longer be stripped. Don't throw around claims of breaking changes without backing them up with unit tests, it's really not helpful.