Welcome! Log In Create A New Profile

Advanced

Problem with uWSGI and PATH_INFO

Posted by Etienne Robillard 
Etienne Robillard
Problem with uWSGI and PATH_INFO
July 27, 2017 01:50PM
Hi, uWSGI apparently does some weird voodoo tricks to manage SCRIPT_NAME
and PATH_INFO when using nginx: "The WSGI standard dictates that
|SCRIPT_NAME| is the variable used to select a specific application.
Unfortunately u nginx is not able to rewrite PATH_INFO accordingly to
SCRIPT_NAME. For such reason you need to instruct WSGI to map specific
apps in the so called “mountpoint” and rewrite SCRIPT_NAME and PATH_INFO
automatically"

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?

Thank you in advance,

E


--
Etienne Robillard
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 03:00PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 03:10PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 03:20PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 04:00PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 04:30PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 05:30PM
> 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
Francis Daly
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 05:30PM
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).

No-one has reported that there is a problem and provided a fix.

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.


In the case of fastcgi, someone saw a possibly-similar issue and went
to the bother of adding a fastcgi_split_path_info directives which splits
the request uri string into two variables.

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.

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
--
Francis Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 06:10PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 06:50PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 07:10PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 07:50PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 27, 2017 11:50PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Francis Daly
Re: Problem with uWSGI and PATH_INFO
July 28, 2017 09:20AM
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 Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
July 28, 2017 09:30AM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
July 29, 2017 12:20PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
August 05, 2017 05:50PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Francis Daly
Re: Problem with uWSGI and PATH_INFO
August 06, 2017 12:10PM
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 Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
August 06, 2017 12:30PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
August 06, 2017 01:00PM
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
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Roberto De Ioris
Re: Problem with uWSGI and PATH_INFO
August 06, 2017 04:20PM
> 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
Etienne Robillard
Re: Problem with uWSGI and PATH_INFO
August 07, 2017 11:10AM
Hi Roberto,

Le 2017-08-06 à 10:09, Roberto De Ioris a écrit :
> 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.
To be fair, I haven't found anything in the uWSGI docs covering the
subject of mounting a WSGI app in nginx without suggesting to define
mountpoints in my uwsgi config. Mountpoints are not defined in the WSGI
specification. Rewriting PATH_INFO and SCRIPT_NAME variables is ok, but
I still need FastCGI-like compatibility. I would like an option to
disable mountpoints at runtime... ;)

E

--
Etienne Robillard
tkadm30@yandex.com
http://www.isotopesoftware.ca/

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Francis Daly
Re: Problem with uWSGI and PATH_INFO
August 08, 2017 08:20PM
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 Daly francis@daoine.org
_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Sorry, only registered users may post in this forum.

Click here to login