soapui changes response? CDATA?
hello, go a strange problem. this is how the raw response looks: TTP/1.1 200 OK Server: nginx/0.6.32 Date: Sun, 22 Feb 2009 22:20:58 GMT Content-Type: text/xml; charset=utf-8 Transfer-Encod...
Forum Discussion
NiclasReimertz
Staff
StaffHi,
The issue is a moral dilemma.
being a developer, not a tester, Ole expressed himself delicately. Being more test oriented, I'll be a bit rougher: It is not a bug in soapUI. You are not allowed have have undefined entities in attributes. Period.
As a tester, I would take this to the developers as a bug in the implementation and make sure it gets fixed, any standards based consumer will not accept the response. This mights change if the only consumers are internal only where you can allow for them to consume the response even though it is faulty.
Our dilemma is:
soapUI is a Testing Tool that should note errors. If we allow undefined entities, and you publish the the web service, you might have customers screaming "WebSphere says the XML is malformed" or "JBoss says this is faulty", in which case we would be doing you a disservice by allowing it.
So our internal discussion is, "What to do? What is correct tool behavior?". What we know is, we can't allow this straight of the bat but there might be useful to cover this, where you would like to allows certain faulty behaviors in the web services, the only question is how to make it useful, general and usable.
I'm terribly sorry you have to wait, but we want to make sure this is handled right in soapUI.
Meanwhile I'd really like to recommend you to talk to the people who built the web service. You never know how it is going to be consumes, there might be problems when trying to consume it in a new client (by for example a mobile app) or if it is used on multiple platforms.
For example, save
e24cf2727a0582446a1b857eb62b86c8
as an XML file and try opening it in Firefox, Chrome or Internet Explorer. They will all complain
the correct xml should be
e24cf2727a0582446a1b857eb62b86c8
Best Regards
niclas
eviware.com
The issue is a moral dilemma.
being a developer, not a tester, Ole expressed himself delicately. Being more test oriented, I'll be a bit rougher: It is not a bug in soapUI. You are not allowed have have undefined entities in attributes. Period.
As a tester, I would take this to the developers as a bug in the implementation and make sure it gets fixed, any standards based consumer will not accept the response. This mights change if the only consumers are internal only where you can allow for them to consume the response even though it is faulty.
Our dilemma is:
soapUI is a Testing Tool that should note errors. If we allow undefined entities, and you publish the the web service, you might have customers screaming "WebSphere says the XML is malformed" or "JBoss says this is faulty", in which case we would be doing you a disservice by allowing it.
So our internal discussion is, "What to do? What is correct tool behavior?". What we know is, we can't allow this straight of the bat but there might be useful to cover this, where you would like to allows certain faulty behaviors in the web services, the only question is how to make it useful, general and usable.
I'm terribly sorry you have to wait, but we want to make sure this is handled right in soapUI.
Meanwhile I'd really like to recommend you to talk to the people who built the web service. You never know how it is going to be consumes, there might be problems when trying to consume it in a new client (by for example a mobile app) or if it is used on multiple platforms.
For example, save
as an XML file and try opening it in Firefox, Chrome or Internet Explorer. They will all complain
the correct xml should be
Best Regards
niclas
eviware.com