[BUG] Starlette path variable convertors not recognized as path variables

Describe the bug A clear and concise description of what the bug is.

To Reproduce Steps to reproduce the behavior:

1. Create a file with the following code

from fastapi import FastAPI
from starlette.requests import Request

@app.get('/myblog/posts/{id}/{slug:path}')
async def view_post(request: Request, id:int, slug: str):
    return dict(request.path_params)

1. Open the browser and try accessing something like http://127.0.0.1:8000/myblog/posts/42/my_article_is_very_insightful/this_could_be_anything/whatever
2. See error.

{"detail":[{"loc":["query","slug"],"msg":"field required","type":"value_error.missing"}]}

A few things to notice:

• FastAPI throws a validation error about a missing query parameter.
• Making the signature view_post(request: Request, id:int): (no slug:str parameter) causes the error to go away

{"id":"42","slug":"my_article_is_very_insightful/this_could_be_anything/whatever"}

• The returned request.query_params object above (which I imagine comes from Starlette because id appears to be a string) still contains the value for slug, meaning it was recognized at some point but FastAPI didn’t catch it.
• Likewise, making the route URL '/myblog/posts/{id}/{slug}' (no path converter) fixes the issue as long as the slug does not contain any slashes

Expected behavior In the example provided above, the route should work the exact same way whether or not slug:str is in the function signature.

Environment:

• OS: Windows
• FastAPI Version: 0.20.0
• Python version: Python 3.6.5

---

While most Starlette convertors are unlikely to be of much use to FastAPI applications (because of the type validation already being performed by FastAPI) ((as well as being undocumented)), the lack of a path wildcard in FastAPI means there still remains this last use case for them. I wouldn’t personally mind if this issuewas closed in favor of a different implementation of path wildcards, although the contents of request.path_params raise some interesting questions regarding the way in which FastAPI currently performs route parameter extraction and why there appears to be a mismatch between the request object and that FastAPI sees.

[sm-Fifteen]

Looking into the OpenAPI spec further, it would appear that the correct way to do something like this according to both OpenAPI 3.0 and RFC 6570 should actually be something closer to /myblog/posts/{id}/{+slug}, which would be translated in the path parameters as allowReserved: true (that spec is full of surprises!).

Should we be using this instead of Flask-style path variable convertors?

[tiangolo]

@sm-Fifteen it was just solved by @euri10 in #234. It is released in FastAPI 0.22.0.

It works with a/b/c and a%2Fb%2Fc, so, it ends up not being a problem with OpenAPI (even if it’s a bit of kind of cheating).

To clarify a bit, FastAPI is made around APIs, and optimized for them, but still, the intention is to support most of the use cases. And the reason of being based in Starlette is to be able to inherit the awesome Starlette features.

So, the idea is that you should be able to do with FastAPI everything you can do with Starlette. And if you build APIs, you get extra benefits.