Re: Problem with uWSGI and PATH_INFO
On Sun, Aug 06, 2017 at 12:28:11PM +0200, Roberto De Ioris wrote: > > On Sat, Aug 05, 2017 at 11:47:24AM -0400, Etienne Robillard wrote: Hi there, > nginx is not able to correctly split PATH_INFO accordingly to SCRIPT_NAME That is correct. It is similarly correct that nginx is not able to know where your uwsgi server is listening. > (and technically it should not do it as uwsgi is a transport only protocol > and the server could make any kind of assumptions about variables). The administrator should know what variable values the uwsgi server will make use of, and where the uwsgi server is listening. The administrator can configure nginx to match whatever those site-specific requirements are. (And one possible way to do that, is for nginx to always set PATH_INFO = the original request, and let the uwsgi server use that in any way it likes.) f -- Francis Dalyfran...@daoine.org ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> So either Django is not a compliant WSGI app or uWSGI is unable to mount > a standard WSGI application to the root location in nginx without using > magic rewrites? > > Eienne > Neither of the two, you were asking about mounting in a sub-uri in the previous posts, that requires some kind of ruling. For mounting under / (or empty SCRIPT_NAME to be more compliant with WSGI) you do not need additional configurations. -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
So either Django is not a compliant WSGI app or uWSGI is unable to mount a standard WSGI application to the root location in nginx without using magic rewrites? Eienne Le 2017-08-06 à 06:28, Roberto De Ioris a écrit : This is what any compliant WSGI server (included uWSGI) expects: https://www.python.org/dev/peps/pep-0333/#environ-variables nginx is not able to correctly split PATH_INFO accordingly to SCRIPT_NAME (and technically it should not do it as uwsgi is a transport only protocol and the server could make any kind of assumptions about variables). For this reason you need to instruct uWSGI to rewrite PATH_INFO accordingly (like shown in the previous posts). There can be no magic in uWSGI to rewrite it as it would mean infering what the user want to do. The solution is using uWSGI to rewrite it (it has at least 3 ways) -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> On Sat, Aug 05, 2017 at 11:47:24AM -0400, Etienne Robillard wrote: > > Hi there, > >> The workaround suggested below is not working. > > From the words here, it is not clear to me what specific configuration > you are using. > >> The only case where >> Django correctly handle uWSGI transport is when PATH_INFO is set to >> DOCUMENT_URI in uwsgi_params. So can someone please explain how to >> set uWSGI to run a WSGI app in FastCGI (backward-compatible) mode? > > I don't know enough about Django to understand that question. > > I do know enough about nginx to believe that nginx does not care what > Django does. > > The only thing that seems to be missing, from an nginx perspective, is: > what does the uwsgi-server want to receive for this request? > > That is: > >> >>It all comes down to: for one specific http request, what values do >> >>you want SCRIPT_NAME and PATH_INFO to have when they are sent to the >> >>uwsgi upstream? > > If someone will provide one explicit example of what behaviour is wanted, > then it may be clear what the appropriate nginx config for this case is. > > This is what any compliant WSGI server (included uWSGI) expects: https://www.python.org/dev/peps/pep-0333/#environ-variables nginx is not able to correctly split PATH_INFO accordingly to SCRIPT_NAME (and technically it should not do it as uwsgi is a transport only protocol and the server could make any kind of assumptions about variables). For this reason you need to instruct uWSGI to rewrite PATH_INFO accordingly (like shown in the previous posts). There can be no magic in uWSGI to rewrite it as it would mean infering what the user want to do. The solution is using uWSGI to rewrite it (it has at least 3 ways) Unfortunately i am not able to help better :) -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
On Sat, Aug 05, 2017 at 11:47:24AM -0400, Etienne Robillard wrote: Hi there, > The workaround suggested below is not working. >From the words here, it is not clear to me what specific configuration you are using. > The only case where > Django correctly handle uWSGI transport is when PATH_INFO is set to > DOCUMENT_URI in uwsgi_params. So can someone please explain how to > set uWSGI to run a WSGI app in FastCGI (backward-compatible) mode? I don't know enough about Django to understand that question. I do know enough about nginx to believe that nginx does not care what Django does. The only thing that seems to be missing, from an nginx perspective, is: what does the uwsgi-server want to receive for this request? That is: > >>It all comes down to: for one specific http request, what values do > >>you want SCRIPT_NAME and PATH_INFO to have when they are sent to the > >>uwsgi upstream? If someone will provide one explicit example of what behaviour is wanted, then it may be clear what the appropriate nginx config for this case is. Cheers, f -- Francis Dalyfran...@daoine.org ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi, The workaround suggested below is not working. The only case where Django correctly handle uWSGI transport is when PATH_INFO is set to DOCUMENT_URI in uwsgi_params. So can someone please explain how to set uWSGI to run a WSGI app in FastCGI (backward-compatible) mode? Etienne Le 2017-07-29 à 06:09, Etienne Robillard a écrit : Hi Francis, Le 2017-07-28 à 03:17, Francis Daly a écrit : What I meant there was that you could possibly use fastcgi_split_path_info to define how you want your $request_uri to be split into parts for your SCRIPT_NAME and PATH_INFO as uwsgi_param values. So your eventual config could include uwsgi_param SCRIPT_NAME $fastcgi_script_name; uwsgi_param PATH_INFO $fastcgi_path_info; after you have defined the first directive appropriately. It all comes down to: for one specific http request, what values do you want SCRIPT_NAME and PATH_INFO to have when they are sent to the uwsgi upstream? I'll try your workaround. I want nginx to manage SCRIPT_NAME and PATH_INFO in FastCGI mode, and uWSGI to act as a FastCGI handler. Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi Francis, Le 2017-07-28 à 03:17, Francis Daly a écrit : What I meant there was that you could possibly use fastcgi_split_path_info to define how you want your $request_uri to be split into parts for your SCRIPT_NAME and PATH_INFO as uwsgi_param values. So your eventual config could include uwsgi_param SCRIPT_NAME $fastcgi_script_name; uwsgi_param PATH_INFO $fastcgi_path_info; after you have defined the first directive appropriately. It all comes down to: for one specific http request, what values do you want SCRIPT_NAME and PATH_INFO to have when they are sent to the uwsgi upstream? I'll try your workaround. I want nginx to manage SCRIPT_NAME and PATH_INFO in FastCGI mode, and uWSGI to act as a FastCGI handler. Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> 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
Re: Problem with uWSGI and PATH_INFO
On Thu, Jul 27, 2017 at 12:06:42PM -0400, Etienne Robillard wrote:
> Le 2017-07-27 à 11:25, Francis Daly a écrit :
> >On Thu, Jul 27, 2017 at 07:45:28AM -0400, Etienne Robillard wrote:
Hi there,
> >The uwsgi_params values are an example of what can be done. The
> >combination of SCRIPT_NAME and PATH_INFO in that file is consistent, and
> >is valid in some cases (that is, cases where the application corresponds
> >to the "root" of the server).
> Actually my problem is that SCRIPT_NAME is not defined in
> uwsgi_params. SCRIPT_NAME is a mandatory environment variable as per
> HTTP/1.1 spec.
?
HTTP/1.1 does not care about uwsgi, no?
I can see what appears to be the WSGI spec at
https://www.python.org/dev/peps/pep-0333/
My initial reading of that says that SCRIPT_NAME is optional.
Is there a uWSGI spec which says something different?
If you want SCRIPT_NAME set to a particular value, you can set SCRIPT_NAME
to a particular value in your config.
> >No-one has reported that there is a problem and provided a fix.
> That's a major issue. A standard WSGI application should be able to
> use a uWSGI upstream server within the "/" location block without
> the need to define any "mountpoints".
So configure your nginx to send whatever parameters your uWSGI upstream
expects for your WSGI application to work the way you want it to.
> >In general, only the administrator knows what SCRIPT_NAME and PATH_INFO
> >values are appropriate in any one case, so that's the person who should
> >configure the two to match their particular case.
>
> Correct. Attempting to rewrite PATH_INFO as DOCUMENT_URI seems not a
> reliable solution for my simple use-case.
The defaults do not work for your use case.
What settings do you want for your use case?
> >(Actually: perhaps fastcgi_split_path_info can be used directly, even
> >in a location{} which does not do fastcgi_pass? It should be easy enough
> >to test whether that can work.)
> Note that I don't use fastcgi_split_path_info. The only modification
> I did to fastcgi_params is:
> fastcgi_param SCRIPT_NAME $fastcgi_script_name
> fastcgi_param PATH_INFO $fastcgi_script_name
What I meant there was that you could possibly use fastcgi_split_path_info
to define how you want your $request_uri to be split into parts for your
SCRIPT_NAME and PATH_INFO as uwsgi_param values.
So your eventual config could include
uwsgi_param SCRIPT_NAME $fastcgi_script_name;
uwsgi_param PATH_INFO $fastcgi_path_info;
after you have defined the first directive appropriately.
It all comes down to: for one specific http request, what values do
you want SCRIPT_NAME and PATH_INFO to have when they are sent to the
uwsgi upstream?
Good luck with it,
f
--
Francis Dalyfran...@daoine.org
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
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. I have no choice to fallback on using fastcgi until this is fixed either in nginx or uWSGI. Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> Hi Roberto, > > That is not effective. My app uses PATH_INFO to resolve a URL (ie: > /blog/create/) to a callback function. > > Could it be possible to just use : > > uwsgi_param PATH_INFO $path_info > > Assuming $path_info is the request_uri minus the location... > > E > Nope, as already said there is no way to manage this directly in nginx (and technically any 'automatic' management could not be so easy to be 'fair'). You have to rewrite PATH_INFO and SCRIPT_NAME in uWSGI itself following the links i pasted before. To be more clear: nginx passes to uWSGI: PATH_INFO = /foo/bar uWSGI receives it and rewrite it as SCRIPT_NAME = /foo PATH_INFO = /bar by using something like this (in the config, tune the regexps as required): [uwsgi] route = ^/(.+?)/(.+)$ setscriptname:/$1 route = ^/(.+?)/(.+)$ setpathinfo:/$2 -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi Roberto, That is not effective. My app uses PATH_INFO to resolve a URL (ie: /blog/create/) to a callback function. Could it be possible to just use : uwsgi_param PATH_INFO $path_info Assuming $path_info is the request_uri minus the location... E Le 2017-07-27 à 12:47, Roberto De Ioris a écrit : Then just add uwsgi_param SCRIPT_NAME ""; in uwsgi_params :) -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> Hi all, > > Le 2017-07-27 à 11:25, Francis Daly a écrit : >> On Thu, Jul 27, 2017 at 07:45:28AM -0400, Etienne Robillard wrote: >> >> Hi there, >> >>> I'm not sure I understand the logic of this. Can someone please >>> explain why the variable PATH_INFO is set to $document_uri in >>> uwsgi_params? >> My guess (without knowing the history): >> >> The uwsgi_params values are an example of what can be done. The >> combination of SCRIPT_NAME and PATH_INFO in that file is consistent, and >> is valid in some cases (that is, cases where the application corresponds >> to the "root" of the server). > Actually my problem is that SCRIPT_NAME is not defined in uwsgi_params. > SCRIPT_NAME is a mandatory environment variable as per HTTP/1.1 spec. >> >> No-one has reported that there is a problem and provided a fix. > That's a major issue. A standard WSGI application should be able to use > a uWSGI upstream server within the "/" location block without the need > to define any "mountpoints". > Then just add uwsgi_param SCRIPT_NAME ""; in uwsgi_params :) -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi all,
Le 2017-07-27 à 11:25, Francis Daly a écrit :
On Thu, Jul 27, 2017 at 07:45:28AM -0400, Etienne Robillard wrote:
Hi there,
I'm not sure I understand the logic of this. Can someone please
explain why the variable PATH_INFO is set to $document_uri in
uwsgi_params?
My guess (without knowing the history):
The uwsgi_params values are an example of what can be done. The
combination of SCRIPT_NAME and PATH_INFO in that file is consistent, and
is valid in some cases (that is, cases where the application corresponds
to the "root" of the server).
Actually my problem is that SCRIPT_NAME is not defined in uwsgi_params.
SCRIPT_NAME is a mandatory environment variable as per HTTP/1.1 spec.
No-one has reported that there is a problem and provided a fix.
That's a major issue. A standard WSGI application should be able to use
a uWSGI upstream server within the "/" location block without the need
to define any "mountpoints".
In general, only the administrator knows what SCRIPT_NAME and PATH_INFO
values are appropriate in any one case, so that's the person who should
configure the two to match their particular case.
Correct. Attempting to rewrite PATH_INFO as DOCUMENT_URI seems not a
reliable solution for my simple use-case.
Perhaps it would be useful for something similar to exist for uwsgi? The
fact that it does not exist already suggests that no-one has enough of
a need, to arrange that it be added.
A $uwsgi_script_name variable would be a worthy addition.
I guess that a server-level "if" could "set" two variables that could be
used to populate SCRIPT_NAME and PATH_INFO, until a uwsgi_split_path_info
directive is introduced. And that might be enough to avoid the need for
a dedicated directive.
(Actually: perhaps fastcgi_split_path_info can be used directly, even
in a location{} which does not do fastcgi_pass? It should be easy enough
to test whether that can work.)
The hard part is usually deciding what exactly is wanted. After that,
the implementation can be considered.
Good luck with it,
f
Note that I don't use fastcgi_split_path_info. The only modification I
did to fastcgi_params is:
fastcgi_param SCRIPT_NAME $fastcgi_script_name
fastcgi_param PATH_INFO $fastcgi_script_name
Etienne
--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> Hi Roberto, > > > Le 2017-07-27 à 09:52, Roberto De Ioris a écrit : >> >>> Hi again, this is not what manage-script-name is for. It is a >>> uWSGI-specific option for when you only PATH_INFO and you want to >>> generate >>> SCRIPT_NAME accordingly. This requires to "mount" apps under specific >>> paths. > Ok. I really don't want to "mount" my app under a specific script name. >>> uWSGI by itself does not rewrite the vars passed by the webserver, if >>> you >>> want to do it you have to use internal routing accordingly (or use a >>> WSGI >>> middleware that is generally more handy and portable, albeit annoying >>> if >>> you already have an entry point) > Nginx internal routing seems a reasonable choice here. My app is looking > like this: > > dispatch-django.uwsgi: > > def application(environ, start_response): >wsgi_app = make_app() >return wsgi_app(environ, start_response) > > Then I invoke uwsgi like so: > I was meaning uWSGI internal routing :) http://uwsgi-docs.readthedocs.io/en/latest/InternalRouting.html and yes, for manage-script-name to have effect you need to specify the mountpoint of your app like described here: http://uwsgi-docs.readthedocs.io/en/latest/Snippets.html#multiple-flask-apps-in-different-mountpoints (it is flask app but it is the same concept) -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi Roberto, Le 2017-07-27 à 09:52, Roberto De Ioris a écrit : Hi again, this is not what manage-script-name is for. It is a uWSGI-specific option for when you only PATH_INFO and you want to generate SCRIPT_NAME accordingly. This requires to "mount" apps under specific paths. Ok. I really don't want to "mount" my app under a specific script name. uWSGI by itself does not rewrite the vars passed by the webserver, if you want to do it you have to use internal routing accordingly (or use a WSGI middleware that is generally more handy and portable, albeit annoying if you already have an entry point) Nginx internal routing seems a reasonable choice here. My app is looking like this: dispatch-django.uwsgi: def application(environ, start_response): wsgi_app = make_app() return wsgi_app(environ, start_response) Then I invoke uwsgi like so: % uwsgi --socket localhost:8000 --wsgi-file dispatch-django.uwsgi --daemonize /var/log/uwsgi.log --enable-threads --workers 2 I think there's really something wrong with uWSGI internal routing system. The so-called "mountpoints" seems a little obscure to me. Perhaps the documentation should define a method to mount a dynamic django app without the need of --manage-script-name ? Etienne -- Etienne Robillard tkad...@yandex.com http://www.isotopesoftware.ca/ ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> Hi Roberto, > > I use gevent-fastcgi for production. I wish to have the time to dive in > the internals of uWSGI to understand how PATH_INFO and SCRIPT_NAME gets > rewritten by uWSGI. I believe the implementation of --manage-script-name > is incorrect and should be fixed to support having a empty or not set > SCRIPT_NAME value. > > Etienne Hi again, this is not what manage-script-name is for. It is a uWSGI-specific option for when you only PATH_INFO and you want to generate SCRIPT_NAME accordingly. This requires to "mount" apps under specific paths. uWSGI by itself does not rewrite the vars passed by the webserver, if you want to do it you have to use internal routing accordingly (or use a WSGI middleware that is generally more handy and portable, albeit annoying if you already have an entry point) -- Roberto De Ioris http://unbit.com ___ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi Roberto,
I use gevent-fastcgi for production. I wish to have the time to dive in
the internals of uWSGI to understand how PATH_INFO and SCRIPT_NAME gets
rewritten by uWSGI. I believe the implementation of --manage-script-name
is incorrect and should be fixed to support having a empty or not set
SCRIPT_NAME value.
Etienne
Le 2017-07-27 à 09:01, Roberto De Ioris a écrit :
Hi,
if the url is something like /foo/bar and you have a location like
location /foo {
...
}
the WSGI standard expects SCRIPT_NAME to be /foo and PATH_INFO to be /bar
if you manually set SCRIPT_NAME to /foo in nginx, PATH_INFO will continue
to be /foo/bar.
Obviously having nginx managing it could be useful, but nowadays it is way
more versatile to manage this part in uWSGI itself (using the
manage-script-name or internal routing to manually rewrite apps), or
directly in your WSGI middleware.
your fastcgi adapter (i suppose flup) hardcodes this magic using the
classic apache fastcgi patterns (something we cannot rely on as we need to
support multiple environments)
--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
> Hi Roberto,
>
> My Django app runs perfectly ok under FastCGI and nginx but is not
> capable of resolving the proper PATH_INFO under uWSGI. In
> fastcgi_params, the value of PATH_INFO and SCRIPT_NAME are set to
> "$fastcgi_script_name". My nginx config looks like this:
>
> location / {
>
> uwsgi_pass django;
>
> include uwsgi_params;
>
> }
>
> My wsgi app (django-hotsauce) really relay on a HTTP/1.1 compatible
> PATH_INFO value, just like in wsgiref. Why is it not possible to
> implement $uwsgi_script_name variable for nginx?
>
> Best regards,
> Etienne
>
>
Hi,
if the url is something like /foo/bar and you have a location like
location /foo {
...
}
the WSGI standard expects SCRIPT_NAME to be /foo and PATH_INFO to be /bar
if you manually set SCRIPT_NAME to /foo in nginx, PATH_INFO will continue
to be /foo/bar.
Obviously having nginx managing it could be useful, but nowadays it is way
more versatile to manage this part in uWSGI itself (using the
manage-script-name or internal routing to manually rewrite apps), or
directly in your WSGI middleware.
your fastcgi adapter (i suppose flup) hardcodes this magic using the
classic apache fastcgi patterns (something we cannot rely on as we need to
support multiple environments)
--
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Re: Problem with uWSGI and PATH_INFO
Hi Roberto,
My Django app runs perfectly ok under FastCGI and nginx but is not
capable of resolving the proper PATH_INFO under uWSGI. In
fastcgi_params, the value of PATH_INFO and SCRIPT_NAME are set to
"$fastcgi_script_name". My nginx config looks like this:
location / {
uwsgi_pass django;
include uwsgi_params;
}
My wsgi app (django-hotsauce) really relay on a HTTP/1.1 compatible
PATH_INFO value, just like in wsgiref. Why is it not possible to
implement $uwsgi_script_name variable for nginx?
Best regards,
Etienne
Le 2017-07-27 à 08:36, Roberto De Ioris a écrit :
Hi, this is an example on how to configure multiple apps:
http://uwsgi-docs.readthedocs.io/en/latest/Snippets.html#multiple-flask-apps-in-different-mountpoints
Best thing to do is completely avoid nginx manipulating the SCRIPT_NAME
variable.
Even when under fastcgi, the WSGI standard expects a different meaning for
SCRIPT_NAME
--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
