M
Mike deBruin
Hi all,
I'm having a problem with the way that .NET hides the implementation of
webservice requests and responses. We have an asp.net front-end that
consumes webservices implemented in a java backend.
User copies a paragraph from word with an opening quote or an extended dash
and pastes it into our app. We call a webservice to do an update, and the
invalid character is included in the soap request. The back end doesn't
have a problem with it. When we then do a request to get the newly updated
object, these invalid characters are in the response soap message, and .net
barfs because it can't parse the xml. ('', hexadecimal value 0x13, is an
invalid character. Line 37, position 43).
I'm no expert at Xml, but from what i understand, ASCII characters 0-31 are
not valid characters in an Xml document, so I can understand why the
exception is thrown. What I don't understand is how it can compose the
request soap message with these invalid characters.
To get around this, I'm going to implement a Soap extension to trap the soap
message before it's deserialized, but can anyone explain to me why soap
requests aren't validated? Does anyone have a quicker workaround than
writing a soap extension to overcome this problem?
Thanks,
Mike
I'm having a problem with the way that .NET hides the implementation of
webservice requests and responses. We have an asp.net front-end that
consumes webservices implemented in a java backend.
User copies a paragraph from word with an opening quote or an extended dash
and pastes it into our app. We call a webservice to do an update, and the
invalid character is included in the soap request. The back end doesn't
have a problem with it. When we then do a request to get the newly updated
object, these invalid characters are in the response soap message, and .net
barfs because it can't parse the xml. ('', hexadecimal value 0x13, is an
invalid character. Line 37, position 43).
I'm no expert at Xml, but from what i understand, ASCII characters 0-31 are
not valid characters in an Xml document, so I can understand why the
exception is thrown. What I don't understand is how it can compose the
request soap message with these invalid characters.
To get around this, I'm going to implement a Soap extension to trap the soap
message before it's deserialized, but can anyone explain to me why soap
requests aren't validated? Does anyone have a quicker workaround than
writing a soap extension to overcome this problem?
Thanks,
Mike