[Approved] Ignore whitespace when parsing SOAP messages (1 Viewer)

[Albert]

AW: Ignore whitespace when parsing SOAP messages

Thanks very much McGoober. I'll have a look at the xsi namespace and why it I write it into the description documents.

The usage of the extra xmlns:dt? namespaces is according to the UPnP/1.1 specification. See UPnP-arch-DeviceArchitecture-v1 1-20081015.pdf, page 56. So I guess we just have to tell the devs of the DeveloperTools to fix their implementation.

 

[Smeulf]

Re: AW: Ignore whitespace when parsing SOAP messages

Thanks very much McGoober. I'll have a look at the xsi namespace and why it I write it into the description documents.

The usage of the extra xmlns:dt? namespaces is according to the UPnP/1.1 specification. See UPnP-arch-DeviceArchitecture-v1 1-20081015.pdf, page 56. So I guess we just have to tell the devs of the DeveloperTools to fix their implementation.

From the UPnP-arch-DeviceArchitecture (still page 56, and 57 ) :

To allow run-time schema processing of
extended data types, an optional location of the extended data type schema MAY be expressed in the SCPD using the standard
XSD xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes as defined in section 4.3.2 of XML Schema Part

<scpd xmlns="urn:schemas-upnp-org:service-1-0"
xmlns:dt="urn:domain-name:schema-name"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:domain-name:schema-name
http://some.company.com/dir/file.xsd"
configId="configuration number">

I think this is why you declared it in the XML doc, you just didn't passed any xsi:schemaLocation value. I don't know if it creates the problem...

Cheers.

 

[Albert]

AW: Ignore whitespace when parsing SOAP messages

Yes, maybe that's the reason why I added the xmlns:xsi attribute. But as we don't provide XML schemas for our extended data types, we don't need the xsi:schemaLocation/xsi:noNamespaceSchemaLocation and so we don't need the xmlns:xsi attribute.

 

[McGoober]

Agreed.

 

[Albert]

AW: Ignore whitespace when parsing SOAP messages

I removed the xsi namespace from the description documents.

McGoober, do you have time to tell the devs of DeviceSpy or of their UPnP infrastructure code the problem in their code? Alternatively, can you tell me where in their code the problem occurs? Then I will check it and then tell them the problem.

Thanks!

 

[McGoober]

Awesome, yep let me deal with UPNP Developer Tool guys.

 

[McGoober]

I've just written this to the UPNP Developer Tools guys at Intel... Hope we get a response soon.

I'm working on an open source project called MediaPortal MEDIAPORTAL - a HTPC Media Center for free!
specifically the latest development build of MediaPortal 2 (MediaPortal 2 - MediaPortal Wiki). It uses UPNP as a backend protocol and implements UPNP/1.1.

Whilst trying to use DeviceSpy on Windows 7 to get UPNP information from MediaPortal 2 Server, no MediaPortal device was shown in DeviceSpy's discovered devices list. Further investigation included running DeviceSpy on Windows XP, this time DeviceSpy showed an open dialog asking for an extended data type schema. After extending the investigation by debugging both MediaPortal and DeviceSpy, I discovered that DeviceSpy attempts to load schemas for extended data types by using an open dialog in the following piece of code...

Code from Global/UPnP/UPnPService.cs line 2428
....
if (loadSchema)
{
// Prompt Application for local Schema Location
System.Windows.Forms.OpenFileDialog fd = new System.Windows.Forms.OpenFileDialog();
....

Whilst debugging on Windows 7 I received the following exception...

System.Threading.ThreadStateException
Current thread must be set to single thread apartment (STA) mode before OLE calls can be made. Ensure that your Main function has STAThreadAttribute marked on it. This exception is only raised if a debugger is attached to the process.
at System.Windows.Forms.FileDialog.RunDialog(IntPtr hWndOwner)
at System.Windows.Forms.CommonDialog.ShowDialog(IWin32Window owner)
at OpenSource.UPnP.UPnPService.ParseSCPD(String XML) in E:\\Users\\Jason Leonard\\Work\\DeveloperToolsForUPnP\\Global\\UPnP\\UPnPService.cs:line 2434
at OpenSource.UPnP.UPnPDeviceFactory.httprequestor_OnRequestCompleted(HttpRequestor sender, Boolean success, Object tag, String url, Byte[] data) in E:\\Users\\Jason Leonard\\Work\\DeveloperToolsForUPnP\\Global\\UPnP\\UPnPDeviceFactory.cs:line 197"

After some reading online, it became clear that the OpenFileDialog object uses COM interop underneath but it's being called from a MTA threading model (multi-thread apartment).

I'm currently unsure on the fix for the issue, but I believe it is affecting DeviceSpy and possibly other UPnP developer tools on both Windows Vista and Windows 7 platforms when using UPNP/1.1 and extended data types.


Thanks for your time with this issue.