IIS returns status code 200 even if XML is invalid

[Miha V]

Hi!

We are using ASMX web service with WSE (we're using WS-Addressing) and
IIS returns HTTP status code 200 even if XML is malformed (it can
contain illegal characters in it).

The request does not get through the stack to the application, but if
I debug the application, I can see that exception is thrown somewhere
"down there".

Is there a way to prevent IIS from returning HTTP status code 200 if
the XML is not valid?

A first chance exception of type 'System.Xml.Xml Exception' occurred in
System.Xml.dll
A first chance exception of type 'System.Invalid OperationExcept ion'
occurred in System.Xml.dll
A first chance exception of type
'System.Web.Ser vices.Protocols .SoapException' occurred in
System.Web.Serv ices.dll

Thanks,
Miha.

[Mr. Arnold]

"Miha V" <mi***********@ gmail.comwrote in message
news:a2******** *************** ***********@c65 g2000hsa.google groups.com...

Hi!

We are using ASMX web service with WSE (we're using WS-Addressing) and
IIS returns HTTP status code 200 even if XML is malformed (it can
contain illegal characters in it).

The request does not get through the stack to the application, but if
I debug the application, I can see that exception is thrown somewhere
"down there".

Is there a way to prevent IIS from returning HTTP status code 200 if
the XML is not valid?

That HTTP 1.1 200 OK return code means the the HTTP request/connection
between the Web client and the Web server was OK. It is not an indication
of data exchanged between the Web client and Web service is invalid or
valid in the case the XML that has been transmitted between the Web client
and Web server.

The only thing you should be concerned about is that the 200 OK was
returned, and if it's not a 200 OK return code, then take the appropriate
action to indicate that there is something wrong with the HTTP connection
between the Web client and Web server, and the connection cannot be made
established between the two.

The return code can be 200 OK and no data was transmitted period, but most
likely, you'll get some kind formatted XML return code from the Web service
to the Web client indicating the Web service had a problem in processing
data.

So it doesn't matter if the XML is valid, not valid or no XML is returned
period when HTTP 1.1 200 OK is returned.

It's up to you check for return codes and take the appropriate action, and
it's up to you to check if the XML is valid by validating the XML data
against a XML schema and taking the appropriate action if it's valid or not
valid. HTTP 1.1 200 OK has nothing to do with valid or invalid XML being
transmitted.

[Miha V]

Mr. Arnold,

this is not completely true. ASMX requests are handled by ASP.NET
infrastructure. And ASP.NET infrastructure unwraps (processes) the
SOAP message and invokes the method on an object to handle such
requests. This object is defined in an ASMX file, and the class behind
this ASMX file handles the call.

Normally, when there is a problem with an XML being sent to the server
(ordinary web service application), ASP.NET will complain with either
400 Bad request or 500 internal server error (depending which
extensions (WSE3.0) you use).

But in this, we're getting this weird behaviour, that ASP.NET returns
success status code back to the client, even when:
* XML is badly formatted (i.e. not well formed)
* XML does not adhere to schema/DTD

The request is not being handled by the "designated method" which
should handle the request.

To illustrate:

our scenario:
client ---- malformed XML ---IIS(asmx) --return code 200

new ASP.NET asmx webservice project:
client ---- malformed XML --IIS(asmx) --return code 400 (bad
request)

When debugging our application, I can see in the debugger that there
is exception thrown (three of them actually), but it does not affect
the status code.

Also note, that there is no XML returned from the server. Just HTTP
status code 200 and then connection terminates. It is a really weird
behaviour...

Hope that helps to clarify the problem we're seeing...

Thanks,
Miha

On Aug 5, 9:48*am, "Mr. Arnold" <MR. Arn...@Arnold.c omwrote:

"Miha V" <miha.valen...@ gmail.comwrote in message
That HTTP 1.1 200 OK return code means the the HTTP request/connection
between the Web client and the Web *server *was OK. It is not an indication
of data exchanged between the Web client and Web service *is invalid or
valid in the case the XML that has been transmitted between the Web client
and Web server.

The only thing you should be concerned about is that the 200 OK was
returned, and if it's not a 200 OK return code, then take the appropriate
action to indicate that there is something wrong with the HTTP connection
between the Web client and Web server, and the connection cannot be made
established between the two.

The return code can be 200 OK and no data was transmitted period, but most
likely, you'll get some kind *formatted XML return code from the Web service
to the Web client indicating the Web service had a problem in processing
data.

So it doesn't matter if the XML is valid, *not valid or no XML is returned
period when HTTP 1.1 200 OK is returned.

It's up to you check for return codes and take the appropriate action, and
it's up to you to check if the XML is valid by validating the XML data
against a XML schema and taking the appropriate action if it's valid or not
valid. HTTP 1.1 200 OK has nothing to do with valid or invalid XML being
transmitted.

[Mr. Arnold]

"Miha V" <mi***********@ gmail.comwrote in message
news:d7******** *************** ***********@34g 2000hsh.googleg roups.com...
Mr. Arnold,

this is not completely true. ASMX requests are handled by ASP.NET
infrastructure. And ASP.NET infrastructure unwraps (processes) the
SOAP message and invokes the method on an object to handle such
requests. This object is defined in an ASMX file, and the class behind
this ASMX file handles the call.

Normally, when there is a problem with an XML being sent to the server
(ordinary web service application), ASP.NET will complain with either
400 Bad request or 500 internal server error (depending which
extensions (WSE3.0) you use).

But in this, we're getting this weird behaviour, that ASP.NET returns
success status code back to the client, even when:
* XML is badly formatted (i.e. not well formed)
* XML does not adhere to schema/DTD

The request is not being handled by the "designated method" which
should handle the request.

To illustrate:

our scenario:
client ---- malformed XML ---IIS(asmx) --return code 200

new ASP.NET asmx webservice project:
client ---- malformed XML --IIS(asmx) --return code 400 (bad
request)

----------------------------------------------------------------------------------------
Well, if the client is sending the XML, then it should be able to vaildate
the XML before it's sent, based on a schema it has for the XML on their end.
I don't see that as an impossible task on the client's part to validate the
XML againts a its known schema before it's sent.

The second thing is something can be done on the client's side to correct
the XML that has bad characters in it. I had a situation where a 3rd party
Web service was sending bad XML to the client that had bad characters in it.
I had to scan all XML coming back from the Web service looking for the bad
characters and replace them with the characters to make the XML valid and
validate it against the known schema. I don't see that as an impossible task
on the client's side either. Maybe, you come up with the routine that is
implemented in the client code.

I don't know your total situation is in making the client send only valid
XML, but that's where I think you need to address the issue.

What you're talking about trying to override on an exception returned in the
ASMX code and controlling/overriding the HTTP status code that's retuned
from IIS may not be a viable solution.

[Miha V]

Arnold, I certainly agree that the problem is on the client side.
Client MUST not send malformed XML. But, since client is out of our
control, this is how it is.

Anyhow, I have found the solution, or better, found what was causing
this behaviour. When I was inspecting the server-side generated proxy,
I noticed the option OneWay = true.

When the contract says OneWay = true, ASP.NET (WSE3.0 actually)
infrastructure will return status code 200 even if XML file is
invalid. Because it is one way, and the sender "does not care".
Whether this is the right thing to do or not is another question, but
that's how it works.

Thanks for your input,
Miha.

On Aug 5, 2:30*pm, "Mr. Arnold" <MR. Arn...@Arnold.c omwrote:

"Miha V" <miha.valen...@ gmail.comwrote in message

news:d7******** *************** ***********@34g 2000hsh.googleg roups.com...
Mr. Arnold,

this is not completely true. ASMX requests are handled by ASP.NET
infrastructure. And ASP.NET infrastructure unwraps (processes) the
SOAP message and invokes the method on an object to handle such
requests. This object is defined in an ASMX file, and the class behind
this ASMX file handles the call.

Normally, when there is a problem with an XML being sent to the server
(ordinary web service application), ASP.NET will complain with either
400 Bad request or 500 internal server error (depending which
extensions (WSE3.0) you use).

But in this, we're getting this weird behaviour, that ASP.NET returns
success status code back to the client, even when:
* XML is badly formatted (i.e. not well formed)
* XML does not adhere to schema/DTD

The request is not being handled by the "designated method" which
should handle the request.

To illustrate:

our scenario:
client ---- malformed XML ---IIS(asmx) --return code 200

new ASP.NET asmx webservice project:
client ---- malformed XML --IIS(asmx) --return code 400 (bad
request)

----------------------------------------------------------------------------------------
Well, if the client is sending the XML, then it should be able to vaildate
the XML before it's sent, based on a schema it has for the XML on their end.
I don't see that as an impossible task on the client's part to validate the
XML againts a its known schema before it's sent.

The second thing is something can be done on the client's side to correct
the XML that has bad characters in it. I had a situation where a 3rd party
Web service was sending bad XML to the client that had bad characters in it.
I had to scan all XML coming back from the Web service looking for the bad
characters and replace them with the characters to make the XML valid and
validate it against the known schema. I don't see that as an impossible task
on the client's side either. Maybe, you come up with the routine that is
implemented in the client code.

I don't know your total situation is in making the client send only valid
XML, but that's where I think you need to address the issue.

What you're talking about trying to override on an exception returned in the
ASMX code and controlling/overriding the HTTP status code that's retuned
from IIS may not be a viable solution.