<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 9:45 PM, John Dennis wrote:<br>
</div>
<blockquote cite="mid:56B40CE2.9080005@redhat.com" type="cite"><br>
<br>
Therefore since ECP requires SOAP 1.1 (not SOAP 1.2) and SOAP 1.1
requires 'text/xml' and because RFC 3902 reserves
'application/soap+xml' for SOAP 1.2 the media type should be
'text/xml' not 'application/soap+xml'.
<br>
</blockquote>
<br>
Yes, agree. I don't recall anyone mentioning application/soap+xml,
but if we did, for the record, we meant text/xml. :-) Nothing in
SAML protocol that I know of is defined for SOAP 1.2.<br>
<br>
<blockquote cite="mid:56B40CE2.9080005@redhat.com" type="cite">
<br>
Also, curl cannot know what the Content-Type should be when doing
a post. But since the vast majority of posts made with curl are
application/x-www-form-urlencoded it defaults to that Content-Type
as a friendly favor if you do a post but fail to provide an
explicit Content-Type header. So it's not really a fault of curl
unless you believe friendly defaults are evil.
<br>
</blockquote>
<br>
I don't disagree with its default behavior. Just saying that it
doesn't enforce sanity on the value you send. Which it can't, as you
point out.<br>
<br>
In the decoder, depending on the stated type as a guarantee that
it's that type and that you can parse it doesn't really work. Even
more so if the main concern is security-related and is about the
danger of parsing "unknown" potentially malicious content.<br>
</body>
</html>