uires 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
nsport 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
> 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 = ^/(.+?)/(.+)$ setpath
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 = ^/(.+?)/(
eported 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_par
> 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 acc
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)
codes 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
--http-socket instead of --socket (or specify both on different ports)
>
--
Roberto De Ioris
http://unbit.com
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
Hi all,
i have released a tool for building VPNs (with various operational modes)
using only websockets as a transport. The server-side delegates all the
authentication, authorization and proxy part to nginx:
https://github.com/unbit/vpn-ws
i hope it will be useful
Regards
--
Roberto De
see it uses tcp sockets when describing nginx integration. This
avoid you to start messing with permissions (btw, the process connecting
to the unix socket, nginx in your case, must have write permission on the
socket).
Read and follow the whole quickstart from start to end, as it
progressively i
t pairs perfectly with nginx:
http://uwsgi-docs.readthedocs.org/en/latest/CGI.html
recent releases (>= 2.0.2) supports async modes so you can spawn multiple
cgi script without the need of a 1:1 mapping with a thread.
You will find the plugin exposes features not available in apache
(included ac
idfs (nginx-gridfs proejct also no longer
> supported).
>
> I'd love to hear from you if possible,
You may be interested in this:
http://uwsgi-docs.readthedocs.org/en/latest/GridFS.html
--
Roberto De Ioris
http://unbit.it
__
> I won't hope every thing is no-blocking and I think it is unnecessary.
>
unfortunataley (well, today is the second time i say thins thing ;) if you
are developing in a non-blocking environment, all must be non-blocking
without exceptions
r uWSGI and the jvm is
>> the
>> best one) so i am quite doubtful saying "multiprocess by default"
>> would be
>> a successfull approach (well the amount of memory per-app will be
>> huge)
>>
>>
>> --
>> Roberto De Ioris
>> http
ss by default" would be
a successfull approach (well the amount of memory per-app will be huge)
--
Roberto De Ioris
http://unbit.it
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
n nginx)
What you mean for "thread switch cost" ?
--
Roberto De Ioris
http://unbit.it
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
d (or better: it
is terribly wrong as in any other non-blocking engine)
You should invest on writing a PSGI adapter so you can use a full
application server (like Starman or uWSGI) behind nginx.
--
Roberto De Ioris
http://unbit.it
___
nginx mailing
misses "range" support and mongodb authentication,
but they will be added in the next releases.
I hope it can be useful.
--
Roberto De Ioris
http://unbit.it
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
and incredibly ugly.
Just let uWSGI do the SCRIPT_NAME rewrite, add the --manage-script-name to
the option (be sure to use the --mount way for loading moinmoin). The
nginx configuration will be simply
location /wiki {
include uwsgi_params;
uwsgi_pass ...;
}
--
Roberto De Ioris
http://unb
to uWSGI SCGI parser too, so in my subconsciuous there should be
a good reason :P)
regarding your updated patch is better for sure
--
Roberto De Ioris
http://unbit.it
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
>
>> Hello!
>>
>> (Cc'd nginx-devel@ as this is better list for this discussion.)
>>
>> On Wed, Feb 20, 2013 at 02:30:38PM +0100, Roberto De Ioris wrote:
>>
>>> Hi, the (tiny) attached patch enable support for new websockets
>>>
> Hello!
>
> (Cc'd nginx-devel@ as this is better list for this discussion.)
>
> On Wed, Feb 20, 2013 at 02:30:38PM +0100, Roberto De Ioris wrote:
>
>> Hi, the (tiny) attached patch enable support for new websockets handling
>> when the uwsgi protocol is used i
-w tests.websockets_echo --gevent 10
no additional configuration is needed for nginx
--
Roberto De Ioris
http://unbit.it
uwsgi_websocket_nginx.patch
Description: Binary data
___
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listi
24 matches
Mail list logo
