log.debug unicode encoding problem in transport/http.py

Issue #32 new
Cody Wilbourn
created an issue

I was using this library to connect to a WSDL endpoint, and would occasionally get back errors

Traceback (most recent call last):

File "/usr/lib/python2.7/logging/handlers.py", line 77, in emit if self.shouldRollover(record):

File "/usr/lib/python2.7/logging/handlers.py", line 156, in shouldRollover msg = "%s\n" % self.format(record)

File "/usr/lib/python2.7/logging/init.py", line 723, in format return fmt.format(record)

File "/usr/lib/python2.7/logging/init.py", line 464, in format record.message = record.getMessage()

File "/usr/lib/python2.7/logging/init.py", line 328, in getMessage msg = msg % self.args

File "/data/virtualenvs/soap/local/lib/python2.7/site-packages/suds/init.py", line 168, in <lambda> str = lambda x: unicode(x).encode('utf-8')

File "/data/virtualenvs/soap/local/lib/python2.7/site-packages/suds/transport/init.py", line 96, in unicode %s""" % (self.code, self.headers, self.message)

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 32653: ordinal not in range(128)

I think I tracked it down to line 86 in transport/http.py log.debug('received:\n%s', reply)

Setting suds.transport explicitly to INFO logging avoided the error.

Comments (7)

  1. Ben Spaulding

    I recently ran into this problem. SOAP messages I was receiving contained non-ASCII characters. When logging to a file multiple UnicodeDecodeErrors would be raised. Trying to troubleshoot this, I learned something I never knew: you should generally only send Unicode to logging. It seems that byte-strings can cause trouble. The below is definitely not a tested fix, but it resolved the issue for me.

    diff --git a/suds/client.py b/suds/client.py
    --- a/suds/client.py
    +++ b/suds/client.py
    @@ -627,11 +632,11 @@
             if status in (httplib.ACCEPTED, httplib.NO_CONTENT):
             failed = True
                 if status == httplib.OK:
    -                log.debug('HTTP succeeded:\n%s', reply)
    +                log.debug('HTTP succeeded:\n%s', reply.decode('utf-8'))
                     log.debug('HTTP failed - %d - %s:\n%s', status, description,
                 # (todo)
    diff --git a/suds/sax/parser.py b/suds/sax/parser.py
    --- a/suds/sax/parser.py
    +++ b/suds/sax/parser.py
    @@ -130,7 +130,7 @@
             if string is not None:
                 source = InputSource(None)
    -            suds.metrics.log.debug('%s\nsax duration: %s', string, timer)
    +            suds.metrics.log.debug('%s\nsax duration: %s', string.decode('utf-8'), timer)
                 return handler.nodes[0]
    diff --git a/suds/transport/__init__.py b/suds/transport/__init__.py
    --- a/suds/transport/__init__.py
    +++ b/suds/transport/__init__.py
    @@ -91,11 +91,11 @@
         def __unicode__(self):
             return u"""\
     CODE: %s
     HEADERS: %s
    -%s""" % (self.code, self.headers, self.message)
    +%s""" % (self.code, self.headers, self.message.decode('utf-8'))
     class Transport:
         """The transport I{interface}."""
    diff --git a/suds/transport/http.py b/suds/transport/http.py
    --- a/suds/transport/http.py
    +++ b/suds/transport/http.py
    @@ -84,11 +84,11 @@
                 if sys.version_info < (3, 0):
                     headers = fp.headers.dict
                     headers = fp.headers
                 result = Reply(httplib.OK, headers, fp.read())
    -            log.debug('received:\n%s', result)
    +            log.debug(u'received:\n%s', result)
             except urllib2.HTTPError, e:
                 if e.code in (httplib.ACCEPTED, httplib.NO_CONTENT):
                     result = None
                     raise TransportError(e.msg, e.code, e.fp)

    Vinay Sajip: http://bugs.python.org/issue6991#msg93114
    Gregory Szorc: https://bugzilla.mozilla.org/show_bug.cgi?id=921694#c3

    @Jurko Gospodnetić: What are your thoughts on that? Does that seem sensible / right?

    I think I am going to fork the repo and add my changes so that I can proceed with the work I need to do. But I will follow this issue, so please let me know if I can be of any help.

  2. charn

    I ran to this problem with the latest available release 0.6. But it looks like this problem might be already fixed in the current upstream, so maybe this issue could be closed?

  3. Mark Saniscalchi


    I would not recommend closing issues until the release containing the fix(es) is externalized as the current stable version. The issue would still exist for the majority of users, who would be on 0.6.

  4. Log in to comment