Skip to Content.
Sympa Menu

mace-opensaml-users - RE : SAXParseException?

Subject: OpenSAML user discussion

List archive

RE : SAXParseException?

Chronological Thread 
  • From: Laurent CHARTIER <>
  • To:
  • Subject: RE : SAXParseException?
  • Date: Fri, 27 Apr 2007 16:30:42 +0200
  • Importance: Normal

I had the same problem using XMLHelper.nodeToString().

Now I'm using:

StringWriter responseWriter = new StringWriter();
XMLHelper.writeNode(samlResponse.getDOM(), responseWriter);

And then the encoding is now UTF-8.

-----Message d'origine-----
De : Paul Hethmon

Envoyé : vendredi 27 avril 2007 16:25
À :

Objet : RE: SAXParseException?

Ok. I've been digging into this all week and have it narrowed down to
the XML declaration. In my code, I'm using XMLHelper.nodeToString() to
convert my AuthnRequest to XML before base64 encoding and putting it
into my form. Essentially what the HTTPPostEncoder does. This results in
an XML declaration of:

<?xml version="1.0" encoding="UTF-16"?>

Seems reasonable and it gets sent and base64 decoded successfully. At
this point though, is when the error is thrown when I try to decode it
using the HTTPPostDecoder. So for fun, I went into my XML on the sending
side and removed the encoding param. Now, xerces will successfully parse
it and I end up with a valid AuthnRequest object on the receiving side.

It seems that xerces is looking for UTF-16, but not finding valid UTF-16
and so throws the "Content not allowed in prolog" error.

So I'm still digging here. This is an area that I'm fuzzy in, dealing
with this level of XML and specifications. So I'm hoping perhaps this
rings a bell for someone who can provide me with a clue.

I'm actually using a copy of Xerces I built from the Apache svn
repository yesterday. That may be good or bad, not sure.



-----Original Message-----
From: Paul Hethmon

Sent: Wednesday, April 25, 2007 1:28 PM

Subject: RE: SAXParseException?

I don't think I'm doing that. In this case, I'm building the
AuthnRequest object in code, then marshalling it to the XML and encoding
for the HTTP POST. So I see encoding="UTF-16" on the sending side. On
the receiving side, I see the same encoding.

I guess I'll go down the path of compiling xerces to see if I can pull
out some additional information on what it thinks it sees.


-----Original Message-----
From: Chad La Joie

Sent: Wednesday, April 25, 2007 12:47 PM

Subject: Re: SAXParseException?

Paul, I have seen this error before when I mistakenly encoded the actual
file I was pulling my SAML from in one manner and then had a different
encoding specified in the XML prolog. I think for me I did something
like encode with UTF-8 and then mistakenly put US-ASCII as the encoding.
So, when I looked at the file and the hex it all looked fine but the
parser was thinking it was something totally different.

Paul Hethmon wrote:
> Ok, so I had this working a few weeks ago and can't figure out what
> changed. I've got a snapshot of the opensaml2 libraries as of about
> March 23rd that builds (mostly, at least I didn't change much). I'm
> creating an AuthnRequest in one application and passing it to my Idp.
> When the Idp goes to decode the incoming HTTP form post, it is
> the exception:
> org.xml.sax.SAXParseException: Content is not allowed in prolog.
> So I went back to opensaml2 code and added another logging statement
> actually print out the base64 decoded value from SAMLRequest. I don't
> see anything wrong with it, looking at the plain text or flipping the
> view to hex to make sure there are no "unprintable" characters. From
> code, I'm calling HTTPPostDecoder.decode().
> So the code snippet looks like:
> HTTPPostDecoder decode = new HTTPPostDecoder();
> decode.setParserPool( new ParserPool() );
> decode.setRequest( request );
> decode.decode();
> Any thoughts on where to look next?
> thanks,
> Paul
> Paul Hethmon
> cell: 865.250.3517
> work: 865.769.0456

Chad La Joie 2052-C Harris Bldg
OIS-Middleware 202.687.0124

Ce message est protégé par les règles relatives au secret des
correspondances. Il est donc établi à destination exclusive de son
destinataire. Celui-ci peut donc contenir des informations confidentielles.
La divulgation de ces informations est à ce titre rigoureusement interdite.
Si vous avez reçu ce message par erreur, merci de le renvoyer à l'expéditeur
dont l'adresse e-mail figure ci-dessus et de détruire le message ainsi que
toute pièce jointe.

This message is protected by the secrecy of correspondence rules. Therefore,
this message is intended solely for the attention of the addressee. This
message may contain privileged or confidential information, as such the
disclosure of these informations is strictly forbidden. If, by mistake, you
have received this message, please return this message to the addressser
whose e-mail address is written above and destroy this message and all files

Archive powered by MHonArc 2.6.16.

Top of Page