Clicking on git changesets fails: 'name' must be bytestring, not unicode URL

Issue #24 resolved
Michael DePalatis created an issue

When clicking on a changeset in a git repository, I get a 500 Internal Server Error page. This is running Kallithea via uwsgi. The key error appears to be related to unicode being passed instead of a bytestring:

Error - <type 'exceptions.TypeError'>: 'name' must be bytestring, not unicode

The full output from uwsgi including traceback is attached.

Comments (8)

  1. Mads Kiilerich

    Do you see that on all changesets or only on ones with non-ascii chars?

    Is the server side running with LANG=C (which could explain this) or is it using UTF-8?

  2. Michael DePalatis reporter

    I tried clicking on several commits in git repositories, and they all give the 500 error. Interestingly, this does not happen with any Mercurial repositories. Clicking on those commit summaries shows the full commit message as well as the diffs as expected.

    If you mean the LANG environment variable, I see en_US.UTF-8 when I echo $LANG.

  3. Mads Kiilerich

    Weird - in other setups it works.

    Are you sure you are looking at the LANG in exactly the right "context"? You can try to check /proc/XXX/environ .

    Do this mitigate the problem?

    --- a/kallithea/lib/vcs/backends/git/
    +++ b/kallithea/lib/vcs/backends/git/
    @@ -27,11 +27,11 @@ class GitChangeset(BaseChangeset):
         def __init__(self, repository, revision):
             self._stat_modes = {}
             self.repository = repository
    +        revision = safe_str(revision)
    -            commit = self.repository._repo[str(revision)]
    +            commit = self.repository._repo[revision]
                 if isinstance(commit, objects.Tag):
    -                revision = commit.object[1]
    +                revision = safe_str(commit.object[1])
                     commit = self.repository._repo.get_object(commit.object[1])
             except KeyError:
                 raise RepositoryError("Cannot get object with id %s" % revision)
  4. Michael DePalatis reporter

    The patch solves the problem. Thanks!

    For completeness, I also checked that /proc/XXX/environ contained the proper LANG variable, which it does (i.e., en_US.UTF8).

  5. Mads Kiilerich

    Yes, we are hoping to get a release out soon.

    I can recommend running from a repo checkout. I make sure that is so stable that I can use it in production. You can make it (and the next release) even better if you help verify that.

  6. Log in to comment