EVOLUTION-NINJA

Edit File: url-parsing-with-wsgi.txt

URL Parsing With WSGI And Paste +++++++++++++++++++++++++++++++ :author: Ian Bicking <ianb@colorstudy.com> :revision: $Rev$ :date: $LastChangedDate$ .. contents:: Introduction and Audience ========================= This document is intended for web framework authors and integrators, and people who want to understand the internal architecture of Paste. .. include:: include/contact.txt URL Parsing =========== .. note:: Sometimes people use "URL", and sometimes "URI". I think URLs are a subset of URIs. But in practice you'll almost never see URIs that aren't URLs, and certainly not in Paste. URIs that aren't URLs are abstract Identifiers, that cannot necessarily be used to Locate the resource. This document is *all* about locating. Most generally, URL parsing is about taking a URL and determining what "resource" the URL refers to. "Resource" is a rather vague term, intentionally. It's really just a metaphor -- in reality there aren't any "resources" in HTTP; there are only requests and responses. In Paste, everything is about WSGI. But that can seem too fancy. There are four core things involved: the *request* (personified in the WSGI environment), the *response* (personified inthe ``start_response`` callback and the return iterator), the WSGI application, and the server that calls that application. The application and request are objects, while the server and response are really more like actions than concrete objects. In this context, URL parsing is about mapping a URL to an *application* and a *request*. The request actually gets modified as it moves through different parts of the system. Two dictionary keys in particular relate to URLs -- ``SCRIPT_NAME`` and ``PATH_INFO`` -- but any part of the environment can be modified as it is passed through the system. Dispatching =========== .. note:: WSGI isn't object oriented? Well, if you look at it, you'll notice there's no objects except built-in types, so it shouldn't be a surprise. Additionally, the interface and promises of the objects we do see are very minimal. An application doesn't have any interface except one method -- ``__call__`` -- and that method *does* things, it doesn't give any other information. Because WSGI is action-oriented, rather than object-oriented, it's more important what we *do*. "Finding" an application is probably an intermediate step, but "running" the application is our ultimate goal, and the only real judge of success. An application that isn't run is useless to us, because it doesn't have any other useful methods. So what we're really doing is *dispatching* -- we're handing the request and responsibility for the response off to another object (another actor, really). In the process we can actually retain some control -- we can capture and transform the response, and we can modify the request -- but that's not what the typical URL resolver will do. Motivations =========== The most obvious kind of URL parsing is finding a WSGI application. Typically when a framework first supports WSGI or is integrated into Paste, it is "monolithic" with respect to URLs. That is, you define (in Paste, or maybe in Apache) a "root" URL, and everything under that goes into the framework. What the framework does internally, Paste does not know -- it probably finds internal objects to dispatch to, but the framework is opaque to Paste. Not just to Paste, but to any code that isn't in that framework. That means that we can't mix code from multiple frameworks, or as easily share services, or use WSGI middleware that doesn't apply to the entire framework/application. An example of someplace we might want to use an "application" that isn't part of the framework would be uploading large files. It's possible to keep track of upload progress, and report that back to the user, but no framework typically is capable of this. This is usually because the POST request is completely read and parsed before it invokes any application code. This is resolvable in WSGI -- a WSGI application can provide its own code to read and parse the POST request, and simultaneously report progress (usually in a way that *another* WSGI application/request can read and report to the user on that progress). This is an example where you want to allow "foreign" applications to be intermingled with framework application code. Finding Applications ==================== OK, enough theory. How does a URL parser work? Well, it is a WSGI application, and a WSGI server, in the typical "WSGI middleware" style. Except that it determines which application it will serve for each request. Let's consider Paste's ``URLParser`` (in ``paste.urlparser``). This class takes a directory name as its only required argument, and instances are WSGI applications. When a request comes in, the parser looks at ``PATH_INFO`` to see what's left to parse. ``SCRIPT_NAME`` represents where we are *now*; it's the part of the URL that has been parsed. There's a couple special cases: The empty string: URLParser serves directories. When ``PATH_INFO`` is empty, that means we got a request with no trailing ``/``, like say ``/blog`` If URLParser serves the ``blog`` directory, then this won't do -- the user is requesting the ``blog`` *page*. We have to redirect them to ``/blog/``. A single ``/``: So, we got a trailing ``/``. This means we need to serve the "index" page. In URLParser, this is some file named ``index``, though that's really an implementation detail. You could create an index dynamically (like Apache's file listings), or whatever. Otherwise we get a string like ``/path...``. Note that ``PATH_INFO`` *must* start with a ``/``, or it must be empty. URLParser pulls off the first part of the path. E.g., if ``PATH_INFO`` is ``/blog/edit/285``, then the first part is ``blog``. It appends this to ``SCRIPT_NAME``, and strips it off ``PATH_INFO`` (which becomes ``/edit/285``). It then searches for a file that matches "blog". In URLParser, this means it looks for a filename which matches that name (ignoring the extension). It then uses the type of that file (determined by extension) to create a WSGI application. One case is that the file is a directory. In that case, the application is *another* URLParser instance, this time with the new directory. URLParser actually allows per-extension "plugins" -- these are just functions that get a filename, and produce a WSGI application. One of these is ``make_py`` -- this function imports the module, and looks for special symbols; if it finds a symbol ``application``, it assumes this is a WSGI application that is ready to accept the request. If it finds a symbol that matches the name of the module (e.g., ``edit``), then it assumes that is an application *factory*, meaning that when you call it with no arguments you get a WSGI application. Another function takes "unknown" files (files for which no better constructor exists) and creates an application that simply responds with the contents of that file (and the appropriate ``Content-Type``). In any case, ``URLParser`` delegates as soon as it can. It doesn't parse the entire path -- it just finds the *next* application, which in turn may delegate to yet another application. Here's a very simple implementation of URLParser:: class URLParser(object): def __init__(self, dir): self.dir = dir def __call__(self, environ, start_response): segment = wsgilib.path_info_pop(environ) if segment is None: # No trailing / # do a redirect... for filename in os.listdir(self.dir): if os.path.splitext(filename)[0] == segment: return self.serve_application( environ, start_response, filename) # do a 404 Not Found def serve_application(self, environ, start_response, filename): basename, ext = os.path.splitext(filename) filename = os.path.join(self.dir, filename) if os.path.isdir(filename): return URLParser(filename)(environ, start_response) elif ext == '.py': module = import_module(filename) if hasattr(module, 'application'): return module.application(environ, start_response) elif hasattr(module, basename): return getattr(module, basename)( environ, start_response) else: return wsgilib.send_file(filename) Modifying The Request ===================== Well, URLParser is one kind of parser. But others are possible, and aren't too hard to write. Lets imagine a URL like ``/2004/05/01/edit``. It's likely that ``/2004/05/01`` doesn't point to anything on file, but is really more of a "variable" that gets passed to ``edit``. So we can pull them off and put them somewhere. This is a good place for a WSGI extension. Lets put them in ``environ["app.url_date"]``. We'll pass one other applications in -- once we get the date (if any) we need to pass the request onto an application that can actually handle it. This "application" might be a URLParser or similar system (that figures out what ``/edit`` means). :: class GrabDate(object): def __init__(self, subapp): self.subapp = subapp def __call__(self, environ, start_response): date_parts = [] while len(date_parts) < 3: first, rest = wsgilib.path_info_split(environ['PATH_INFO']) try: date_parts.append(int(first)) wsgilib.path_info_pop(environ) except (ValueError, TypeError): break environ['app.date_parts'] = date_parts return self.subapp(environ, start_response) This is really like traditional "middleware", in that it sits between the server and just one application. Assuming you put this class in the ``myapp.grabdate`` module, you could install it by adding this to your configuration:: middleware.append('myapp.grabdate.GrabDate') Object Publishing ================= Besides looking in the filesystem, "object publishing" is another popular way to do URL parsing. This is pretty easy to implement as well -- it usually just means use ``getattr`` with the popped segments. But we'll implement a rough approximation of `Quixote's <http://www.mems-exchange.org/software/quixote/>`_ URL parsing:: class ObjectApp(object): def __init__(self, obj): self.obj = obj def __call__(self, environ, start_response): next = wsgilib.path_info_pop(environ) if next is None: # This is the object, lets serve it... return self.publish(obj, environ, start_response) next = next or '_q_index' # the default index method if next in obj._q_export and getattr(obj, next, None): return ObjectApp(getattr(obj, next))( environ, start_reponse) next_obj = obj._q_traverse(next) if not next_obj: # Do a 404 return ObjectApp(next_obj)(environ, start_response) def publish(self, obj, environ, start_response): if callable(obj): output = str(obj()) else: output = str(obj) start_response('200 OK', [('Content-type', 'text/html')]) return [output] The ``publish`` object is a little weak, and functions like ``_q_traverse`` aren't passed interesting information about the request, but this is only a rough approximation of the framework. Things to note: * The object has standard attributes and methods -- ``_q_exports`` (attributes that are public to the web) and ``_q_traverse`` (a way of overriding the traversal without having an attribute for each possible path segment). * The object isn't rendered until the path is completely consumed (when ``next`` is ``None``). This means ``_q_traverse`` has to consume extra segments of the path. In this version ``_q_traverse`` is only given the next piece of the path; Quixote gives it the entire path (as a list of segments). * ``publish`` is really a small and lame way to turn a Quixote object into a WSGI application. For any serious framework you'd want to do a better job than what I do here. * It would be even better if you used something like `Adaptation <http://www.python.org/peps/pep-0246.html>`_ to convert objects into applications. This would include removing the explicit creation of new ``ObjectApp`` instances, which could also be a kind of fall-back adaptation. Anyway, this example is less complete, but maybe it will get you thinking.