Using `--alias` with invalid characters "slugifies" the string in the shell but sends the characters unchanged to `Deploy.subdomain_alias`.

[overlordofmu]

- Do you want to request a feature or report a bug?

A bug.

- What is the current behavior?

When using --alias to create a custom subdomain for a deploy, characters which would be invalid for a domain name are "slugified" in the shell URL but the database is still getting the unmodified string.

- If the current behavior is a bug, please provide the steps to reproduce.

Here is an example deploy:

$ netlify deploy --alias="not/working"
Deploy path:        /Users/me/data/git/overlordofmu/netlify-cli-manual-deploys/public
Configuration path: /Users/me/data/git/overlordofmu/netlify-cli-manual-deploys/netlify.toml
Deploying to draft URL...
✔ Finished hashing 8 files
✔ CDN requesting 0 files
✔ Finished uploading 0 assets
✔ Deploy is live!

Logs:              https://app.netlify.com/sites/netlify-cli-manual-deploys/deploys/5efaea211010bad6650a7350
Website Draft URL: https://not-working--netlify-cli-manual-deploys.netlify.app

If everything looks good on your draft URL, deploy it to your main site URL with the --prod flag.
netlify deploy --prod

However, if I check the actual content of Deploy.subdomain_alias it is "not/working" instead of not-working. The URL in the deploy above does not work: https://not-working--netlify-cli-manual-deploys.netlify.app

- What is the expected behavior?

That the same "slugified" string shown in the shell command output be used for the subdomain_alias value and the given URL in the shell will then work.

- Local Environment Information

$ netlify version --verbose
────────────────────┐
 Environment Info   │
────────────────────┘

  System:
    OS: macOS 10.15.5
    CPU: (12) x64 Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
  Binaries:
    Node: 12.18.0 - ~/.nvm/versions/node/v12.18.0/bin/node
    Yarn: 1.22.4 - /usr/local/bin/yarn
    npm: 6.14.4 - ~/.nvm/versions/node/v12.18.0/bin/npm
  Browsers:
    Chrome: 83.0.4103.116
    Firefox: 77.0.1
    Safari: 13.1.1
  npmGlobalPackages:
    netlify-cli: 2.54.0

netlify-cli/2.54.0 darwin-x64 node-v12.18.0

[overlordofmu]

Follow-ups

https://community.netlify.com/t/netlify-cli-alias-urls-not-found/17831

[erezrokah]

This is an issue with our API, I opened an issue for it internally. It looks like the CLI should not slugify the branch argument when invoking the deploy API call.

[HugoGranstrom]

I've hit this issue now as well but regarding upper-case letters. --alias nicename works while --alias niceName doesn't. What are your suggested method to deal with this at the moment? I want to use aliases based on branch names, is there any certain transform I can apply to them to make them work? Slugify?

[overlordofmu]

@HugoGranstrom, "slugify" meaning "to take a string and make it suitable to be used as a slug".

The definition of "slug" itself can be found here: https://en.wikipedia.org/wiki/Clean_URL#Slug

Our slugs (which is also true of most but not all slugs) are always lowercase. It won't be possible to use mixed case slugs. We could request a feature request for this but I'm 100% certain that our service will never be able to support mixed case slugs. In other words, I'm 100% sure the feature request will never get made.

So, it may be helpful to ask: "Why am I 100% sure we won't support mixed case slugs?"

I'm sure because, to support them, we would need to differentiate between cases at the DNS level. We would need to treat nicename--example.netlify.app and niceName--example.netlify.app as two different domain names. However, DNS itself ignores case. Because DNS itself lacks support for case-sensitivity, we would not be able to support mixed case slugs.

To summarize, a mixed case slug won't happen because the slugs get used for subdomains and DNS has no concept of uppercase or lowercase.

Also, please be warned that the --alias option is intended to be used as a single use alias. If you reuse the same alias for a future deploy those aliases are not branch deploys and branch deploy features will not work for those deploys. The only way to use branch subdomain features currently is to do the build at Netlify.

There is an open feature request for true branch subdomain support with manual deploys here: #1572.

[HugoGranstrom]

@overlordofmu Thank you sincerely for your answer :D

I'm sure because, to support them, we would need to differentiate between cases at the DNS level. We would need to treat nicename--example.netlify.app and niceName--example.netlify.app as two different domain names. However, DNS itself ignores case. Because DNS itself lacks support for case-sensitivity, we would not be able to support mixed case slugs.

If this is the case, why isn't this limitation documented anywhere? I expected Netlify CLI to at least tell me that something was wrong about my alias if it doesn't fit the template instead of just giving me a broken link, don't you agree? Some solution is to be expected to this at least, for example fixing the bug this issue was opened for so that the printed and deployed URLs actually match (both are the slugified string for example) (Especially since it has been a year now since this was found and I'm certainly not the only one who has gotten headaches trying to figure this out).

Also, please be warned that the --alias option is intended to be used as a single use alias. If you reuse the same alias for a future deploy those aliases are not branch deploys and branch deploy features will not work for those deploys. The only way to use branch subdomain features currently is to do the build at Netlify.

I'm totally fine with it overwriting the last instance and I have no need for branch deploy whatever that is, I'm just deploying a prebuilt directory anyway and I just want a human-readable URL. But because of this, I'm just using the the commit hash for now :)