> Hi Roberto,
>
> Le 2017-07-27 à 13:45, Roberto De Ioris a écrit :
>>
>> by using something like this (in the config, tune the regexps as
>> required):
>>
>> [uwsgi]
>> route = ^/(.+?)/(.+)$ setscriptname:/$1
>> route = ^/(.+?)/(.+)$ setpathinfo:/$2
>>
> I use a dynamic regex URL resolver to resolve a request URI to a
> callback function. Also I prefer avoiding to modify uWSGI internal
> routing system for my basic use-case.


Sorry, but someone (nginx or uWSGI) must be informed of your needs (like
Francis explained yesterday). What you consider a 'basic use-case', it is
absolutely not in this specific scenario where you want to map some form
of namespace (like SCRIPT_NAME). The 'basic use case' here is the app
mounted under the root. It is only a lucky coincidence that the fastcgi
hack exposed by nginx (that came from a php need) has been handy for you.
You could even use uWSGI in fastcgi mode. Maybe you have been confused by
the 'uwsgi' name of the protocol (yes, unfortunate choice made 8 years ago
:( ). It has nothing to do with the python WSGI standard, it is only a
transport protocol. It is the backend app that gives meaning to data.

I have no choice to fallback on
> using fastcgi until this is fixed either in nginx or uWSGI.


frankly speaking, there is nothing to fix in uWSGI because it already
honours what the webserver passes to it and eventually (via routing or
code) it is able to rewrite it if the webserver cannot make assumptions. I
have shown at least 3 ways to deal with this, i have literally no idea of
other solutions :)

and honestly, i do not think nginx should add ad-hoc use cases to the
uwsgi protocol (that is a simple dictionary serializer protocol and should
never interpret its content). But obviously this second part is up to the
nginx developers ;)


--
Roberto De Ioris
http://unbit.com
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx