<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 7:03 PM, Cantor, Scott wrote:<br>
</div>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128240E0@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">
Formally speaking, ECP is SOAP and requires that content type. </blockquote>
<br>
Yes, I was going to bring that up. It's technically not valid for a
SOAP/ECP client to not send that.<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128240E0@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite">Practically speaking, the decoding class doesn't
check, and sending anything that doesn't get in the way will work
(I tested with foo/bar, worked fine).</blockquote>
<br>
Yes, it was pretty much ported over from V2 as-is, and it never
checked content type. I guess we were adopting the "be permissive
in what you accept" rule of internet programming. We could actively
enforce the type. However, that leads to the opposite problem:
breaking people who currently don't send anything, or who send the
wrong thing. Don't know which is preferable...<br>
<br>
<blockquote
cite="mid:9846A6064BD102419D06814DD0D78DE1128240E0@CIO-TNC-D2MBX02.osuad.osu.edu"
type="cite"> I believe the SP is pretty strict about that stuff,
just because I don't like having C/C++ code operating on unknown
data if I can avoid it.<br>
</blockquote>
<br>
Philosophically, I agree. Just pointing out, though, that just
because the request carries a Content-Type doesn't mean it actually
*is* that type. Could be broken or lying. Which is exactly what
curl seems to do by default, i.e. I don't think a naked SOAP
Envelope is syntactically (at least not semantically) valid
application/x-www-form-urlencoded (not param/value pairs).<br>
<br>
</body>
</html>