
<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:50 PM, Brent Putman wrote:<br>

    </div>

    <blockquote cite="mid:56B3D5AA.308@georgetown.edu" type="cite">

      <meta content="text/html; charset=windows-1252"

        http-equiv="Content-Type">

      <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.  </blockquote>

    <br>

    Some quick googling suggests the answer: It's behavior defined by

    the servlet spec.  See Section 3.1.1.  When it's

    "application/x-www-form-urlencoded", then essentially any call to

    any of the request getParameter* methods prior to calling

    getInputStream() results in the request body being consumed, in

    order to populate the request parameter set with the form params. 

    After that, the body can no longer be read, so the input stream is

    null or at least the i/o cursor is at the end of the stream or

    something.<br>

    <br>

    We are not calling getParameter() that I can see, but I imagine

    something in the MVC or SWF layer is (like make checking for flow

    execution key or something?).  So that pretty much explains it I

    think.<br>

    <br>

  </body>

</html>