Board index » delphi » XML document must have a top level element

2008-01-17 06:09:27 AM
delphi48
I'm hoping someone has some insight they can offer on a bizarre situation I am facing.
I have a Delphi Win32 ISAPI Web Service compiled in October last year that when hosted in IIS on my local PC can be successfully called by both Delphi and Java clients.
Today, I simply recompile with no changes to the source code and no updates to Delphi. Now, only the Delphi client can call the web service. The Java client gets a SOAP fault "XML document must have a top level element". In addition, the response has extra text at the beginning that last year's version does not
"--MIME_boundaryB0R9532143182121
Content-Type: text/xml
nContent-ID: <www.borland.com/rootpart.xml>
Content-Location: www.borland.com/rootpart.xml
Content-Length: 479"
So I guess something has changed but I don't know what could be causing Delphi to emit different binary code.
The PCs at work have updates pushed to them automatically, but Delphi is not subject to these.
I'm at a loss. Any and all suggestions gratefully received!
Thanks in advance.
Mark
 

Hello,
This is just a guess but I would be curious to know if somehow maybe MSXML was
updated. This could happen is a new version of IE was installed.
Unfortunately, this error is rather common (as a Google search reveals).
What version of Delphi are you using? And what version of MSXML is installed
on the machine?
Cheers,
Bruneau.
 

Hi Jean-Marie,
Easy question 1st. Dev environment is Turbo Delphi 2006 with Delphi 2007 SOAP patches.
MSXML on the server (= Delphi client = Development PC) is v8.0.7002.0
MSXML on the Java client is the same. i.e. v8.0.7002.0
I don't see how the version of MSXML could be the problem as the Java client can call the old (October 2007) version of the DLL no problem. When I recompile the DLL now, the Java client gets the SOAP fault. No change in MSXML (or any DLL for that matter) on the client or server.
Unless the version of MSXML on the Dev PC could affect the code emitted by the Delphi compiler? It is possible that the versions could have changed in the last 3 months. Doubtful though, as the date on MSXML is Aug 2004.
Another bit of information... The Delphi client runs fine from the PC that the Java client runs from.
Thanks
Mark
"Jean-Marie Babet" <XXXX@XXXXX.COM>writes:

"Jean-Marie Babet" <XXXX@XXXXX.COM>writes
beginning to chew on xml pretty hard and it would be a bear
to run into glitches like Mark described.
Can you give (or point to) a rundown of the differences,
"gotchas", and workarounds?
Dan <sigh>
 

Well the Java boys have worked out what's happening.
The problem is with the request header...
POST /ISAPI/RIInternetPolicyWSIsapi.dll/soap/RIPolicyWebService HTTP/1.1
SOAPAction: ""
User-Agent: Jakarta Commons-HttpClient/3.0
Host: nu11068:9090
Expect: 100-continue
Content-Length: 625
<?xml version="1.0" encoding="UTF-8"?><soapenv:Envelope xmlns:soapenv="schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="www.w3.org/2001/XMLSchema" xmlns:xsi="www.w3.org/2001/XMLSchema-instance"><soapenv:Body><ns1:GetPolicyDetails soapenv:encodingStyle="schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="urn:RIPolicyWebServiceIntf-RIPolicyWebService"><PolicyNo xsi:type="xsd:string">6767640</PolicyNo><UserID xsi:type="xsd:string">WEB01</UserID><Password xsi:type="xsd:string">WEBPWD</Password><Environment xsi:type="xsd:string">USR</Environment></ns1:GetPolicyDetails></soapenv:Body></soapenv:Envelope>
Note that there is no value for SOAPAction and no Content Type string. With these values correctly populated, the call works.
The only question outstanding (and an answer is not critical because everything is working now) is why the old version of the webservice is more resilient to these missing fields in the request header? I know I haven't applied any patches to Delphi in the last few months.
{*word*76}y Java clients! I spit on Java...
Thanks to all who took an interest.
Mark
"Mark Weston" <XXXX@XXXXX.COM>writes:

Hello,
Thank you for the follow-up post detailing your findings.
While Delphi WebServices use the SOAP-Action to dispatch, we don't rely on
it. IOW, if the SOAPAction header is missing, we'll try to dispatch using
the request's pathinfo. There's a little comment in WebBrokerSOAP.pas to
that effect:
"... { Get the path to which client posted - SOAPAction may not tell us
which porttype to dispatch to; we'll then use the path }..."
And as far as Content-Type is concerned, if I remember correctly, we don't
enforce it either; however, we'll throw an exception on the common
unacceptable ones. IOW, we don't ensure that we receive 'text/xml' but we
check for 'text/plain' and 'text/html' and bail out on these. The net result
is that we'll keep chugging if it is missing.
Unfortunately none of the above really solves the mystery. Short of having
captured the old and new request/response packets, it may not be easy to
explain this issue. However, I am glad it is resolved. I have always felt that
being lenient/resilient was a good approach but that has not always been the
case. A error about 'missing SOAPAction header' (as many SOAP
implementations do) would have been wonderful here...
Cheers,
Bruneau.