[Zope-dev] Re: [Zope-Coders] Re: [Zope-Checkins] CVS: Zope/lib/python/ZPublisher - xmlrpc.py:1.14

[Casey Duncan]

I agree that error values containing html are pretty evil, but I think th=
ey go=20
back to the days before we had any notion of using Zope beyond direct web=
=20
publishing. Many of these originate from the response object itself, so I=
=20
plan to override them in the xml-rpc reponse class.

In any case, in the process of refactoring my first try (below) at untang=
ling=20
error values in xmlrpc, I found a small diamond in the rough that is wort=
h=20
pointing out:

Zope response objects have a class attribute "_error_format" that is set =
to=20
"text/plain" in BaseResponse and overridden as "text/html" in HTTPRespons=
e. I=20
overrode it back to "text/plain" in xmlrpc.Response in my latest check-in=
=2E=20
Zope's top level exception handler (in Zope/__init__.py) sniffs this valu=
e=20
and only fires off the rendering of standard_error_message if=20
response._error_format is 'text/html'. So this change alleviates much of =
the=20
noise in the xmlrpc fault string and eliminates the need for much of the=20
formatting hacks I put in.

The refactored xmlrpc exception handler still strips tags from the=20
error_value, I could be convinced to escape them instead, if that's what=20
user's would prefer. In any case I plan to fix the most egregious offende=
rs=20
(like not found errors) entirely by making them a plain text message for=20
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
> >=20
> > Modified Files:
> > =09xmlrpc.py=20
> > Log Message:
> > Improved error output for xmlrpc faults
> >=20
> >  - Value is stripped of HTML tags and minimally formatted
> > +            # Strip HTML tags and format the error value
> > +            v =3D str(v)
> > +            v =3D re.sub(r"<br\s*/?>", "\n", v)
> > +            remove =3D [r"<[^<>]*>", r"&[A-Za-z]+;"]
> > +            for pat in remove:
> > +                v =3D re.sub(pat, " ", v)
> > +            v =3D re.sub(r"\n(?:\s*\n)+", "\n\n", v)
> > +               =20
> > +            from Globals import DevelopmentMode
> > +            if DevelopmentMode:
> > +                from traceback import format_exception
> > +                value =3D ''.join(format_exception(t, v, tb))
> > +            else:
> > +                value =3D '%s\n\n%s' % (t, v)
> > +               =20
>=20
> 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.
>=20
> Florent