[Query] Trailing slash doesn't match routes.

[BenJenkinson]

Just a simple one. I tried creating the following route:

Route::get('hello', function()
{
    return View::make('hello');
});

But this route is then only accessible at example.com/hello and not example.com/hello/, which throws a NotFoundHttpException. Obviously, creating the route for hello/ then means the route is no longer accessible at 'example.com/hello'. This is exactly what is supposed to happen, since the route didn't match, but it might not be what is expected to happen.

Type any URL on the Laravel 4 documentation site, absent-mindedly include a trailing slash, and you won't find the page.

This could be a feature when creating RESTful APIs (when a URI resource with a trailing slash is considered different from one without), but for standard navigation it could be a common query; especially since "Pretty URLs" commonly append a trailing slash for neatness.

To avoid this, users could simply define routes twice, in my case, for both hello and hello/.

Route::get('hello', function()
{
    return View::make('hello');
});
Route::get('hello/', function()
{
    return Redirect::to('hello')
});

However, I'm pretty sure doing this for every route for which a trailing slash could be a possibility would be quite annoying. On the other hand, you also wouldn't want to assume and use the .htaccess file to automatically add the slash automatically to all routes.

tl;dr Not sure if bug or feature, and merely a 'gotcha' for new users.

[softlabs-2]

I have been having the same issue when you create Resource Controller using Route::resource('test', 'TestController') and creating the controller using ''php artisan controller:make TestController".

Then when you browse to /test or /test/create or /test/1 it works fine but when you add a trailing slash like /test/ or test/create/ it throws NotFoundHttpException.

Just wondering if this will remain how it is or if it is a bug to be fixed?

[pauljohnston]

I'm also having the same issue, anything with a trailing slash doesn't route and just shows an error.

[franzliedke]

Duplicate content has to be taken into account when handling this. The proper solution, if anything, would be to redirect to one of the two variants (but only if the other one of them is defined).

[taylorotwell]

Just don't use trailing slashes.

[BenJenkinson]

I don't think that's really a solution. Users may use trailing slashes. We may construct our URLs specifically forgoing them, but a user may still type a URL that includes one. We should be able to cope.

Traditionally, the segments of a URL are emulating the folder structure. Where although /example/docs/routing may be a page on the documentation, /example/docs/ is considered the main index of the documentation and it would be reasonable to expect a page to exist there. The URL structure /example/docs would indicate that docs is a page of the example section, when it is actually an index in its own right.

I have found some web services with APIs that insist upon one format over the other, or that use / to indicate whether the RESTful resource returns a single item or a list of items; but I cannot find any public-facing websites that follow the current behavior and do not either serve identical content, or redirect to the preferred URL-format (whether that be with, or without a /).

Even http://laravel.com currently functions in this way, laravel.com/docs/ produces the documentation as well as laravel.com/docs does.

It is of course preferable that a single page does not exist at two different addresses, but at the very least it should redirect from one to the other.

[tomicakorac]

It's possible to fix this using .htaccess, by rewriting or redirecting to url either with or without trailing slash. It's also possible to enable both variants. Although I agree this should be changed so that na url works with or without /$.

[ghost]

Just came across this issue too. Any URL with a trailing slash now returns a NotFoundHttpException since updating to the latest version of L4 this morning.

I'm also of the opinion that Laravel should redirect to one or the other.