Closed Bug 137490 Opened 22 years ago Closed 19 years ago

[Testcase] .NET web service doesn't like namespace prefix in method name

Categories

(Core Graveyard :: Web Services, defect)

Product:
Core Graveyard
Component:
Web Services
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.5alpha

People

(Reporter: christian, Assigned: mozilla)

References

(
URL
)

Details

Attachments

(2 obsolete files) 

Web Services in .NET use the new XSD schema namespace of
http://www.w3.org/2001/XMLSchema (the instance document namespace is
different too).  Thus, calling a Micro$oft .NET web service will not lead to 
the correct result. When calling the web service as shown in example, the web 
service parses the XML as 0, no matter which value was entered. Thus, 
the "prime number checking" web service always returns "no prime". Tested with 
2002041408.
fyi: here is the SOAP call generated by Mozilla:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/" 
env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:xs="http://www.w3.org/1999/XMLSchema" 
xmlns:xsi="http://www.w3.org/1999/XMLSchema-
instance"><env:Header/><env:Body><a0:istPrimzahl 
xmlns:a0="http://tempuri.org/"><zahl 
xsi:type="xs:integer">29</zahl></a0:istPrimzahl></env:Body></env:Envelope>

also fyi: when using the SOAP capabilities of IE, this SOAP call is generated 
(and the correct result is returned):

<?xml version='1.0' encoding='utf-8'?>
<SOAP-ENV:Envelope xmlns="" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" 
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://tempuri.org/" 
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/" 
xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" 
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>
<istPrimzahl xmlns="http://tempuri.org/">
<zahl>29</zahl></istPrimzahl></SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Reassigning to SOAP owner.
Assignee: heikki → rayw
QA Contact: petersen → rakeshmishra
harishd is now maintaining SOAP, reassigning. Harish, Nisheeth, could you
confirm if this really/still happens?
Assignee: rayw → harishd
I've confirmed that this the behavior described in this "bug" still happens. 
But, I'm not sure if the right solution for us is to start sending the new
namespace.  Isn't it true that we would be seen as a SOAP 1.2 client if we sent
out the new namespace?  Since we only support SOAP 1.1, that would send a wrong
message and potentially break us in other ways when SOAP 1.2 servers send SOAP
1.2 only elements back to us in the SOAP response.

Seems to me that the evangelism team needs to get with the .NET web service
folks and see why their SOAP server isn't accepting a valid SOAP 1.1 message.

CCing webfw folks...
Status: UNCONFIRMED → NEW
Ever confirmed: true
duh, i just realized that i mis-spoke in comment 5.  The problem is with XML
schema namespace we are sending, not the SOAP namespace.

But, my concern about advertising the "http://www.w3.org/2001/XMLSchema" XML
Schema namespace remains the same.  If we say that we support this newer XML
schema namespace, it is again possible for a SOAP server to send us back a SOAP
response that contains XML schema elements or attributes that we don't support.
I did more research on this on the W3C and OASIS web sites and realized that the
correct thing for us to do is to start sending out the
"http://www.w3.org/2001/XMLSchema" namespace.  This is the namespace used in the
Public Recommendation of the "XML Schemas: DataTypes" spec.  The
"http://www.w3.org/1999/XMLSchema" namespace we are currently sending out is the
one specified in the fourth and earlier working drafts of the spec.  Once a spec
has become a Public Recommendation, all implementors are supposed to upgrade
their implementations to track it.  Which means we should send out the 2001 XML
Schema namespace.

Changing summary of the bug to reflect this.  Harish, if you are busy, feel free
to re-assign to me.  This one should be an easy one to fix.

For those who are interested, the history of the XML Schema spec is available at
http://www.w3.org/1999/XMLSchema.  It contains links to the seven working
drafts, the candidate recommendation, and the public recommendation.
Summary: [Testcase] SOAP: XSD schema namespace not supported → [Testcase] WSDL should emit "http://www.w3.org/2001/XMLSchema" namespace
Blocks: 190182
It is not entirely that simple.  As presently written, the capability is easily
there to send out either one.  There is already a lot of work in it to solve a
complex situation of the standards.  Please talk to me before changes are made.
Component: XML → Web Services
spoke to harishd about this.  taking...

will talk to rayw and get his input on how this bug should be fixed...
Assignee: harishd → nisheeth
Is there a workaround for this? Even non-WSDL would be fine for now. I tried
lots of things, but I can't make anything work, either with 1.4rc1, phoenix 0.6
or trunk.
The problem I am having is:

"getAssociatedEncoding is not a function". Can anyone help me?
OK, so what we will do here is create a build that emits the new XML Schema
namespace and test it against web services deployed on IBM, MS, and Sun, and BEA
server infrastructure.

Once we've verified that emitting the new schema namespace doesn't break access
to web services hosted on these major platforms, we'll check in the change on
the Mozilla trunk.

Any volunteers on helping test on the above and other platforms, please contact
me.  We are short on QA these days and the cycle time for this bug will be
heavily dependent on how quickly we get these platforms tested.  Thanks!

About to attach the patch that makes Mozilla spit out the new XML Schema
namespace...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.5alpha
I need to dust off my wsdl testcase generator, so I'll use that to test web
services that work currently once there is a patch.
nsSoapEncoding wasn't being exposed to script properly.  Thanks to Harish for
this fix!
With attachment 125552 [details] [diff] [review] in my build, here's the SOAP call generated by Mozilla:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" 
  xmlns:enc="http://schemas.xmlsoap.org/soap/encoding/"
  env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<env:Header/>
<env:Body>
<a0:istPrimzahl xmlns:a0="http://tempuri.org/">
<zahl xsi:type="xs:integer">123</zahl>
</a0:istPrimzahl>
</env:Body>
</env:Envelope>

Unfortunately, the server still always responds with "no prime".  Next, I will
play around with tweaking the SOAP call manually using XMLHTTPRequest to see if
I can figure out what the server wants to see.
Marko, attachment 125553 [details] [diff] [review] fixes the "getAssociatedEncoding is not a function" JS
error you saw.  I should have probably attached it to a separate bug, but, now
that the deed's done, I'll get reviews for it on this bug itself and check it in
to the trunk.

I want to hold off on checking in the "emit 2001 schema namespace patch"
(attachment 125552 [details] [diff] [review]) until I figure out which SOAP call makes the .NET server
work properly.  Maybe the problem you saw earlier had nothing to do with the
schema namespace...
Comment on attachment 125553 [details] [diff] [review]
Patch that allows nsSoapEncoding to be scriptable again

You could just use NS_IMPL_QUERY_INTERFACE1_CI.
Thanks for the suggestion, Peter.  I'll attach the changed patch to a new bug to
keep the two issues separate...
Comment on attachment 125553 [details] [diff] [review]
Patch that allows nsSoapEncoding to be scriptable again

Obsoleting old patch that covers separate issue.  New patch now attached to bug
209338.
Attachment #125553 - Attachment is obsolete: true
OK, here's the deal.  The schema namespace we emit isn't the culprit here.   The
.NET web service doesn't like the namespace prefix in the method name "istPrimzahl".

Specifically, the .NET web service gets confused when it sees the following SOAP
snippet for the method call:

<a0:istPrimzahl xmlns:a0="http://tempuri.org/">
<zahl xsi:type="xs:integer">29</zahl>
</a0:istPrimzahl>

Replacing the above SOAP snippet with the following makes everything happy:

<istPrimzahl xmlns='http://tempuri.org/'> 
<zahl xsi:type='xs:integer'>29</zahl>
</istPrimzahl>

Updating the summary and marking the patch that changes the schema namespace
obsolete...

I will work more on this with Harish next week...
Summary: [Testcase] WSDL should emit "http://www.w3.org/2001/XMLSchema" namespace → [Testcase] .NET web service doesn't like namespace prefix in method name
Comment on attachment 125552 [details] [diff] [review]
Patch that emits 2001 schema namespace in SOAP 1.1

This patch isn't needed because the schema namespace isn't causing the .NET web
service barf.
Attachment #125552 - Attachment is obsolete: true
I think you are right, my tests confirm that the a0 prefix is confusing the .NET 
web service, but as per comment 7, I do think that we should additionally send 
out the 2001 schema namespace. What do your think?
Christian, I was corrected by Ray Whitmer on this.  Mozilla is doing the right
thing by sending out the 1999 schema namespace in SOAP 1.1 calls because the
SOAP 1.1 spec explicitly mentions that namespace.

We might have considered going against the spec and emitting a 2001 schema
namespace for SOAP 1.1 calls if major web service vendors did not work with
Mozilla.  But, now that we've found that the problem isn't with the schema
namespace, I think we shouldn't mess with it.
The following also works with the .NET web service and is probably easier for us
to implement.  We need to propagate the namespace prefix to the method
parameters in our SOAP call.

<a0:istPrimzahl xmlns:a0='http://tempuri.org/'>
  <a0:zahl xsi:type='xs:integer'>14</a0:zahl>
</a0:istPrimzahl>

Re-assigning to John Gaunt, our SOAP owner to fix this.
Assignee: nisheeth → jgaunt
Status: ASSIGNED → NEW
Is this bug still being worked on?
this now works fine in 1.8 trunk builds.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
No specific patch / bug referenced as the fix.

-> WORKSFORME
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 19 years ago → 19 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: