Add a note on how root_path should be used #230
Conversation
|
I guess it depends on how you deal with these internally, but the spec probably shouldn't say to base this off I think there should be some more nuance than just "remove prefix", as the prefix should either end with a slash, or be followed by a slash in the path, in order for |
This follows WSGI, as root_path is considered the equivalent to SCRIPT_NAME and ensures that the root_path can be used as a global prefix to all routes in the application.
|
I've updated to try and make this clearer, and whilst slightly adjusting the rule. |
| /foo/bar "" No /foo/bar | ||
| /foo/bar /foo No /bar | ||
| /foo/bar /bar Yes | ||
| /foo/bar /foo/bar Yes |
There was a problem hiding this comment.
I'm unsure this is the right logic...
There was a problem hiding this comment.
/foo/bar should succeed and the path would be / (since it would be empty then have a leading slash prepended).
| /foo/bar /foo No /bar | ||
| /foo/bar /bar Yes | ||
| /foo/bar /foo/bar Yes | ||
| /foo/bar/ /foo/bar No / |
There was a problem hiding this comment.
You should add an example of requesting /foobar with root_path="/foo" to show that it will 404.
|
This is not how |
|
Closing, will adapt Quart and WSGI middleware instead. |
This follows WSGI, as root_path is considered the equivalent to
SCRIPT_NAME and ensures that the root_path can be used as a global
prefix to all routes in the application.