<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">On 2/4/16 3:53 PM, Cantor, Scott wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112823F01@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap="">Thanks. Maybe Brent has an obvious insight, but I haven't figured out why
our decoding logic would be behaving that way in this situation.</pre>
</blockquote>
</blockquote>
<br>
Unless we know otherwise, I'd trust that the log is correct and the
request body really isn't valid XML...<br>
<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE112823F01@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
<blockquote type="cite">
<pre wrap=""> I don't know
if we even look at Content-Type, and if we did, we'd have a clear error. All I
see is the code passing the request stream from the servlet into the XML
parser. I don't understand how that causes that error on both containers yet.
It's very odd.
</pre>
</blockquote>
<pre wrap="">
We probably figured this out months ago, the problem is just the script and use of curl, it defaults the Content Type to form-encoded if you don't set it.</pre>
</blockquote>
<br>
Yes, that rings a bell, and sounds correct to me. <br>
<br>
Since we can't even parse the inbound request, there's no way to get
the regular PROTOCOL_MESSAGE output on the IdP side. But if you can
munge the ECP client script, just adding a "-v" to the curl
invocation should show the actual request on stderr. And will
probably confirm what Scott said.<br>
</body>
</html>