Pesto with uWSGI

[Randall]

I'm trying to get Pesto to work with uWSGI. My application works fine
using wsgiref.simple_server.make_server, but when I use uWSGI, I see
the error:

<pesto.wsgiutils.ClosingIterator object at 0x8ae3b2c> deleted without
close being called

A page will load, but redirects are failing and (when I use nginx), I
see this message:

client closed prematurely connection while reading client request line

To rule out uWSGI's built in http server, I hooked it up to nginx and
had the same problem. I'm using the DispatcherApp and
session_middleware so that initialization looks like this:

dispatcher = DispatcherApp()

sessioning = pesto.session_middleware(
FileSessionManager(SESSION_PATH),
)
application = sessioning(dispatcher)

Maybe this is a uWSGI problem, but since the only error I see is
coming from pesto, I was hoping I might get some insight from here.

Thanks.

-Randall

[Oliver Cope]

Hi Randall,

You normally see errors like that when a middleware layer forgets to
call the response iterator's close method.

I've not used uwsgi before so I don't have any idea as to whether this
could be a factor, or whether there's a bug in pesto or any other
middleware in use. I just tried installing uwsgi, but so far I'm not
having much luck with getting it to run on my system at all :( I'll have
another go later on when I have some more time to look into it.

You could also try putting wsgiref.validate.validator into your stack,
I've found this to be useful for sniffing out any misbehaving middleware
layers.

Olly.

[Randall]

Thanks. I've also tried hooking it up to nginx using flup and fsgi,
but am having problems there too. It seems PATH_INFO is not passed
along. I don't know what CGI variables are required for everything to
work OK so at this point I'm just trying stuff, which is a little
disappointing since the WSGI layer is supposed to handle that. I'm
going to take your suggestion and enable wsgiref.validate.validator.

[Randall]

Oliver,

First, I've settled on nginx + flup. I prefer flup's forking model
over threaded servers and because it can fork extra processes when the
load ramps.

Part of my problem was that I configured sessions wrong, but there is
another issue. It seems that Pesto requires PATH_INFO, so I set
PATH_INFO = SCRIPT_NAME and my application is working properly. I
tried to figure out what is expected of PATH_INFO AND SCRIPT_NAME for
WSGI and I didn't find a clear answer. However, from what I
gathered, SCRIPT_NAME is typically the primary component and PATH_INFO
what's left. For instance, for a php script:

/app1/myscript.php/item/edit

SCRIPT_NAME = /app1/myscript.php
PATH_INFO = /item/edit

In the case of a WSGI app, there really is no script name, so I would
expect this:

/app1/myfunction/item/edit/ (no way to distinguish script from
path_info)

SCRIPT_NAME = /app1/myfunction/item/edit/
PATH_INFO = / (part after edit)

But this doesn't seem to work with Pesto. It expects

PATH_INFO = /app1/myfunction/item/edit

Did I over look something? Is there a variable other than PATH_INFO
when can be set?

Also, I did run the validator and everything seems OK with PATH_INFO =
SCRIPT_NAME except for it doesn't like SCRIPT_NAME = '/' (it wants ''
instead).

On Oct 26, 3:43 am, Oliver Cope <oli...@redgecko.org> wrote:

[Oliver Cope]

On 27/10/2011 07:26, Randall wrote:
>
> Part of my problem was that I configured sessions wrong, but there is
> another issue. It seems that Pesto requires PATH_INFO, so I set
> PATH_INFO = SCRIPT_NAME and my application is working properly. I
> tried to figure out what is expected of PATH_INFO AND SCRIPT_NAME for
> WSGI and I didn't find a clear answer.
>

If you want to find out how SCRIPT_NAME and PATH_INFO are used by WSGI
then the best thing you could do is to read PEP-3333. The section
'environ variables' covers these variables, but if you have time then
it's definitely worth reading through the whole document.

http://www.python.org/dev/peps/pep-3333/

> However, from what I
> gathered, SCRIPT_NAME is typically the primary component and PATH_INFO
> what's left. For instance, for a php script:
>
> /app1/myscript.php/item/edit
>
> SCRIPT_NAME = /app1/myscript.php
> PATH_INFO = /item/edit
>

Yes, that's correct.

> In the case of a WSGI app, there really is no script name, so I would
> expect this:
>

The general rule is that SCRIPT_NAME is the location where your
application is mounted, and put together with PATH_INFO will show you
the full request path.

The one small exception is that if you app is mounted at the root
location, '/', then SCRIPT_NAME should be set to an empty string. For
example a request for '/item/edit' would be passed:

SCRIPT_NAME = ''
PATH_INFO = '/item/edit'

But if your app was mounted at '/app1' then a request for
'/app1/item/edit' would look like this:

SCRIPT_NAME = '/app1'
PATH_INFO = '/item/edit'

It's up to you when configuring nginx/flup to decide which location you
want your app to run from and make sure the SCRIPT_NAME/PATH_INFO are
correctly set. The flask docs have some good configuration examples
showing how to mount WSGI applications at any location:

http://flask.pocoo.org/docs/deploying/fastcgi/#configuring-nginx

Cheers,

Olly.