# cherrypy._cpdispatch module

CherryPy dispatchers.

A ‘dispatcher’ is the object which looks up the ‘page handler’ callable and collects config for the current request based on the path_info, other request attributes, and the application architecture. The core calls the dispatcher as early as possible, passing it a ‘path_info’ argument.

The default dispatcher discovers the page handler by matching path_info to a hierarchical arrangement of objects, starting at request.app.root.

class cherrypy._cpdispatch.Dispatcher(dispatch_method_name=None, translate={33: 95, 34: 95, 35: 95, 36: 95, 37: 95, 38: 95, 39: 95, 40: 95, 41: 95, 42: 95, 43: 95, 44: 95, 45: 95, 46: 95, 47: 95, 58: 95, 59: 95, 60: 95, 61: 95, 62: 95, 63: 95, 64: 95, 91: 95, 92: 95, 93: 95, 94: 95, 95: 95, 96: 95, 123: 95, 124: 95, 125: 95, 126: 95})

  Bases: `object`

  CherryPy Dispatcher which walks a tree of objects to find a handler.

  The tree is rooted at cherrypy.request.app.root, and each hierarchical component in the path_info argument is matched to a corresponding nested attribute of the root object. Matching handlers must have an ‘exposed’ attribute which evaluates to True. The special method name “index” matches a URI which ends in a slash (“/”). The special method name “default” may match a portion of the path_info (but only when no longer substring of the path_info matches some other object).

  This is the default, built-in dispatcher for CherryPy.

  dispatch_method_name = '_cp_dispatch'

    The name of the dispatch method that nodes may optionally implement to provide their own dynamic dispatch algorithm.

  find_handler(path)

    Return the appropriate page handler, plus any virtual path.

    This will return two objects. The first will be a callable, which can be used to generate page output. Any parameters from the query string or request body will be sent to that callable as keyword arguments.

    The callable is found by traversing the application’s tree, starting from cherrypy.request.app.root, and matching path components to successive objects in the tree. For example, the URL “/path/to/handler” might return root.path.to.handler.

    The second object returned will be a list of names which are ‘virtual path’ components: parts of the URL which are dynamic, and were not used when looking up the handler. These virtual path components are passed to the handler as positional arguments.

class cherrypy._cpdispatch.LateParamPageHandler(callable, *args, **kwargs)

  Bases: `PageHandler`

  When passing cherrypy.request.params to the page handler, we do not want to capture that dict too early; we want to give tools like the decoding tool a chance to modify the params dict in-between the lookup of the handler and the actual calling of the handler. This subclass takes that into account, and allows request.params to be ‘bound late’ (it’s more complicated than that, but that’s the effect).

  property kwargs

    Page handler kwargs (with cherrypy.request.params copied in).

class cherrypy._cpdispatch.MethodDispatcher(dispatch_method_name=None, translate={33: 95, 34: 95, 35: 95, 36: 95, 37: 95, 38: 95, 39: 95, 40: 95, 41: 95, 42: 95, 43: 95, 44: 95, 45: 95, 46: 95, 47: 95, 58: 95, 59: 95, 60: 95, 61: 95, 62: 95, 63: 95, 64: 95, 91: 95, 92: 95, 93: 95, 94: 95, 95: 95, 96: 95, 123: 95, 124: 95, 125: 95, 126: 95})

  Bases: `Dispatcher`

  Additional dispatch based on cherrypy.request.method.upper().

  Methods named GET, POST, etc will be called on an exposed class. The method names must be all caps; the appropriate Allow header will be output showing all capitalized method names as allowable HTTP verbs.

  Note that the containing class must be exposed, not the methods.

class cherrypy._cpdispatch.PageHandler(callable, *args, **kwargs)

  Bases: `object`

  Callable which sets response.body.

  property args

    The ordered args should be accessible from post dispatch hooks.

  property kwargs

    The named kwargs should be accessible from post dispatch hooks.

class cherrypy._cpdispatch.RoutesDispatcher(full_result=False, **mapper_options)

  Bases: `object`

  A Routes based dispatcher for CherryPy.

  connect(name, route, controller, **kwargs)
  find_handler(path_info)

    Find the right page handler, and set request.config.

  redirect(url)

cherrypy._cpdispatch.VirtualHost(next_dispatcher=<cherrypy._cpdispatch.Dispatcher object>, use_x_forwarded_host=True, **domains)

  Select a different handler based on the Host header.

  This can be useful when running multiple sites within one CP server. It allows several domains to point to different parts of a single website structure. For example:

      http://www.domain.example  ->  root
      http://www.domain2.example  ->  root/domain2/
      http://www.domain2.example:443  ->  root/secure

  can be accomplished via the following config:

      [/]
      request.dispatch = cherrypy.dispatch.VirtualHost(
          **{'www.domain2.example': '/domain2',
             'www.domain2.example:443': '/secure',
            })

  next_dispatcher

    The next dispatcher object in the dispatch chain. The VirtualHost dispatcher adds a prefix to the URL and calls another dispatcher. Defaults to cherrypy.dispatch.Dispatcher().

  use_x_forwarded_host

    If True (the default), any “X-Forwarded-Host” request header will be used instead of the “Host” header. This is commonly added by HTTP servers (such as Apache) when proxying.

  `**domains`

    A dict of {host header value: virtual prefix} pairs. The incoming “Host” request header is looked up in this dict, and, if a match is found, the corresponding “virtual prefix” value will be prepended to the URL path before calling the next dispatcher. Note that you often need separate entries for “example.com” and “www.example.com”. In addition, “Host” headers may contain the port number.

cherrypy._cpdispatch.XMLRPCDispatcher(next_dispatcher=<cherrypy._cpdispatch.Dispatcher object>)

cherrypy._cpdispatch.getargspec(callable)

cherrypy._cpdispatch.test_callable_spec(callable, callable_args, callable_kwargs)

  Inspect callable and test to see if the given args are suitable for it.

  When an error occurs during the handler’s invoking stage there are 2 erroneous cases: 1. Too many parameters passed to a function which doesn’t define

  > one of *args or **kwargs.

  2. Too little parameters are passed to the function.

  There are 3 sources of parameters to a cherrypy handler. 1. query string parameters are passed as keyword parameters to the

  > handler.

  2. body parameters are also passed as keyword parameters.

  3. when partial matching occurs, the final path atoms are passed as positional args.

  Both the query string and path atoms are part of the URI. If they are incorrect, then a 404 Not Found should be raised. Conversely the body parameters are part of the request; if they are invalid a 400 Bad Request.

cherrypy._cpdispatch.validate_translator(t)