We've always had issues with unicode urls (specifically machine names with non ascii characters). There are potentially a few problems in TG/cherrpy that are causing this.
Created attachment 439251 [details] output The 'historysearch' widget in this deubg has an incorrectly encoded value as its action string.
Created an attachment (id=439305) Patch: decode fqdn parameter for view() if necessary
The problem here is twofold: Kid works exclusively in unicode, so it expects template data to be passed in as unicode objects. If you do pass it a str, it will decode it using the encoding set in the `assume_encoding` attribute of the template (/usr/lib/python2.4/site-packages/kid/codewriter.py:581), with a default of sys.getdefaultencoding() (/usr/lib/python2.4/site-packages/kid/__init__.py:424) which is 'ascii'. TurboGears lets you configure the `assume_encoding` attribute for normal templates (and by default it sets it 'utf8'), but the code path for widget templates is completely different and it never sets `assume_encoding` (/usr/lib/python2.4/site-packages/turbogears/widgets/base.py:180), so it will always be 'ascii'. So then the problem becomes, we are passing in a raw str (with UTF-8 bytes) as the action attribute for the historysearch widget (Server/bkr/server/controllers.py:909). That's because the fqdn argument is passed as a raw str by cherrypy *if* it comes from the virtual path, as in /view/example.asdf.com. It's correctly decoded as UTF-8 when it's a query param though, as in /view/?fqdn=example.asdf.com. The attached patch is a dodgy solution to the problem, in that it only fixes this one particular instance (which is unlikely to occur, since we don't normally have non-ASCII chars in a hostname). It doesn't help any of the other situations where we are using cherrypy's virtual path mapping. So it's probably not worth applying this particular patch, although we should maybe think about a more general solution for decoding controller params that come from a virtual path.
In general we should make sure to decode controller params correctly where needed. But for this particular case it is no longer an issue, now that we are validating system fqdns as (ASCII-only) hostnames: bug 624857. Closing this bug.