Links with a dot are not processed by turbo

[silva96]

We have links in our platform that are user profiles like this:

domain.com/users/some.username

Whenever you click on those links, a normal request is made instead of a turbo request.

Is there any way to fix this? (I don't want to write a stimulus "link_controller#click" that calls Turbo.visit if it can be fixed from turbo side)

Thanks!

[terracatta]

If anyone else was reading this issue and asked themselves "are periods even allowed in the path?", apparently they are.

[brunoprietog]

I have the same issue, it would be nice if it could be solved directly from turbo.

[silva96]

If anyone else was reading this issue and asked themselves "are periods even allowed in the path?", apparently they are.

Yes, instagram does it all day https://www.instagram.com/ruby.tuesday/

[tleish]

TLDR: Turbo can handle periods, as long as the URL doesn't end in a way that suggests the URL is NOT an html page.

DETAILS:

Links with dots are via turbo:

• domain.com/users/some.username.html => fetched by turbo
• domain.com/users/some.username/ => fetched by turbo
• domain.com/users/some.png => skipped by turbo
• domain.com/users/some.username => skipped by turbo

Note in the instagram example, the URL ends in "/", indicating it's a directory

Turbo checks to see if a url is a directory or an html page

function isHTML(url) {
  return !!getExtension(url).match(/^(?:|\.(?:htm|html|xhtml))$/)
}

Turbo skips non-html links (e.g. .json, .svg, .jpg, .png, etc).

  locationIsVisitable(location: URL) {
    return ... && isHTML(location)
  }

Any suggestions on how the javascript could determine if the url is an html page vs a file with a .username extension?

One possible option I can think of is to add capability to turbo to support an html attribute which tells turbo "treat as an html link, even if it doesn't look like one".

This option requires a developer to write additional code, so you could just append / or .html to the end of URLs with dots and make it work today.

[silva96]

Thanks, we solved it adding trailing_slash to the route.rb