How should servers utilise root_path

[pgjones]

root_path is often considered equivalent to WSGI's SCRIPT_NAME, yet usage of root_path by servers differs in that WSGI servers seem to split out the SCRIPT_NAME from the PATH_INFO whereas ASGI servers (Daphne, Hypercorn, Uvicorn) do not,

I find (for all 3 ASGI servers, with daphne shown),

$ SCRIPT_NAME="/bob" gunicorn t110:app
>> environ = {'RAW_URI': '/bob/', 'PATH_INFO': '/', 'SCRIPT_NAME': '/bob', ...}

$ daphne --root-path "/bob" t110:app
>> scope = {'path': '/bob/', 'raw_path': b'/bob/', 'root_path': '/bob', ...}

whereas I think the scope should be,

>> scope = {'path': '/', 'raw_path': b'/bob/', 'root_path': '/bob', ...}

I.e. the server should 404 if the request target does not start with the root_path, and if it does remove it from the path, but keep it in the raw_path. Are the current ASGI servers correct, or does the ASGI spec need to be clearer about this?

[davidism]

ASGI documents root_path as "same as SCRIPT_NAME in WSGI" https://asgi.readthedocs.io/en/latest/specs/www.html#http-connection-scope. That means it should be stripping root_path from path, otherwise route matching won't work as expected when mounted under a path.

We ran into this while working on sans-IO / ASGI support in Werkzeug pallets/werkzeug#2005 (comment).

[davidism]

This seems to be the relevant bug in Daphne: django/daphne#125. I couldn't find one for Uvicorn.

[euri10]

Interesting, we had one user complaining recently it wasn't working as expected, encode/uvicorn#937 I must admit I rapidly tested against daphne and hypercorn, and as same routes were served the same way as in uvicorn I maybe diagnosed too fast this wasn't a problem, but seeing this I'm not sure about it now, not familiar enough with the SCRIPT_NAME behavior. I always thought root_path was meant to be used with a reverse proxy

…

On Wed, Jan 20, 2021, 6:10 PM David Lord ***@***.***> wrote: This seems to be the relevant bug in Daphne: django/daphne#125 <django/daphne#125>. I couldn't find one for Uvicorn. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#229 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAINSPQCMARL2DN57LRCWY3S24FAFANCNFSM4WK62A7A> .

[davidism]

root_path is also used in reverse proxy situations, although it also needs to be supported by the A/WSGI server.

There are various ways to manage it, but ultimately the WSGI server and/or app needs to know where it's mounted and adjust SCRIPT_NAME accordingly. (Same for ASGI and root_path.) So for example, ASGI apps could work around this right now by using some middleware to fix root_path themselves before handling the request, although that's not ideal, as shown in the workaround in the issue @euri10 linked.

[pgjones]

I've altered Hypercorn to act as WSGI does, see this commit

[pgjones]

See also #230.

[andrewgodwin]

The intention of the spec is thus:

• root_path does, in fact, match SCRIPT_NAME and is the prefix of where the app is stored
• path includes root_path and then anything else after it, unlike PATH_INFO, which has SCRIPT_NAME removed from the beginning

(this is made slightly clearer at the bottom in https://asgi.readthedocs.io/en/latest/specs/www.html#wsgi-compatibility)

It was my intention that frameworks doing URL routing on just the "local" section remove root_path from path themselves.

[davidism]

I see. Then the spec needs to clarify that root_path has the same value as SCRIPT_NAME, but doesn't have the same behavior with path. If I understand, in ASGI, root_path is intended to be a hint for how the app should treat path, it's just passed through by the server without doing anything?

I sort of understand this, since it makes building URLs work the same as matching URLs. But this is going to make extracting behavior in Werkzeug to work with both WSGI and ASGI trickier, not sure exactly what the answer is yet for us. It also seems to be causing misunderstandings based on the linked issues.

[davidism]

The compatibility section of the spec currently says:

PATH_INFO can be derived from path and root_path

Now that you've clarified your intention, I see that it means "can be derived by stripping root_path from path". But reading over it coming from WSGI, I misread that it was the same separation as WSGI.

[davidism]

I guess my next question is what the point of root_path is then, if it's just passed on to the app. Why not just configure that in the app and not have it passed by the server at all, since the app would be the thing stripping it while matching or appending it while building.

[andrewgodwin]

Well, the point of having it is twofold:

• I wanted to be able to preserve compatibility with WSGI through a translation layer, so that information was needed somehow
• You might want to proxy the same app with different root paths in e.g. a multi-tenant hosting situation

I agree the spec could be a lot more clear - happy to improve the language there.

[pgjones]

This now makes sense to me, I'll close.