Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How can I remove the trailing slash in pretty URLs? #492

Closed
unor opened this issue Sep 8, 2014 · 10 comments
Closed

How can I remove the trailing slash in pretty URLs? #492

unor opened this issue Sep 8, 2014 · 10 comments
Labels

Comments

@unor
Copy link

unor commented Sep 8, 2014

IIRC, with v0.11 pretty URLs had no trailing slash (as it’s still documented in the example on Pretty URLs). With v0.12, a slash gets appended.

How can I, globally, get back the old behavior?

@spf13
Copy link
Contributor

spf13 commented Sep 9, 2014

After a long debate, we discovered that the definitive correct behavior for a URL representing a directory was to end in a slash. Personally I liked the look of the nonslash ending urls better, but a compelling enough case was made to change my mind. Ending in a slash works on every web server out of the box without any additional configuration. Consequently we have not enabled a way to go back to the previous (erroneous) behavior.

If there is a compelling enough reason to restore the old behavior as a configurable option it wouldn't be hard to do, I'm just not aware of one.

@unor
Copy link
Author

unor commented Sep 9, 2014

I don’t have any experience with servers having a problem with trailing-slash-less URLs, so can’t say anything about this point. (Work fine for me, but I’m always using Apache.)

Personally, I don’t want to have URLs that end with a slash, and shouldn’t it be possible to achieve those URLs with Hugo, it would be a no-go for me. But I guess I’m not the average user, as I’m really picky about URLs ;-)

A compelling (though I don’t know if it’s compelling enough) reason would be canonical URLs: a site that is already published with trailing-slash-less URLs would be well-advised to keep its URLs. Stable URLs are an important and good thing, for various reasons (SEO, canonical link type, vocabulary URIs used by RDF/Microdata, user bookmarks, cache, etc.), and in my opinion, an upgrade of a tool (CMS / static site generator) should never result in changed URLs.

That said, personally I’d love to have a setting to choose which URLs should be used. But maybe there is good solution/workaround that would work even now? Maybe via configuration settings, if necessary even manually for each content? Or would the menu then still generate URLs with trailing slash?

@adrinux
Copy link

adrinux commented Sep 10, 2014

@unor Surely the slash/no-slash makes no difference as far as the web server is concerned? AFAIK no URLs will break with this behaviour, previously published or otherwise. I'm sure everyone would agree about keeping URLs consistent, just seems irrelevant to this. Maybe I'm missing something...

@unor
Copy link
Author

unor commented Sep 10, 2014

@adrinux They don’t necessarily break in the 404 sense (as servers seem to correct the URL; but I guess this might depend on server config), but in the canonical sense:

With v0.11, I had the URL http://example.com/me#i.
With v0.12, it automatically became http://example.com/me/#i.

When user agents visit http://example.com/me#i, the URL changes to http://example.com/me/#i.

@whereisaaron
Copy link

@unor @adrinux the trailing slash on the path is supposed to be there, many web servers have built-in behaviors to 'auto-fix' missing trailing slashes by internally redirecting/rewriting in the missing trailing slash. More 'pure' servers without this behavior break, though you can often add rewrite rules to add the missing slashes.

So hugo now does the 'right thing' (tm) by default and yields the most correct and compatible canonical URLs.

If you are picky about URLs, then you should demand that they include the trailing slash :-)

That said, people who can ensure their web server will add slashes could have an hugo option to remove them, if @spf13 were persuaded. I've just argued it should have a pejorative name, like '--break-urls-by-removing-trailing-slashes'. So people who really want to can do it, but at least they know they are doing something arguably incorrect.

@spf13 spf13 added the question label Oct 19, 2014
@twistor
Copy link

twistor commented Dec 11, 2014

I can understand how making urls work by default on most webservers is a nice thing, but claiming that one behavior is more correct than the other is ridiculous. Urls don't need to convey any information about the directory structure of the server. That's an implementation deal that users should not have to deal with.

Even if one argued that listing type pages should end in a slash, making every URL end in a slash is obviously semantically incorrect. So while the current behavior is convenient, it carries no more correctness than the alternative.

@whereisaaron
Copy link

Hi @twister, you're absolutely right that the motivation here is to make hugo output compatible with more web servers 'out of the box'. The rest is a flame-bait argument about standards and implementations :-)

No one, I think, is suggesting every URL should end in a slash, only those that are intended to invoke the directory, default document behavior. And then, only as the default setting, as that is compatible with more web servers. If your preference is no trailing slashes for default document pages and your particular web server supports that, then go for it, have no trailing slashes.

And now on to the argument material...

Without a trailing slash a URL like 'http://mysite.com/foo' is arguably ambiguous when mapped to a file system. (Which is a significant concern for static website.) Does it mean the page 'foo' or does it mean the page 'foo/[default doc or dir listing]'. What happens on file systems where you can have simultaneously have a file 'foo' and a directory called 'foo', which page should the web server return?

Some web servers have a particular behavior to handle this ambiguity, where they check for the page 'foo' first and if they don't find it, they automatically and internally add the slash and try again. Other web server implementations don't do that extra slash-adding behavior, or at least no without extra configuration, so they only look for a file 'foo' and if not found, return a 404.

@bep
Copy link
Member

bep commented Feb 2, 2015

For further discussion, use http://discuss.gohugo.io/

@keaeriksson
Copy link

Hi, if you are using AWS to host your Hugo site I wrote a blog post on how to remove trailing slashes using S3, CloudFront and Lamdba@Edge here: https://mocki.io/hosting-a-hugo-site-on-aws-s3-and-cloudfront.

@github-actions
Copy link

github-actions bot commented Feb 5, 2022

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 5, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

7 participants