/v1/characters/ doesn't handle slashes correctly

[emreozcan]

Steps to reproduce:

• Make a GET request to /v1/characters/%2F

Expected response:

[{"character": "/",
  "name": "SOLIDUS",
  "codepoint": "U+002F",
  "uriEncoded": "%2F"}]

Result:
It redirects to /v1/characters with a 307 Temporary Redirect.

Requesting any string that ends with %2F results in a 307 that removes the trailing slash.
/v1/characters/a%2F gets redirected to /v1/characters/a. Expected response:

[
  {
    "character": "a",
    "name": "LATIN SMALL LETTER A",
    "codepoint": "U+0061",
    "uriEncoded": "%61"
  },
  {
    "character": "/",
    "name": "SOLIDUS",
    "codepoint": "U+002F",
    "uriEncoded": "%2F"
  }
]

Any other string that includes %2F results in a 404 {"detail": "Not Found"}.

[a-luna]

Thanks for pointing this out! I've identified a simple fix thanks to fastapi/fastapi/issues/791 (specifically this response by @jules-ch). The necessary fix is to change the API endpoint from /v1/characters/{string} to /v1/characters/-/{string:path}

:path is a URL converter (like :int or :float) which modifies the value that will be stored in the string path parameter/variable. Specifically, :path returns the rest of the path, including any additional / characters, which is exactly the behavior needed to fix this issue.

@jules-ch also advises to use a - or # character to split the API route (e.g, /v1/characters/-/{string:path}) if there will ever be any URLs created under /v1/characters such as /v1/characters/search or /v1/characters/filter.

I am finishing implementing this fix now.

@emreozcan - I'm honestly amazed that you found this project, let alone used it enough to find a bug. Can I ask how you came across my humble (incomplete 😅) Unicode API? I created it to flex my FastAPI/Python/backend skills on my developer portfolio. Is it useful to you? Any improvements/features you would recommend?