Bugzilla – Bug 681747
Different web service requests between SL and ML causes request to fail
Last modified: 2011-04-08 08:28:13 UTC
User-Agent: Opera/9.80 (X11; Linux x86_64; U; en) Presto/2.7.62 Version/11.01 Test site: http://moon.sublimeintervention.com/MoonlightDrtViewer/ Login fails (after clicking "Continue" it jumps to the "Graph" tab, then almost immediately back to the "Login" tab, which indicates that the login failed). Please ping me or any other moonlight team member for the correct credentials. Wireshark says that the web service request sent by ML is different from what SL sends. The source code for the test site is here: https://github.com/rolfbjarne/moonlight-drt-viewer/tree/master/MoonlightDrtViewer Reproducible: Always
Request sent by SL: <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <Login xmlns="http://monkeywrench.novell.com/"> <login> <User>xxx</User> <Password>yyy</Password> </login> </Login> </s:Body> </s:Envelope> Request sent by ML: <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Body> <Login xmlns="http://monkeywrench.novell.com/"> <login xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns:d4p1="http://schemas.datacontract.org/2004/07/MoonlightDrtViewer.MonkeyWrench"> <d4p1:Cookie i:nil="true" /> <d4p1:Ip4 i:nil="true" /> <d4p1:Password>yyy</d4p1:Password> <d4p1:User>xxx</d4p1:User> </login> </Login> </s:Body> </s:Envelope>
This requires a couple of fixes regarding how XmlSerializerFormatAttribute should be applied. Full WCF works fine with this attribute, but in Silverlight this type does not reside in System.ServiceModel.dll while all internal dependent code for this attribute depends on System.Xml.Serialization and cannot be fixed without some structural changes. Shouldn't be hard, but not cosmetic. In Silverlight app, System.Xml.Serialization.dll must have corresponding implementation inside, so what's important for our System.ServiceModel.dll is to have consistent behavioral processing model for it.
Turned out that there isn't known Silverlight-compatible way to do it. XmlSerializerFormatAttribute should internally create XmlSerializerOperationBehavior and attach it to OperationDescription.Behaviors. But there is no public XmlSerializerOperationBehavior constructor. There is actually one non-public constructor that takes "OperationReflector" which is totally unknown (i.e. MS internal type), so we cannot even get working XmlSerializerOperationBehavior via FormatterServices.GetUninitializedObject(). The internal access list that we have in moon module does not describe anything related to XmlSerializerFormatAttribute, but I actually found that System.ServiceModel.dll references it (grep the assembly), so it seems that the internal access list is incomplete. Until it gets known, it is not possible to "fix" this issue.