Throw error if long URLs are provided without schema

[codaamok]

Summary

When creating short codes with the REST API, e.g. createShortUrl, long URLs without a schema are allowed and Shlink redirects them to the default domain where the longUrl is appended to the URI. Same is true for the new deviceLongUrl.[android|ios|desktop] request properties too.

For example, If the value bbc.co.uk is given for longUrl, Shlink redirects to http://<default_domain>/bbc.co.uk instead of http(s)://bbc.co.uk.

Example request:

curl -X 'POST' \
  'https://domain/rest/v3/short-urls' \
  -H 'accept: application/json' \
  -H 'X-Api-Key: x' \
  -H 'Content-Type: application/json' \
  -d '{
  "longUrl": "bbc.co.uk",
  "deviceLongUrls": {
    "android": "bbc.co.uk",
    "ios": "bbc.co.uk",
    "desktop": "bbc.co.uk"
  },
  "customSlug": "bbc"
}'

There are two solutions to this request:

• Throw an error if longUrl is given without a schema. Shlink web UI has validation in the form so this implementation would match that behaviour
• Assume the user means http:// in this situation and use this in the response

If it were me, I'd probably go with option 1 on the basis if you're creating short-url's via REST API then you should a) know what a schema is and why it's important to specify and b) can handle errors in code. Plus it'll follow the functionality of the web UI.

Although option 2 allows for an easier user experience.

[acelaya]

This is a bug. Option one is how it should be working.

I even remember having to tweak this to support deeplinks, some years ago. Perhaps that was what broke this.

[acelaya]

I have been re-considering this for a couple reasons.

• First, I seemed to be relying on this on tests a lot, when building dummy data, which has forced me to refactor a lot of stuff 😅
• Second, I realized that changing this behavior is technically speaking, a breaking change.

The first problem was caused by me. I have had to rewrite many tests, but such is life. It's done now.

Regarding the second problem, I have decided to still go with it because a) most of the people use shlink-web-client, which already validates URLs, and b) the resulting short URLs when the schema is not provided are completely broken, so I very much doubt anyone was actually relying on this behavior.

That said, since Shlink has to support different types of URIs (including deeplinks and such), I have decided to go with a simplistic approach, which is just validating that provided URL has a schema of any type. So values like foo or bbc.co.uk are no longer considered valid, but http://foo, https://foo, http://bbc.co.uk, ftp://foo or market://foo will be considered valid.