Customize the POST encoding format?

[Brent Putman]

On 3/25/17 8:10 PM, Mohamed Lrhazi wrote:
>
> In chrome devtools, I can see that the Post is indeed URL encoded :
>
>
> Content-Type: application/x-www-form-urlencoded
>
> I think this is what this SP is complaining about... but is this not
> expected behavior?
>

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.

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.

An HTML form 'enctype' can only take 3 values 1)
'application/x-www-form-urlencoded', which is the default if 'enctype'
is unspecified 2) ' 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).

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170325/e5e94fae/attachment-0001.html>