Closed
Bug 308147
Opened 19 years ago
Closed 19 years ago
Bad interpretation of the SOAP response
Categories
(Core Graveyard :: Web Services, defect)
Core Graveyard
Web Services
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: obs, Unassigned)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050910 Firefox/1.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050910 Firefox/1.4 Hello This code works in firefox 1.0.x but not with 1.5 familly: result=parser.parseFromString(params[0].element.textContent, "text/xml"); I have to strim params[0].element.textContent to make it work: result=parser.parseFromString(trim(params[0].element.textContent),"text/xml"); If i write the xml in a string var, it works, so the bug is from the SOAP response. So i think that 1.5 adds some funny caracters before the xml declaretion. Reproducible: Always
| Reporter | ||
Comment 2•19 years ago
|
||
(In reply to comment #1) > you'll have to post the XML document A sample : <?xml version="1.0" encoding="UTF-8"?> <ret_getRangeComputers version="1.0"> <state>0</state> <quantity>44</quantity> <range1>-1</range1> <range2>-1</range2> <computer> <macAddress>00:11:0a:3a:bb:8a</macAddress> <ipAddress>10.247.8.9</ipAddress> <lastTime>1120310288</lastTime> <hostname>pas-r08p09</hostname> </computer>
Comment 3•19 years ago
|
||
So what is the difference between params[0].element.textContent and trim(params[0].element.textContent) in this case? "trim" is not a built-in function, so I have no idea what you're doing in it....
| Reporter | ||
Comment 4•19 years ago
|
||
(In reply to comment #3) > So what is the difference between params[0].element.textContent and > trim(params[0].element.textContent) in this case? "trim" is not a built-in > function, so I have no idea what you're doing in it.... function trim(str) { return str.replace(/^\s*|\s*$/g,""); } params[0].element.textContent contains several spaces before the begining of my response. Exemple send = "this is my response" get = " this is my response" I hope this will help you to understand this problem
Comment 5•19 years ago
|
||
Comment 4 and comment 2 don't agree -- that XML does not contain the text you quote in comment 4. What is the actual XML involved, and the actual textContent you see?
| Reporter | ||
Comment 6•19 years ago
|
||
| Reporter | ||
Comment 7•19 years ago
|
||
| Reporter | ||
Comment 8•19 years ago
|
||
(In reply to comment #5) > Comment 4 and comment 2 don't agree -- that XML does not contain the text you > quote in comment 4. What is the actual XML involved, and the actual > textContent you see? > Comment 6 and 7 contains . 6 is what is send to firefox by the server, it's catch using ethereal . 7 is what firefox put in params[0].element.textContent I have use the javascript "escape" function to notice the presence of a '\n' (%0A) in the beginning of params[0].element.textContent
| Reporter | ||
Comment 10•19 years ago
|
||
(In reply to comment #9) > What's params[0].element? Is that the <Result> node? Or the <return> node> > function returnOfSOAPCall(response) { var num = new Object(); var params = response.getParameters(false, num); var parser = new DOMParser(); var resultDoc = parser.parseFromString(trim(params[0].element.textContent),"text/xml"); ... } In my code params[0].element represente the content of the SOAP response without all the SOAP stuff (Envelope, Body...)
Comment 11•19 years ago
|
||
That doesn't answer my question, really. What's params[0].element.localName in your code?
| Reporter | ||
Comment 12•19 years ago
|
||
(In reply to comment #11) > That doesn't answer my question, really. What's params[0].element.localName in > your code? > Sorry, ihave misunderstand your question... params[0].element.textContent correspond to the <return> node. If you want to see the client, it's there: http://svn.fani-project.org/pub/fani/freya/trunk/freya/chrome/content/freya/presente/call_response.js
Comment 13•19 years ago
|
||
> params[0].element.textContent correspond to the <return> node.
I can't tell what you mean by that, and this is the key issue in this bug -- exactly which node you're getting the textContent of. So could you please tell me what params[0].element.localName is?| Reporter | ||
Comment 14•19 years ago
|
||
(In reply to comment #13) > > params[0].element.textContent correspond to the <return> node. > > I can't tell what you mean by that, and this is the key issue in this bug -- > exactly which node you're getting the textContent of. So could you please tell > me what params[0].element.localName is? dump(params[0].element.localName) => Result This is what you want, i hope.
Comment 15•19 years ago
|
||
Yep. Given that, the behavior is correct. Firefox 1.0.x has a buggy textContent implementation that was fixed in 1.5, and the <Result> node's textContent does start with a newline -- it's the newline between "<Result>" and "<return".
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•