I agree that error values containing html are pretty evil, but I think they go back to the days before we had any notion of using Zope beyond direct web publishing. Many of these originate from the response object itself, so I plan to override them in the xml-rpc reponse class. In any case, in the process of refactoring my first try (below) at untangling error values in xmlrpc, I found a small diamond in the rough that is worth pointing out: Zope response objects have a class attribute "_error_format" that is set to "text/plain" in BaseResponse and overridden as "text/html" in HTTPResponse. I overrode it back to "text/plain" in xmlrpc.Response in my latest check-in. Zope's top level exception handler (in Zope/__init__.py) sniffs this value and only fires off the rendering of standard_error_message if response._error_format is 'text/html'. So this change alleviates much of the noise in the xmlrpc fault string and eliminates the need for much of the formatting hacks I put in. The refactored xmlrpc exception handler still strips tags from the error_value, I could be convinced to escape them instead, if that's what user's would prefer. In any case I plan to fix the most egregious offenders (like not found errors) entirely by making them a plain text message for xml-rpc. -Casey On Friday 30 August 2002 12:16 pm, Florent Guillaume wrote:

Casey Duncan <casey@zope.com> wrote:

...

Update of /cvs-repository/Zope/lib/python/ZPublisher In directory cvs.zope.org:/tmp/cvs-serv24443

Modified Files: xmlrpc.py Log Message: Improved error output for xmlrpc faults

- Value is stripped of HTML tags and minimally formatted + # Strip HTML tags and format the error value + v = str(v) + v = re.sub(r"<br\s*/?>", "\n", v) + remove = [r"<[^<>]*>", r"&[A-Za-z]+;"] + for pat in remove: + v = re.sub(pat, " ", v) + v = re.sub(r"\n(?:\s*\n)+", "\n\n", v) + + from Globals import DevelopmentMode + if DevelopmentMode: + from traceback import format_exception + value = ''.join(format_exception(t, v, tb)) + else: + value = '%s\n\n%s' % (t, v) +

IMHO this goes to show that the error value should never have contained HTML in the first place. I think error values should be defined as pure text, and the HTML publishing would html_quote it as needed, and the XMLRPC publishing would do what it deems.

Florent