Closed Bug 308147 Opened 19 years ago Closed 19 years ago

Bad interpretation of the SOAP response

Categories

(Core Graveyard :: Web Services, defect)

defect
Not set
normal

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
you'll have to post the XML document
(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>
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....
(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 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?
(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

What's params[0].element?  Is that the <Result> node?  Or the <return> node>
(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...)

That doesn't answer my question, really.  What's params[0].element.localName in your code?
(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
> 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?
(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.
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
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: