<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 3/25/17 8:10 PM, Mohamed Lrhazi
wrote:<br>
</div>
<blockquote
cite="mid:CAOm-VQ4KbuiE0cExV6bmOM+yMPE9xiCakdS=ofDvfRwWpi=e_Q@mail.gmail.com"
type="cite">
<div dir="auto">
<div dir="ltr"><br>
<div>In chrome devtools, I can see that the Post is indeed URL
encoded :</div>
<div><br>
</div>
<div>
<div style="font-size:12.8px"><br
class="m_3619661752355433206gmail-Apple-interchange-newline">
Content-Type: application/x-www-form-urlenco<wbr>ded</div>
<div style="font-size:12.8px"><br>
</div>
</div>
<div>I think this is what this SP is complaining about... but
is this not expected behavior?</div>
<br>
</div>
</div>
</blockquote>
<br>
Indeed, that is the expected behavior. That's the default enctype
of an HTML form POST. So there literally *is* URL encoding going on
from their perspective, but it isn't being done by *us*, it's being
done by the browser, when it actually auto-POSTs the form that we
send back.<br>
<br>
This is such an obvious thing that I wasn't even thinking about it.
I assumed they thought we were URL-encoding what we put into the
form (we aren't) and that was resulting in double encoding, or
something like that. If that is really what they are complaining
about (you should ask them)... I think they have a conceptual
misunderstanding.<br>
<br>
An HTML form 'enctype' can only take 3 values 1)
'application/x-www-form-urlencoded', which is the default if
'enctype' is unspecified 2) '
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
multipart/form-data', used for uploading files, etc, and I'm sure
they're not expecting that one. 3) at least in HTML 5 it can take
apparently 'text/plain'. I've personally literally never seen the
latter, in SAML or otherwise. I'm not sure it would even work for
the SAML POST binding. And even if it did, my experience strongly
argues that that value it is not required or even expected by really
anybody (except apparently maybe this vendor).<br>
<br>
More importantly, the normative SAML bindings spec doesn't even
mention any specified use of 'enctype', and their examples omit
'enctype' entirely, which means the POST defaults to
'application/x-www-form-urlencoded'. So that's really probably the
answer here for them: The spec (implicitly) assumes
'application/x-www-form-urlencoded'. If the vendor doesn't support
that, then they are broken.<br>
<br>
On a practical level, I don't know why they would even care about
this anyway, since virtually every server-side web library/framework
with which I am familiar automatically URL-decodes form POST data.
You often have to actually go out of your way and work hard(er) to
even get at the raw pre-decoded data. So if this is really what
they mean, I don't know what their problem is.<br>
</body>
</html>