[Web-SIG] Accessing deeply nested multiple doc roots for WSGI apps

Jason Stitt jason at pengale.com
Sat Oct 15 08:21:50 CEST 2005

On Oct 14, 2005, at 7:30 PM, Ben Bangert wrote:

> 1) Have a faster version of StaticURLParser, perhaps written in C
> 2) Create some sort of specification for a single static docroot
> where each WSGI egg gets its own symlink into
> #1 still leaves me with the WSGI app sending static data, which isn't
> ideal but so far it works and I can put the WSGI app under any URL
> prefix without a problem. It also requires me to dynamically generate
> the URL to all static information.

I agree with you that sending static files over WSGI is not ideal, in  
general. Depending on the server implementation you are using it is  
theoretically possible to take advantage of sendfile() for performance:


But if you are using FastCGI or SCGI (e.g. with Flup) instead of  
running within the HTTP server itself (e.g. with mod_python), I'm not  
sure if that will work. (Anybody more familiar with Flup's  
capabilities, or whether any currently available server implements  
that part of the PEP?)

Can you set up Squid or a similar proxy and cache static URLs? That  
would probably get rid of any performance problems.

> #2 is probably easier in some respects, since if the scheme is a
> given (ie, /media/PACKAGE/VERSION/FILE.GIF) then I don't need to
> generate all the URL's and the webserver can be pointed to the static
> files root.

Personally, I wouldn't base the URL/filename on the package name and  
version. What if you wanted to run multiple instances of the same  
application, each with its own files? Some of them could be  
dynamically generated, or maybe the header graphic just needs to be  
different for each instance. And if any of these files might be  
linked to externally, you don't want a changing version # in there.

The publishing engine I'm planning (yeah, I know, everyone has one  
these days, don't they?) needs to be able to run as many different  
sites as I want on one server. Anything to do with filesystem paths  
and base URLs/hostnames will be configured per site, so I don't have  
a standard naming scheme in the code itself. This does mean  
"generating" URLs, but you're going to have to do that for links  
between pages anyway, right?


P.S. New on this list. Is there an introduction protocol, and is it  
more or less complicated than HTTP? ;-)

More information about the Web-SIG mailing list