Case insensitive short links.

[AndiCui]

Summary

We use the link shortener to make readable link for Google Form etc., so that we can put the link in places like Instagram posts or PowerPoint presentations where the link is not clickable for users. Something like example.com/lecture-feedback instead of something like forms.gle/aCqGXMZNuW4kbJn79. (Therefore, the shortlink is not necessary shorter, but more usable.)

The problem is that if users do not realize that they are not dealing with a link shortener, they will assume that the link is not case sensitive. I think a case insensitive mode either for a link or server-wide would be really cool.

---

Notes from maintainer to track progress and discoveries

Case-insensitive considerations:

• New env var/config option: SHORT_URL_MODE='strict'|'loosely' -> Defaults to 'strict' for BC
  • strict: Custom slugs and short-codes are matched strictly, with uppercase and lowercase taken into consideration
  • loosely: Custom slugs and short-codes are matched loosely
• When mode is loosely
  • Shlink should convert custom slugs and short-codes to lowercase (even multi-segment slugs)
    • HTTP: Via middleware
      • This could be done in a way that applies to any endpoint, including REST ones.
        However, this is tricky and has a lot of implications. It's probably better to do it only on the short URL, which is the only route end-users can visit.
    • CLI: TBD
      • With the comment above, this is not needed finally
  • Shlink should do a case-insensitive match to the database
    • Again, only for short URLs (+ QR code and pixel action)
  • New short-codes should be generated just with lowercase, for consistency
• Warning! Shlink will not check already created short URLs. If this value is changed later in time, the wrong short URL might resolve if more than one exists with the same case-insensitive short-code/slug

[acelaya]

Hello @AndiCui

Enabling a case insensitive mode would have more side effects than it looks like, and it would be easy to end up introducing some bug by accident.

Since I see this a bit of an edge case, I'm afraid I have to leave it with a very low priority.

I will leave the ticket here, and if enough users react to it, I will reconsider it.

[es-sam]

This issue has been closed for quite a while but did anyone find a workaround? For us this requires entering in multiple variations of a slug every time and is quite tedious (myspecialevent, MySpecialEvent, Myspecialevent, etc.)

[jonathandhn]

I'm also stuck with that. Coming from yourls, I didn't see it coming.

[trialsin]

To me, case insensitivity it is a very important feature too.

[trialsin]

Would be nice to have a option to make short codes to be generated only in lower case or upper or mixed
Something like lastpass password generator would be nice:

[JustSleightly]

Just leaving my comment here for another +1 to case insensitivity in shortlinks (not the generation like the previous comment but the original post)

[acelaya]

I wasn't going to implement case-insensitive short URLs, because there's a lot of things that could go wrong, but it has been requested a couple of times during the past years, so I have finally done it. I hope I don't regret it 😅

It's done in a slightly naive way, not covering all the edge cases, and with the only purpose that a short URL can be matched regardless of the use of uppercase or lowercase.

The way it works is by providing a new config option, SHORT_URL_MODE, that can be strict or loosely. Strict is the default value, and it makes Shlink work as it has been so far.

When loosely is set, the next things happen:

• Shlink will no longer generate short codes with uppercase letters. Only lowercase and numbers will be used in the alphabet.
• When providing a custom slug, Shlink will lowercase it, so if there's a URL with aaabbb and AaaBbb is provided, it will throw an error saying it already exists.
• When a short URL is visited, the short code/custom slug will be matched loosely, meaning AaaBbb will match an existing URL with aaabbb short code.

Things that are not covered:

• Already existing short URLs: If this option is set to loosely on an existing Shlink instance which already has "conflicting" URLs, the matching might not work as expected. You need to take care of solving those conflicts manually, but this is most probably an edge case.
  Other than that, it should continue working as expected.
• Loosely checks are done only for "public" URLs (short URLs, QR codes and email tracking). REST API endpoints do strict matches no matter what.
  I don't expect a major impact here, as those endpoints are never manually consumed.

I will release Shlink 3.5.0 in the next hours, including this feature. Feel free to report any issues found.