diff options
| author | Chris McDonough <chrism@agendaless.com> | 2010-09-24 22:10:00 +0000 |
|---|---|---|
| committer | Chris McDonough <chrism@agendaless.com> | 2010-09-24 22:10:00 +0000 |
| commit | 841313c5ff30e9c7322b230051d1a099d3369461 (patch) | |
| tree | f05de38fea3a6e954cbd77f543307092ff731796 /docs/tutorials/bfgwiki2/src/basiclayout | |
| parent | f0fc3e5c1dee40d4262a85204c356516d1d2ea5a (diff) | |
| download | pyramid-841313c5ff30e9c7322b230051d1a099d3369461.tar.gz pyramid-841313c5ff30e9c7322b230051d1a099d3369461.tar.bz2 pyramid-841313c5ff30e9c7322b230051d1a099d3369461.zip | |
- The ``repoze.bfg.traversal.traversal_path`` API now eagerly attempts
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.
Diffstat (limited to 'docs/tutorials/bfgwiki2/src/basiclayout')
0 files changed, 0 insertions, 0 deletions
