Well, er, yes.

pywebserver is a minimal web server that takes full advantage of pyWeb and PyHP, to let you build your own full-featured dynamic websites.

• 100% Pure Python
  
  • You can either run pywebserver as a black box, or you can import/subclass its classes for even greater customisation
    
    
• Easy Configuration
  
  • No need to wade through megabytes of documentation
  • Get up and running in seconds
    
    
• Fast
  
  • Speed should be reasonably comparable to Apache and thttpd, and avoids the heavy overhead of CGI
    
    
• Native PyHP Support
  
  • Easy - just declare which file suffices should be preprocessed by PyHP (only .py.html by default, but you could set it to .html as well if you like, or whatever)
  • Much faster than shebanging ("#!") your PyHP scripts to run under PyHP within Apache
    
    
• CGI Support
  
  • Just declare which filename masks should be executed as CGIs (default .cgi)

• Easy Virtual Host Support
  
  • Simple configuration syntax - host1=dir1,host2=dir2...
    
    
• Flexible
  
  • You could specify the entire configuration using command-line arguments, if you want
  • Easy to hack - either maul the code, or subclass from it
  • Block certain URLs via unix-style patterns or regular expressions

Installation of pywebserver is trivial.

If you have already run the python setup.py install script to install PyWeb, pywebserver will already be installed along with it.

(If on windows, you'll need instead to ensure that c:\python2x\lib\site-packages\pywebserver.py (or whatever) is on your PATH.

If you're on *nix, and you haven't run setup.py, then just create a symlink from the pywebserver.py file (wherever you installed it) to a file called pywebserver on your path.

The default server configuration file is pywebserverconfig.py, sourced from the current directory you are in when you start the server.

You can use the -c /path/to/another/file.py command-line option to set the server to find its configuration somewhere else.

Look at the template configuration file supplied with this code (it should be in server/pywebserverconfig.py in your pyweb tarball).

You can override all configuration items in this file with command line options - run pywebserver -h for details.

When your pywebserver is running, it does pretty much what one would expect:

• listening on the designated port (80, or whatever you configure)
• accepting http connections
• preprocessing designated PyHP files (ending with .py.html, or whatever you configure)
• running CGI files in a separate process (ending with .cgi, or whatever you configure)
• blocking attempts to access banned files
• serving up all other files, with a reasonable mimetype guess

But there are a couple of bits of magic, aimed at making your life easier and improving server performance.

When the server starts up, it imports the file pywebserverglobals.py in the current directory (or another file, according to your configuration settings).

After import, all symbols found in this module will be copied as attributes to an object called globaldata, which you will find in the local namespace when autoexec.py is running (see below), and when any python code segments are executed in (or included by) PyHP markups.

This globaldata object gets created from an empty class definition, and acts as a server-global store of data and objects.

Typical uses of globaldata would include:

• python module imports, particularly imports which can take hundreds or thousands of milliseconds, in which case doing such imports with each server hit would cause an unacceptable performance drag
• setting up any custom server-global data which is not supported by standard server configuration

If you wish, you can put a file called autoexec.py into the root documents directory of one or more of your configured virtual hosts.

Think of autoexec.py as a 'hook' - code which will be executed with each and every client 'hit' to the server. Even if the hit is for some static file, like an HTML document or an image file, autoexec.py will be executed.

If, for a given virtual host, autoexec.py is not present within the document directory root, the request will go ahead as normal. But if it is present, it will be run with the execfile() command.

autoexec.py will run with some useful items in its namespace, most importantly:

• page - a pyWeb httpEmpty object, which allows you to:
  
  • add content with calls to page.add() (or just add(), which is also available as shorthand)
  • change the mimetype, by setting the page.contenttype attribute (default 'text/html')
  • abort any further processing of the client request, by setting the attribute page.abort to True.
    
    
• session - a pyWeb httpenv object (refer pyWeb doco)
• fields - shorthand for session.fields - a dict-like object containing the fields from the client request
• cookies - shorthand for session.cookies - a dict-like object containing any cookies received from client
• relpath - a string containing the file path requested by the client. Note that this contains the leading '/'. Also, note that you can write back to this variable if you want to implement an invisible redirect.
  

Ideally, the kinds of things you'll want to put into autoexec.py will include:

• getting database access
• checking user credentials, via cookies and/or http form fields
• checking the legality of certain operations, and aborting any further processing if the client is doing something improper
• writing into page.localdata (as attributes) anything which should be made available to subsequent segments of python code
• generating data which will later be referenced in page layouts

autoexec.py is intended as a convenience, which gives you a hook into every client hit, and which lets you do any initialisations which tend to be common between all or most PyHP scripts.

Any attribute you write into page.localdata can be accessed by PyHP scripts through ${somename}$ markups.

Note - as a security measure, the server is hardwired to block any attempts to access this file via http.

Generally speaking, it's not a good idea to put too much stuff into this file, because it will be executed as python source (not as .pyc) with each and every hit to the server.

If there's anything time-consuming you need to do - importing large modules etc - this is best done in the server-global pywebserverglobals.py file - see above.