to encode a Unicode ``path`` into ASCII before attempting to split it and decode its segments. This is for convenience, effectively to allow a (stored-as-Unicode-in-a-database, or retrieved-as-Unicode-from-a-request-parameter) Unicode path to be passed to ``find_model``, which eventually internally uses the ``traversal_path`` function under the hood. In version 1.2 and prior, if the ``path`` was Unicode, that Unicode was split on slashes and each resulting segment value was Unicode. An inappropriate call to the ``decode()`` method of a resulting Unicode path segment could cause a ``UnicodeDecodeError`` to occur even if the Unicode representation of the path contained no 'high order' characters (it effectively did a "double decode"). By converting the Unicode path argument to ASCII before we attempt to decode and split, genuine errors will occur in a more obvious place while also allowing us to handle (for convenience) the case that it's a Unicode representation formed entirely from ASCII-compatible characters.
-------- - Compatibility with WebOb 1.0. Requirements ------------ - Now requires WebOb >= 1.0. Backwards Incompatibilities --------------------------- - Due to changes introduced WebOb 1.0, the ``repoze.bfg.request.make_request_ascii`` event subscriber no longer works, so it has been removed. This subscriber was meant to be used in a deployment so that code written before BFG 0.7.0 could run unchanged. At this point, such code will need to be rewritten to expect Unicode from ``request.GET``, ``request.POST`` and ``request.params`` or it will need to be changed to use ``request.str_POST``, ``request.str_GET`` and/or ``request.str_params`` instead of the non-``str`` versions of same, as the non-``str`` versions of the same APIs always now perform decoding to Unicode.
``set_notfound_view`` or ``set_forbidden_view`` APIs, the context sent to the view was incorrect (could be ``None`` inappropriately).
``pregenerator`` argument. The pregenerator for the resulting route is called by ``route_url`` in order to adjust the set of arguments passed to it by the user for special purposes, such as Pylons 'subdomain' support. It will influence the URL returned by ``route_url``. See the ``repoze.bfg.interfaces.IRoutePregenerator`` interface for more information.
-------- - A ``request.matched_route`` attribute is now added to the request when a route has matched. Its value is the "route" object that matched (see the ``IRoute`` interface within ``repoze.bfg.interfaces`` API documentation for the API of a route object). - The ``exception`` attribute of the request is now set slightly earlier and in a slightly different set of scenarios, for benefit of "finished callbacks" and "response callbacks". In previous versions, the ``exception`` attribute of the request was not set at all if an exception view was not found. In this version, the ``request.exception`` attribute is set immediately when an exception is caught by the router, even if an exception view could not be found. Backwards Incompatibilities --------------------------- - The router no longer sets the value ``wsgiorg.routing_args`` into the environ when a route matches. The value used to be something like ``((), matchdict)``. This functionality was only ever obliquely referred to in change logs; it was never documented as an API. - The ``exception`` attribute of the request now defaults to ``None``. In prior versions, the ``request.exception`` attribute did not exist if an exception was not raised by user code during request processing; it only began existence once an exception view was found. Deprecations ------------ - References to the WSGI environment values ``bfg.routes.matchdict`` and ``bfg.routes.route`` were removed from documentation. These will stick around internally for several more releases, but it is ``request.matchdict`` and ``request.matched_route`` are now the "official" way to obtain the matchdict and the route object which resulted in the match. Documentation ------------- - Added two sections to the "Hooks" chapter of the documentation: "Using Response Callbacks" and "Using Finished Callbacks". - Added documentation of the ``request.exception`` attribute to the ``repoze.bfg.request.Request`` API documentation. - Added glossary entries for "response callback" and "finished callback". - The "Request Processing" narrative chapter has been updated to note finished and response callback steps.
callbacks are called by the router unconditionally near the very end of request processing.