and I countered with:

to which Christian answered:

Phillip J. Eby wrote on web-...@python.org (in a different discussion):

IMO, Phillip's comments add support for my interpretation of SCRIPT_NAME
(as it relates to CherryPy): that it's perfectly OK for SCRIPT_NAME to
be something other than "the path up to the wsgiApp callable". When I
wrote wsgiApp, it was designed to be completely independent of the URL:
one callable for multiple "WSGI apps"; each "CP app", when invoked via
_cpwsgi, equates to one "WSGI app". I can see now that I should not have
called it "wsgiApp". :(

PEP 333 takes pains to say "the application object" or "the application
callable" in many, many places where it could have just said "the
application"--I think there's a reason, and it is that "the callable" is
supposed to be decoupled from "the application". One common way to
implement that for a framework is to make "the callable" a factory
function which returns "the real callable"; I chose in CP to use
polymorphism ("many apps -> one function") rather than use a factory
("many apps -> one function -> many functions").

/soapbox off ;)

Robert Brewer
System Architect
Amor Ministries
fuman...@amor.org

at some point I said:

and Robert countered:

then I answered:

then Phillip J. Eby wrote on web-...@python.org (in a different discussion):

which Robert followed with:

I've been following that web-sig discussion as well, and maybe I'm wrong
here, but I think he is referring to changing SCRIPT_NAME within a
wsgiApp for the benefit of a hosted wsgiApp.  And that is totally cool.
  Once we are inside of the CP dispatch process, if it can determine
that "projectapp" is the target CP-app in question and rewrite
SCRIPT_NAME from "/apps/cherrypy" to "/apps/cherrypy/projectapp" and
PATH_INFO to "/tags/filters", that is fine with me.

I actually do that in my WSGIAppFilter - I use
_cputil.get_object_trail() to determine what portion of PATH_INFO
corresponds to objects mounted on the tree.  So SCRIPT_NAME becomes
SCRIPT_NAME + cp_tree_object_parts.  The remainder of the path that
doesn't correspond to objects in the CP tree is set to PATH_INFO.  Thus,
the hosted wsgi app gets a SCRIPT_NAME and PATH_INFO that are correct in
its context.

I like the polymorphism approach.  I just think that the
_cpwsgi.wsgiApp, as a single "application callable", should dispatch to
its multiple hosted wsgi apps with PATH_INFO (i.e., that should be the
object_path).  From within, if it wants to rewrite SCRIPT_NAME and
PATH_INFO to reflect the true location of the internal app, that is
fine.   It really is the only way that a correct SCRIPT_NAME and
PATH_INFO could be set since only CP knows the internal object structure
of the tree.

So here is what I am proposing, in a nutshell:

1. Have CP ignore SCRIPT_NAME for locating the object requested.
2. Use PATH_INFO to locate the requested object.
3. Optionally: rewrite SCRIPT_NAME to be the original SCRIPT_NAME + the
"found application" (however that is determined - I gave my
WSGIAppFilter example).
4. Use SCRIPT_NAME + path when writing issuing redirects and other URL
writing tasks.

Me too :-)

Christian

Alright, I took a different approach on this.  As you suggested, I went
after _cpwsgiserver this time.

I have updated #455 (http://www.cherrypy.org/ticket/455) with a new
patch.  _cpwsgiserver should now set the correct SCRIPT_NAME and
PATH_INFO.  It probably still needs some fine tuning, but I didn't want
to go much further on it until I got some feedback (yea or nay).

That is basically what I did.  The default behavior still simply takes a
single app and serves it.  There is now an add_application(path, app)
method that lets you mount an app at a different point.  As I think
about it, maybe this behavior should mirror the cherrypy.tree object a
little more.  Maybe server.add_application() should become server.mount()?

Anyhow, the bottom line is that _cpwsgiserver can now host multiple WSGI
apps at multiple locations.  The mount point for the application becomes
its SCRIPT_NAME.  When a URL is requested, the server determines by its
path which application should handle it.

Hhhmm...I wasn't really sure what you meant by this.  I'm not sure why
the _cpwsgiserver would need to be aware of application locations within
the main wsgiApp callable.

Thanks for bearing with me on this still.  Maybe even with this latest
patch this idea still isn't feasible, but I have at least got a better
understanding of the inner workings of CP in the process :-)  What I
have put together passed all current tests, but would of course require
new tests if it is a direction we want to go.

Here is an example of using the new setup:

import cherrypy
from cherrypy._cpwsgi import wsgiApp
from somepackage import somemiddleware, some_simple_app

class Root:
     @cherrypy.expose
     def index(self):
         return "Hello, world!"

wrapped_app = somemiddleware(wsgiApp)

cherrypy.tree.mount(Root(), '/')

# tell CP to use our custom wrapped CP wsgiApp
cherrypy.server.cp_wsgi_app = wrapped_app

# add another wsgi app to host (maybe this is beyond the scope of CP?)
cherrypy.server.mount_wsgi_app('/over/here', some_simple_app)

cherrypy.server.start()

Ok, I'll answer my own question.  It *is* beyond the scope of CP.  I
have removed it in my latest patch attached to the ticket.

Christian
http://www.dowski.com