<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 5:23 PM, Brent Putman wrote:<br>
    </div>
    <blockquote cite="mid:56B3CF4E.9000601@georgetown.edu" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <br>
      Yeah, so with the right content type, does the IdP still log the
      same XML parsing error?  If so, I'm at a loss.  Need to confirm,
      b/c it's entirely possible that it's getting past the parsing but
      then throwing a fatal error which results in the 500 and SOAP
      fault you previously posted, for example something specific to the
      authN or ECP case.  For example, not sure off-hand what that would
      return if for example basic authN isn't configured correctly and
      so there's no REMOTE_USER visible in the request. <br>
    </blockquote>
    <br>
    <br>
    I hate flying blind, so I grabbed that aws.plugin.bash script,
    ripped out what wasn't relevant to just making the ECP request, and
    ran it against my v3 IdP.  With no explicit content type header, it
    sends application/x-www-form-urlencoded, and that results in the XML
    parsing error.<br>
    <br>
    With the text/xml, it actually "works", in that it gets past the XML
    parsing and the decoding step.  (It then fails with a 500 and SOAP
    fault b/c I don't have other stuff configured, but that's ok, that's
    expected.)<br>
    <br>
    So I don't know *why* the parsing fails with the wrong content type;
    IdP/OpenSAML doesn't look at it AFAIK.  I suspect it's something
    non-obvious in the servlet container layer, or Spring MVC or SWF
    that's mucking with what we see in the request.  Which IIRC is what
    we thought before, but can't remember if anyone actually figured it
    out yet.  But the workaround for now is to explicitly send the
    content type and that should work as far as the fundamental message
    processing goes.<br>
    <br>
    I suspect you've now got that part working, and you've now got some
    other issues with ECP or authN or profile config that's resulting in
    the 500 and fault, that you need to sort out. So the logs are your
    friend there...<br>
    <br>
    <br>
  </body>
</html>