clean_urls: true by default?

[kylemac]

I find myself setting this to true every time and others seem to expect it as well. should we just make it default? jescalan/roots#634 (comment)

cc @Jenius @declandewet

[zspecza]

I don't think having it on by default is a good idea, my reasoning is that as a new user to Roots I'd expect the development server to behave as any static site would, i.e. without clean URLs.

[kylemac]

word, thanks for weighing in.

that was my original thinking too. the only reason i'm in the other camp now is since using netlify -- i have no problem that they automatically clean up the URLs. it should be noted that .html urls work too, they just get rewritten to be clean.

in any case, i could go either way

[zspecza]

I think it's important not to tie Roots too closely to Netlify, even if just in discussion, as it might cause confusion and some might get the idea that one is required for the other to work. That's just my thinking of course. Roots is @Jenius' baby so ultimately he'll decide :P

[kylemac]

Point taken

On Thu, Apr 30, 2015 at 8:14 AM, Declan de Wet notifications@github.com
wrote:

I think it's important not to tie Roots too closely to Netlify, even if just in discussion, as it might cause confusion and some might get the idea that one is required for the other to work. That's just my thinking of course. Roots is @Jenius' baby so ultimately he'll decide :P

Reply to this email directly or view it on GitHub:
#24 (comment)

[notslang]

I think that as a server (having nothing to do with roots), it's reasonable to enable "clean urls" by default. The reason why is that file extensions are nearly meaningless in URIs, they're a naming convention used to indicate content-type on file systems which don't support any other method of indicating content-type.

But URIs are implementation-independent and represent resources, not files. They have their own method of indicating what format the data is to be interpreted in (the Content-Type header), and a method for requesting data in a certain format (the Accept header).

A single resource can even be available in a variety of formats. For example, I could request https://twitter.com/slang800 with Accepts: text/html (as a webbrowser does) to get the standard human-readable Twitter UI for my profile. Or I could request https://twitter.com/slang800 with Accepts: application/json if I wanted to get a machine-readable version of all the data in my profile**

This duality wouldn't be possible (or at least wouldn't make any sense) if those URIs had file extensions in them. You'd have to request https://twitter.com/slang800.json with Accepts: application/json and requesting it with Accepts: text/html would error out with a 406... While https://twitter.com/slang800.html would need to be requested with Accepts: text/html and requesting it with Accepts: application/json would error out with a 406. And, of course, the resource we're looking for in both those cases is slang800's twitter profile, not slang800.json's profile.

** Twitter doesn't actually support this because they treat machines as second-class citizens and prevent them from having easy access to public data - preferring to force them to go through their separate API.

[kylemac]

a good point @slang800. thanks for adding to the convo

[jescalan]

Yeah really interesting perspective @slang800, thanks for weighing in here. These are great points from everyone. I think initially I was swinging towards no to defaulting it, but after reading everyone's perspectives I'm now a little more on the yes side.

Why? Because "any other static site" is not really a default, per-se. Any site that goes up must have a server written for it, so it's up to the server how the file extensions are handled, really. It just turns out most static file servers include the file extensions for all files. Our clean url option strips the extensions only for html files, simple because this is a server made specifically for static sites. I see no reason why anyone would ever want the extension on an html file on a static site, which is, as Kyle mentioned, why you switch on clean urls pretty much every time. As long as we have the re-routing of foo.html to foo so there are no breakages with this change, which we do, this seems to me like it would simply make things more convenient for everyone. I can't imagine someone being mad about not having the .html extension on the end, as long as everything still works. And if they have some other weird instance where they are not serving a static site, then they should not be using charge haha.

So I'd go with yes for this. Let's make it happen.