TO API allows creation of a profile with spaces

[ericholguin]

I'm submitting a ...

• bug report
• new feature / enhancement request
• improvement request (usability, performance, tech debt, etc.)
• other

Traffic Control components affected ...

• CDN in a Box
• Documentation
• Grove
• Traffic Control Client
• Traffic Monitor
• Traffic Ops
• Traffic Ops ORT
• Traffic Portal
• Traffic Router
• Traffic Stats
• Traffic Vault
• unknown

Current behavior:

When making a POST request to /profiles and the name key is set to a string value that contains spaces, the response returned is:

HTTP\1.1 200 OK
{
    "alerts": [
        {
            "text": "profile was created.",
            "level": "success"
        }
    ],
    "response": {
        "id": 632,
        "lastUpdated": "2019-12-17 17:55:34+00",
        "name": "test Profile5",
        "description": "Test Profile",
        "cdn": 2,
        "routingDisabled": false,
        "type": "UNK_PROFILE"
    }
}

The profiles/name/{{name}}/copy/{{copy}} endpoint is also affected by this bug.

This also affects Traffic Portal when clicking on Clone Profile, the user can input a profile name with spaces and it will create the profile with no errors.

Expected / new behavior:

Should return:

HTTP\1.1 400 Bad Request
{
    "alerts": [
        {
            "text": "'name' cannot contain any spaces",
            "level": "error"
        }
    ]
}

Minimal reproduction of the problem with instructions:

Anything else:

[ocket8888]

Why do you expect that a profile name cannot contain spaces?

[mitchell852]

well apparently TP does not allow spaces but the TO API does.

Not sure what the right answer is tbh.

[ocket8888]

Oh, well then is the bug in TO or TP? Are Profile names supposed to contain spaces? Is there a production environment that has Profiles with spaces in their names?

[mitchell852]

in practice, i've never seen profile names with spaces.....but not really sure if it would hurt or not.

[ocket8888]

I think Profile Names ought to be able to include spaces. Even though it really only makes sense to actually give them names meant for humans to read once we stop reading them with machines and doing automatic things based on glob patterns and regular expressions.

[ocket8888]

Added "bug" label because no matter what's decided, TP isn't currently accurately reflecting TO's API restrictions, and is in fact inconsistent within itself.