When a request is sent to the CMS server it can specify it wants an xml document as the result as opposed to HTML by setting the HTTP request arg xml=true. In CMSServlet.renderTemplate() the xml flag is checked and if its set to true then it invokes CMSServlet.outputXML() instead of rendering an HTML template. However CMSServlet.renderTemplate() is bypassed when an exception is caught. Instead in the exception catch block CMSServlet.renderExecption() is directly invoked bypassing the logic in CMSServlet.renderTemplate(). CMSServlet.renderExecption() fails to test for the xml output flag, as a consequence even though the client requested xml output instead of HTML, it gets HTML, a truly unanticipated response.
Created attachment 369245 [details] patch
Did you intentionally ignore "xmlOutput" request parameter to provide XML output only if "xml" request parameter is set to true? If no, then you are ignoring your own algorithm provided in bug #531940. (see: https://bugzilla.redhat.com/attachment.cgi?id=369228) If yes, then your patch is fine.
re comment #2 yes this was intentional. The use of "xmlOutput" parameter name is a singular aberration unique to profileSubmit, all other usage is consistently "xml". I'd be happy to see the xmlOutput exception eliminated for consistency sake but I assumed it was important to retain for backward compatibility reasons. Since IPA will have it's own branch perhaps this isn't valid rationale. If these patches make it back into the main CMS code base then this would be an issue.
Patch included in in bug #533979 (attachment #373874 [details]) is committed.