doc/bugs/pythonproxy-utf8_again.mdwn

   1 [[!template  id=gitbranch branch=chrysn/more-proxy-utf8-fail author="[[chrysn]]"]]
   2
   3 the recently introduced fixes for [[crashes in the python proxy even if disabled]]
   4 caused the typical python2 implicit conversion failures ("'ascii' codec
   5 can't...") on my debian sid system -- to fix it, i had to revert commit 154c4ea9e.
   6
   7 i did not dig down all the way to the xml / xmlrpc modules, but my impression
   8 is that some module changed its behavior between stable and sid and now
   9 generates `unicode` strings instead of `str`.
  10
  11 a [[patch]] to allow both versions by inspecting the types and en-/decoding on
  12 demand should work both for anarcat's and my case. i did not test the python3
  13 version, but i'm pretty sure it was already broken after the abovementioned
  14 patch.
  15
  16 -- [[chrysn]]
  17
  18 > update 2014-06-29: the problem persists, but i found it is not trivial to
  19 > reproduce. to demonstrate, use this test plugin:
  20 >
  21 >    #!/usr/bin/env python
  22 >    # -*- coding: utf-8 -*-
  23 >
  24 >    from proxy import IkiWikiProcedureProxy
  25 >
  26 >    def preprocess(self, proxy, *args):
  27 >        return repr(self.rpc('pagetype', 'schön'))
  28 >
  29 >    proxy = IkiWikiProcedureProxy(__name__)
  30 >    proxy.hook('preprocess', preprocess, id='testdirective')
  31 >    proxy.run()
  32 >
  33 > note that when the 'schön' is stored in a variable, the exception changes --
  34 > it seems to me that the issue is related to the way exceptions are encoded.
  35 >
  36 > the suggested patch still applies and solves the issue. --[[chrysn]]
  37
  38 >> In this patch band:
  39 >>
  40 >>     -        xml = _IkiWikiExtPluginXMLRPCHandler._read(in_fd).decode('utf8')
  41 >>     +        response = _IkiWikiExtPluginXMLRPCHandler._read(in_fd)
  42 >>     +        if isinstance(response, unicode):
  43 >>     +            xml = response.encode('utf8')
  44 >>
  45 >> I think you mean `response.decode`, not `response.encode`.
  46 >>
  47 >> Other than that it looks good to me. I like the use of `repr` in debug
  48 >> messages. --[[smcv]]