The API help message seems to be abusing the XML pretty-printer, assuming that output will be partially de-escaped. This is fairly rude. :)
Now that the pretty-printer isn't a security hazard, it's formatting output correctly; that is, as given.
In theory we could special-case the pretty-printer, but I suspect it would more sense to just have an HTML interface for this? The URL detection in particular is very fragile as back-interpreting the original code is going to depend on how that particular formatter treats all kinds of characters.
Well, the only characters that really seem to be causing problems in the links are ampersands. Could we maybe just special-case these for now?
I really think it would make much more sense just to provide, as you suggested, our own html, not formatted xml, help document at the entry point, but I believe the reason Yuri wanted to do it this way was so that we would be handing back valid xml when an error occurs (the help message is shown on all errors). It would, however, make more sense to me for an error just to return a simple doc indicating the error, and only display the help document when the api is accessed without any parameters.
(In reply to comment #3)
It would, however, make more sense to me for an error just to return a
simple doc indicating the error, and only display the help document when the
api is accessed without any parameters.
This has been discussed before. It was agreed (and implemented) that the help document be shown only if the requested format is an FM (fancy markup) format. If not, the help text will not be shown unless the users explicitly requests it with action=help. See also:
(In reply to comment #5)
Committed r25922, which is a temporary fix for this. Leaving the bug open until
we find a better solution (most likely, a fully html version of the help).
Sorry, that was r25923