Text input with leading slash can cause unexpected 400 errors

An interesting report came in today, some short autocomplete queries return an unexpected 400 error with a leading slash (/).

Some examples that are broken:

/v1/autocomplete?text=/cali
/v1/autocomplete?text=/colo
/v1/autocomplete?text=/brook

Some examples that work:

/v1/autocomplete?text=/broo
/v1/autocomplete?text=/asdf

In all broken cases, the parsed_text.subject property is just the slash:

"query": {
      "text": "/brook",
      "parser": "pelias",
      "parsed_text": {
        "subject": "/",
        "locality": "brook",
        "admin": "brook"
      },

It looks like whether or not the input was parsed as a subject will determine if this bug manifests or not, but maybe we want to fix it elsewhere, like by removing leading slashes?

Start at the autocomplete API entry point and trace how a leading slash becomes parsed_text.subject and can produce a 400 response. Reproduce the linked /cali, /colo, and /brook examples alongside the working cases; done means leading-slash autocomplete queries no longer fail unexpectedly and parsing remains correct.