298873 - Web services using WebMethods Glue no longer work.

Status: VERIFIED INVALID

(Core Graveyard :: Web Services, defect)

Description

[Tobias]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+

The abowe link demonstrates a web services example that has worked before in
firefox 1.04 and slao Mozilla 1.7.8 (also older versions). but in Moazilla
1.8(alpha) and above and the Firefox 1.1(alpha) it does not work at all..

try the above link in Firefox 1.04 and it work but not in the new comming
versions of Mozilla and Firefox.


Reproducible: Always

Steps to Reproduce:
1.go to the url http://mgalli.com/wsdom/moz-crossportal/fs-4/
2.press the get button
3.no result in the latest firefox/Mozilla
4.above (works in the last stable Mozilla/Firefox release)

Actual Results:  
nothing

Expected Results:  
reporting the rogress in the result window..

Comment 1

[William Bumgarner [:zsinj]]

It's not Firefox, it's the page. I'm not that good with JavaScript, but even
MSIE can't get that page to work.

<- qawanted

Comment 2

[Jorge Villalobos [:jorgev] (he/him)]

The following is thrown in the Javascript Console:
Error: uncaught exception: Security Error: Content at
http://mgalli.com/wsdom/moz-crossportal/fs-4/ may not load data from
http://services.xmethods.net/soap.

Comment 3

[William Bumgarner [:zsinj]]

Resolution: INVALID?

Comment 4

[Tobias]

I guess that the mozilla people at http://www.mozilla.org/projects/webservices/
would not be so glad if you this critical bug as INVALID.

Web services is NOT supported by IE so you should not work there... 

this is a bug but I can not say where it fails..

Comment 5

[William Bumgarner [:zsinj]]

My appologies. In this case, the cause needs to be found (hence this report) and
the regression started.

Summary: [regression] ?

Comment 6

[Tobias]

Does anyone know the status of the web service implementation ? the last changes
 at the page I added above was from summer 2003.
is SOAP 1.2 implemented ? WSDL 1.2 ?

Comment 7

[zug_treno]

Product:Core Component:Web Services?

Comment 8

[Tobias]

that sounds like a better place to place the bug in...

Comment 9

[Boris Zbarsky [:bzbarsky]]

Doron, what's up here?  This regressed in the range:  http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=20041012+040000&maxdate=20041013+100000&cvsroot=%2Fcvsroot

And I see nothing webservices-related there...  Note that that security error was appearing even while this code was working.

Comment 10

[Doron Rosenberg (IBM)]

Funky:

Asynchronous Request:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:enc="h
ttp://schemas.xmlsoap.org/soap/encoding/" env:encodingStyle="http://schemas.xmls
oap.org/soap/encoding/" xmlns:xs="http://www.w3.org/1999/XMLSchema" xmlns:xsi="h
ttp://www.w3.org/1999/XMLSchema-instance"><env:Header/><env:Body><getRate xmlns=
"urn:xmethods-CurrencyExchange"><country1 xsi:type="xs:string">usa</country1><co
untry2 xsi:type="xs:string">brazil</country2></getRate></env:Body></env:Envelope
>


Asynchronous Response:
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi=
"http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XM
LSchema" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" soap:encoding
Style="http://schemas.xmlsoap.org/soap/encoding/"><soap:Body><soap:Fault><faultc
ode>soap:Server</faultcode><faultstring>String index out of range: -1</faultstri
ng><detail><e:electric-detail xmlns:e="http://www.themindelectric.com/"><class>j
ava.lang.StringIndexOutOfBoundsException</class><message>String index out of ran
ge: -1</message><trace>java.lang.StringIndexOutOfBoundsException: String index o
ut of range: -1
        at java.lang.String.substring(String.java:1520)
        at java.lang.String.substring(String.java:1487)
        at electric.net.soap.http.SOAPHandler.getPath(SOAPHandler.java:138)
        at electric.net.soap.http.SOAPHandler.service(SOAPHandler.java:76)
        at electric.server.http.ServletServer.service(ServletServer.java:218)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
        at electric.net.servlet.Config.service(Config.java:182)
        at electric.net.http.HTTPContext.service(HTTPContext.java:118)
        at electric.net.servlet.Servlets.service(Servlets.java:47)
        at electric.net.http.WebServer.service(WebServer.java:127)
        at electric.net.tcp.TCPServer.run(TCPServer.java:145)
        at electric.net.tcp.Request.run(TCPServer.java:262)
        at electric.util.ThreadPool.run(ThreadPool.java:105)
        at java.lang.Thread.run(Thread.java:479)
</trace></e:electric-detail></detail></soap:Fault></soap:Body></soap:Envelope>

The only checkin that looks like it could do this is:

Fix XML serializer to use default namespaces when possible instead of outputing unneeded namespace prefixes. Also fix possible correctness issues with the prefixes it generates. Bug 263225, r=peterv, sr=rbs

What we are sending is causing the web service to choke.

Comment 11

[Doron Rosenberg (IBM)]

It is that checkin (bug 263225) that broke this:

Before:

  <env:Body>
    <a0:getRate xmlns:a0="urn:xmethods-CurrencyExchange">
      <a0:country1 xsi:type="xs:string">usa</a0:country1>
      <a0:country2 xsi:type="xs:string">brazil</a0:country2>
    </a0:getRate>
  </env:Body>

After:

  <env:Body>
    <getRate xmlns="urn:xmethods-CurrencyExchange">
      <country1 xsi:type="xs:string">usa</country1>
      <country2 xsi:type="xs:string">brazil</country2>
    </getRate>
  </env:Body>

the missing "a0:" namespace prefix is causing this.  Obviously some webservices (this seems to be Apache) need that extra prefix.

Is there a way WSDL code could get the old behavior back from the serializer?

Oh yeah, someone smack mgalli for not adding an error handler to his testcase :)

Comment 12

[Jesse Ruderman]

If Apache needs the prefix, does that mean Apache is violating the XML spec?

Comment 13

[Jo Hermans]

I'm not sure if namespaces are required or not (I'm not a SOAP expert, but I've build SOAP clients and servers before). But I know that GSOAP (the most popular SOAP stack) is generating them in their requests by default.

I agree that XHTML-code with these namespaces won't render very well (bug 155723 comment 16), but SOAP isn't XHTML. Serializing SOAP might be different from serializing XHTML.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> Is there a way WSDL code could get the old behavior back from the serializer?

Not without changing the serializer.  I suppose we can add some flags for this, and try really hard to make it safe, but see below.

> If Apache needs the prefix, does that mean Apache is violating the XML spec?

Yes.  Those two XML snippets that doron posted are completely equivalent XML.

Which makes me ask -- how common is this problem in web service implementations?  Is the issue Apache in general, or just this one site?  If this is not common, I'd rather evangelize; if this is a problem with every Apache install, we need to look for a safe 1.8 fix.

Comment 15

[Robert Accettura [:raccettura]]

FWIW reporter uses a webservice, and doesn't appear to be affected.

Comment 16

[Doron Rosenberg (IBM)]

I spoke too soon, turns out it isn't Apache, but rather Glue by WebMethods.

Though it seems that every other web service impl can talk to it, so not sure.  I'll see what other impls do tomorrow.

The issue is probably that the content inside <env:Body> needs to be in a different namespace than the SOAP one (specifically "urn:xmethods-CurrencyExchange"), which is true in 1.8.  So seems that the Glue product is indeed in violation of XML.

Comment 17

[Robert Accettura [:raccettura]]

Can this be fixed for an RC2?

Comment 18

[Boris Zbarsky [:bzbarsky]]

See comment 14.  If it's desperately needed we can try to do something, but it would require a lot of time for the testing that would be needed.

Comment 19

[Robert Accettura [:raccettura]]

reporter doesn't use glue (http://www.webmethods.com/meta/default/folder/0000008413), we use NuSOAP actually.  So this shouldn't be an issue AFAIK since I don't think NuSOAP has this problem, at least not that I've seen.

This clearly isn't Apache, unless http://ws.apache.org/ is involved, which I don't think is the case.

My only concern was being hit with this regression, but after re-reading this bug, I don't think it's an issue for me.

I'm curious how other products handle this (both server and client side).

Considering "webservice" is currently a huge buzz word in Corporate IT departments right now (on a scale of "Web 2.0")... i'd personally want to be pretty sure this is isolated to one product... and that they are at fault.  Just my $0.02.

Comment 20

[Doron Rosenberg (IBM)]

Don't think we need to worry for 1.8.  Our webservices code has bigger problems (.Net webservices) than this.

Comment 21

[Boris Zbarsky [:bzbarsky]]

OK.  In that case, this is invalid.