By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,844 Members | 836 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,844 IT Pros & Developers. It's quick & easy.

Confirm understanding - web service exceptions

P: n/a
If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is
not a .Net app, I only receive the HTTP 500 error. I believe this is due
mostly to the fact that the non-.Net apps are using POST instead of SOAP. If
the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!
Jul 21 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
there are two separate issues here i think - non-net apps handle soapfaults
differently, i've worked with one whose serialiser caught and re-threw it as
its Exception type, and another that didnt -as far as it could tell it
reconstituted one of its valid base Object types, and we had to manually
check the proprties of the object after each call. to compilcate matters a
web service method doesnt guarantee it will throw a SoapException, so we
ensured that, from our web service methods, we only threw a derived
SoapException that we knew the client could interpret.

as for posts and http status 500 - i've only encountered that when a .net
web service received a request it couldnt interpret, for example when the
client expected rpc-cencoding, or the namespace wasnt recognised. otherwise
the service should still return the fault with a status 200, so far as i
know...

r.
"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is
not a .Net app, I only receive the HTTP 500 error. I believe this is due
mostly to the fact that the non-.Net apps are using POST instead of SOAP. If the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!

Jul 21 '05 #2

P: n/a
Thanks for the reply. However, I'm still a little unsure about how my web
services should handle exceptions. Maybe this will help...
I think that when a web service propagates an exception, ASP.Net will do one
of two things for the client:
A - if the client invoked the service via SOAP, ASP.Net will return the
exception to the client.
B - if the client invoked the service via POST, ASP.Net will respond with
HTTP 500, because POST expects an HTTP code, not an exception.
In other words, ASP.Net knows the protocol that was used to invoke the web
service, and returns whatever is appropriate for that protocol.

So... If I wanted all clients to receive the same kind of exception response
regardless of their protocol, my web service should catch (instead of
propagate) exceptions and return something else to the client. So I will
decide how to respond to the client instead of letting ASP.Net decide.
That's the kind of strategy that I wanted to confirm with others so I'd know
the approach makes sense and is based on the proper understanding of how
ASP.Net handles propagated exceptions.

"Robbie Harris" <ro***********@hotmail.com> wrote in message
news:bj**********@sparta.btinternet.com...
there are two separate issues here i think - non-net apps handle soapfaults differently, i've worked with one whose serialiser caught and re-threw it as its Exception type, and another that didnt -as far as it could tell it
reconstituted one of its valid base Object types, and we had to manually
check the proprties of the object after each call. to compilcate matters a
web service method doesnt guarantee it will throw a SoapException, so we
ensured that, from our web service methods, we only threw a derived
SoapException that we knew the client could interpret.

as for posts and http status 500 - i've only encountered that when a .net
web service received a request it couldnt interpret, for example when the
client expected rpc-cencoding, or the namespace wasnt recognised. otherwise the service should still return the fault with a status 200, so far as i
know...

r.
"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...
If I invoke a web service, and it throws an exception, I can see the
exception if the client app is a .Net app. However, if the client app is not a .Net app, I only receive the HTTP 500 error. I believe this is due mostly to the fact that the non-.Net apps are using POST instead of
SOAP. If
the non-.Net apps were using SOAP, they too would in fact "see" the
exception. Is this true? Thanks!


Jul 21 '05 #3

P: n/a
i've not worked with http-post clients - so i'm no expert - but i'd be
loathe to change the service error handling strategy on the basis of the
client call - having once had to deploy two versions of the same service for
document and literal encoding, i'd hate to think of the added complexity of
customising exception handling on top! i can understand why a .net web
service exception would result in a 500 error for a post client, but i'd
also be interested to know if others in this group sovled this well with a
unified approach.

r.

"Marty McDonald" <mc******@wsdot.wa.gov> wrote in message
news:Ov*************@TK2MSFTNGP11.phx.gbl...
Thanks for the reply. However, I'm still a little unsure about how my web
services should handle exceptions. Maybe this will help...
I think that when a web service propagates an exception, ASP.Net will do one of two things for the client:
A - if the client invoked the service via SOAP, ASP.Net will return the
exception to the client.
B - if the client invoked the service via POST, ASP.Net will respond with
HTTP 500, because POST expects an HTTP code, not an exception.
In other words, ASP.Net knows the protocol that was used to invoke the web
service, and returns whatever is appropriate for that protocol.

So... If I wanted all clients to receive the same kind of exception response regardless of their protocol, my web service should catch (instead of
propagate) exceptions and return something else to the client. So I will
decide how to respond to the client instead of letting ASP.Net decide.
That's the kind of strategy that I wanted to confirm with others so I'd know the approach makes sense and is based on the proper understanding of how
ASP.Net handles propagated exceptions.

Jul 21 '05 #4

P: n/a
Hello Marty,

I'd like to share the following information with you:

1. What's the version of your .NET Framework, 1.0 or 1.1? Please be noted
that HTTP POST is disabled in .NET Framework 1.1.

INFO: HTTP GET and HTTP POST Are Disabled by Default
http://support.microsoft.com/default...b;en-us;819267

2. Which exception is thrown from you web service, SoapException?
Do you use HTTP GET to consume web service via HttpWebRequest class?

3. I believe the article below is helpful for Web Service exception
handling:

Handling and Throwing Exceptions in XML Web Services
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconwebservicedescription.asp

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! 每 www.microsoft.com/security
This posting is provided ※as is§ with no warranties and confers no rights.
Jul 21 '05 #5

P: n/a
the article is here:
http://msdn.microsoft.com/library/de...astructure.asp

but it just covers the basic stuff. the question is: http get and post
clients will receive an http status 500 when an exception is thrown,
regardless of the exception type, so is there a best practise approach to
exception handling in web services that would allow the exception to be
caught and consumed regardless of the client protocol?

i dont think there is, other than thats a client capability limitation that
probably shouldnt be coded for in a web service - but i'm interested to know
others approach to this...

r.

"Tian Min Huang" <ti******@online.microsoft.com> wrote in message
news:fj**************@cpmsftngxa06.phx.gbl...
Hello Marty,

I'd like to share the following information with you:

1. What's the version of your .NET Framework, 1.0 or 1.1? Please be noted
that HTTP POST is disabled in .NET Framework 1.1.

INFO: HTTP GET and HTTP POST Are Disabled by Default
http://support.microsoft.com/default...b;en-us;819267

2. Which exception is thrown from you web service, SoapException?
Do you use HTTP GET to consume web service via HttpWebRequest class?

3. I believe the article below is helpful for Web Service exception
handling:

Handling and Throwing Exceptions in XML Web Services
http://msdn.microsoft.com/library/de...us/cpguide/htm l/cpconwebservicedescription.asp

Hope this helps.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! 每 www.microsoft.com/security
This posting is provided ※as is§ with no warranties and confers no rights.

Jul 21 '05 #6

P: n/a
I'm running Framework 1.0. Thank you for your information. But my issue is
best explained by Robbie's 9/11/2003 2:44 AM reply. I'm mostly trying to
make sure I understand what ASP.Net is doing with non-SOAP clients (I think
ASP.Net just responds with HTTP 500). If I'm correct in that, then I can
work on a solution for it. Thanks everyone for your input!
Jul 21 '05 #7

P: n/a
Hello Marty,

Thanks for posting in the group.

I just checked the post thread and have some idea for this issue. On my
opinion, the most direct way to confirm this is to check SOAP return
message from different actions to see what the difference it.

In MSDN, we could find a good tool named "SOAP Trace Utility" after
installing SOAP toolkit. Please refer to
http://msdn.microsoft.com/library/en..._5y49.asp?fram
e=true for detailed steps on using this tool.

Hope that helps.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! 每 www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
!From: "Marty McDonald" <mc******@wsdot.wa.gov>
!References: <#6**************@TK2MSFTNGP10.phx.gbl>
<bj**********@sparta.btinternet.com> <Ov*************@TK2MSFTNGP11.phx.gbl>
<fj**************@cpmsftngxa06.phx.gbl>
!Subject: Re: Confirm understanding - web service exceptions
!Date: Thu, 11 Sep 2003 07:34:11 -0700
!Lines: 7
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
!Message-ID: <#P*************@tk2msftngp13.phx.gbl>
!Newsgroups: microsoft.public.dotnet.general
!NNTP-Posting-Host: 164.110.202.164
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!tk2msftn gp13.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.general:108157
!X-Tomcat-NG: microsoft.public.dotnet.general
!
!I'm running Framework 1.0. Thank you for your information. But my issue
is
!best explained by Robbie's 9/11/2003 2:44 AM reply. I'm mostly trying to
!make sure I understand what ASP.Net is doing with non-SOAP clients (I think
!ASP.Net just responds with HTTP 500). If I'm correct in that, then I can
!work on a solution for it. Thanks everyone for your input!
!
!
!

Jul 21 '05 #8

P: n/a
This looks like a useful tool. But that tells me what happened after the
fact.
Example...
At work, we have a C# web service that performs a calculation.
It is used by a ColdFusion client. The ColdFusion client can use the
service just fine. The problem is that when the web service throws an
exception, the ColdFusion client recieves an HTTP 500 response - that is not
enough information for them to know what happened.
I believe the ColdFusion client receives HTTP 500 because they are using the
POST protocol. If they used SOAP, they would see the exception details.
So my whole question is this... when clients are using POST, we need a good
way (besides exceptions) to let them know what happened. I can figure it
out on my own, but wanted to know if anyone else did it already, I would be
interested in their ideas.

"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
news:zJ**************@cpmsftngxa06.phx.gbl...
Hello Marty,

Thanks for posting in the group.

I just checked the post thread and have some idea for this issue. On my
opinion, the most direct way to confirm this is to check SOAP return
message from different actions to see what the difference it.

In MSDN, we could find a good tool named "SOAP Trace Utility" after
installing SOAP toolkit. Please refer to
http://msdn.microsoft.com/library/en..._5y49.asp?fram e=true for detailed steps on using this tool.

Hope that helps.

Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! 每 www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no

rights.
Jul 21 '05 #9

P: n/a
Hello Marty,

Thanks for the quick response.

I used trace tool when using IE to invoke a web method, here is the
returned data:

0x00000000 48 54 54 50 2F 31 2E 31 20 31 30 30 20 43 6F 6E HTTP/1.1
100 Con
0x00000010 74 69 6E 75 65 0D 0A 53 65 72 76 65 72 3A 20 4D
tinue..Server: M
0x00000020 69 63 72 6F 73 6F 66 74 2D 49 49 53 2F 35 2E 31
icrosoft-IIS/5.1
0x00000030 0D 0A 44 61 74 65 3A 20 4D 6F 6E 2C 20 31 35 20 ..Date:
Mon, 15
0x00000040 53 65 70 20 32 30 30 33 20 30 39 3A 34 39 3A 32 Sep 2003
09:49:2
0x00000050 30 20 47 4D 54 0D 0A 58 2D 50 6F 77 65 72 65 64 0
GMT..X-Powered
0x00000060 2D 42 79 3A 20 41 53 50 2E 4E 45 54 0D 0A 0D 0A -By:
ASP.NET....
0x00000070 48 54 54 50 2F 31 2E 31 20 35 30 30 20 49 6E 74 HTTP/1.1
500 Int
0x00000080 65 72 6E 61 6C 20 53 65 72 76 65 72 20 45 72 72 ernal
Server Err
0x00000090 6F 72 2E 0D 0A 53 65 72 76 65 72 3A 20 4D 69 63
or...Server: Mic
0x000000A0 72 6F 73 6F 66 74 2D 49 49 53 2F 35 2E 31 0D 0A
rosoft-IIS/5.1..
0x000000B0 44 61 74 65 3A 20 4D 6F 6E 2C 20 31 35 20 53 65 Date: Mon,
15 Se
0x000000C0 70 20 32 30 30 33 20 30 39 3A 34 39 3A 32 30 20 p 2003
09:49:20
0x000000D0 47 4D 54 0D 0A 58 2D 50 6F 77 65 72 65 64 2D 42
GMT..X-Powered-B
0x000000E0 79 3A 20 41 53 50 2E 4E 45 54 0D 0A 58 2D 41 73 y:
ASP.NET..X-As
0x000000F0 70 4E 65 74 2D 56 65 72 73 69 6F 6E 3A 20 31 2E
pNet-Version: 1.
0x00000100 31 2E 34 33 32 32 0D 0A 43 61 63 68 65 2D 43 6F
1.4322..Cache-Co
0x00000110 6E 74 72 6F 6C 3A 20 70 72 69 76 61 74 65 0D 0A ntrol:
private..
0x00000120 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65
Content-Type: te
0x00000130 78 74 2F 70 6C 61 69 6E 3B 20 63 68 61 72 73 65 xt/plain;
charse
0x00000140 74 3D 75 74 66 2D 38 0D 0A 43 6F 6E 74 65 6E 74
t=utf-8..Content
0x00000150 2D 4C 65 6E 67 74 68 3A 20 38 38 0D 0A 0D 0A 53 -Length:
88....S
0x00000160 79 73 74 65 6D 2E 45 78 63 65 70 74 69 6F 6E 3A
ystem.Exception:
0x00000170 20 42 42 0D 0A 20 20 20 61 74 20 4B 42 33 30 57 BB.. at
KB30W
0x00000180 53 2E 54 65 73 74 4D 65 74 68 6F 64 31 28 29 20
S.TestMethod1()
0x00000190 69 6E 20 64 3A 5C 6D 76 70 77 65 62 5C 6B 62 33 in
d:\mvpweb\kb3
0x000001A0 30 5C 6B 62 33 30 77 73 2E 61 73 6D 78 3A 6C 69
0\kb30ws.asmx:li
0x000001B0 6E 65 20 36 31 0D 0A 00 ne 61...

It seems that there is no SOAP exception returned. Under this situation it
is impossbile for a client to get exception infomation since it is not
available in client side. I think what we could do is to contruct a
customized message in server side when exception happens and return it back
to client.

Here is a SOAP message when there is exception message inside: (FYI)

0x00000000 48 54 54 50 2F 31 2E 31 20 31 30 30 20 43 6F 6E HTTP/1.1
100 Con
0x00000010 74 69 6E 75 65 0D 0A 53 65 72 76 65 72 3A 20 4D
tinue..Server: M
0x00000020 69 63 72 6F 73 6F 66 74 2D 49 49 53 2F 35 2E 31
icrosoft-IIS/5.1
0x00000030 0D 0A 44 61 74 65 3A 20 4D 6F 6E 2C 20 31 35 20 ..Date:
Mon, 15
0x00000040 53 65 70 20 32 30 30 33 20 30 39 3A 33 30 3A 30 Sep 2003
09:30:0
0x00000050 34 20 47 4D 54 0D 0A 58 2D 50 6F 77 65 72 65 64 4
GMT..X-Powered
0x00000060 2D 42 79 3A 20 41 53 50 2E 4E 45 54 0D 0A 0D 0A -By:
ASP.NET....
0x00000070 48 54 54 50 2F 31 2E 31 20 35 30 30 20 49 6E 74 HTTP/1.1
500 Int
0x00000080 65 72 6E 61 6C 20 53 65 72 76 65 72 20 45 72 72 ernal
Server Err
0x00000090 6F 72 2E 0D 0A 53 65 72 76 65 72 3A 20 4D 69 63
or...Server: Mic
0x000000A0 72 6F 73 6F 66 74 2D 49 49 53 2F 35 2E 31 0D 0A
rosoft-IIS/5.1..
0x000000B0 44 61 74 65 3A 20 4D 6F 6E 2C 20 31 35 20 53 65 Date: Mon,
15 Se
0x000000C0 70 20 32 30 30 33 20 30 39 3A 33 30 3A 30 34 20 p 2003
09:30:04
0x000000D0 47 4D 54 0D 0A 58 2D 50 6F 77 65 72 65 64 2D 42
GMT..X-Powered-B
0x000000E0 79 3A 20 41 53 50 2E 4E 45 54 0D 0A 58 2D 41 73 y:
ASP.NET..X-As
0x000000F0 70 4E 65 74 2D 56 65 72 73 69 6F 6E 3A 20 31 2E
pNet-Version: 1.
0x00000100 31 2E 34 33 32 32 0D 0A 43 61 63 68 65 2D 43 6F
1.4322..Cache-Co
0x00000110 6E 74 72 6F 6C 3A 20 70 72 69 76 61 74 65 0D 0A ntrol:
private..
0x00000120 43 6F 6E 74 65 6E 74 2D 54 79 70 65 3A 20 74 65
Content-Type: te
0x00000130 78 74 2F 78 6D 6C 3B 20 63 68 61 72 73 65 74 3D xt/xml;
charset=
0x00000140 75 74 66 2D 38 0D 0A 43 6F 6E 74 65 6E 74 2D 4C
utf-8..Content-L
0x00000150 65 6E 67 74 68 3A 20 36 34 36 0D 0A 0D 0A 3C 3F ength:
646....<?
0x00000160 78 6D 6C 20 76 65 72 73 69 6F 6E 3D 22 31 2E 30 xml
version="1.0
0x00000170 22 20 65 6E 63 6F 64 69 6E 67 3D 22 75 74 66 2D "
encoding="utf-
0x00000180 38 22 3F 3E 0D 0A 3C 73 6F 61 70 3A 45 6E 76 65
8"?>..<soap:Enve
0x00000190 6C 6F 70 65 20 78 6D 6C 6E 73 3A 73 6F 61 70 3D lope
xmlns:soap=
0x000001A0 22 68 74 74 70 3A 2F 2F 73 63 68 65 6D 61 73 2E
"http://schemas.
0x000001B0 78 6D 6C 73 6F 61 70 2E 6F 72 67 2F 73 6F 61 70
xmlsoap.org/soap
0x000001C0 2F 65 6E 76 65 6C 6F 70 65 2F 22 20 78 6D 6C 6E /envelope/"
xmln
0x000001D0 73 3A 78 73 69 3D 22 68 74 74 70 3A 2F 2F 77 77
s:xsi="http://ww
0x000001E0 77 2E 77 33 2E 6F 72 67 2F 32 30 30 31 2F 58 4D
w.w3.org/2001/XM
0x000001F0 4C 53 63 68 65 6D 61 2D 69 6E 73 74 61 6E 63 65
LSchema-instance
0x00000200 22 20 78 6D 6C 6E 73 3A 78 73 64 3D 22 68 74 74 "
xmlns:xsd="htt
0x00000210 70 3A 2F 2F 77 77 77 2E 77 33 2E 6F 72 67 2F 32
p://www.w3.org/2
0x00000220 30 30 31 2F 58 4D 4C 53 63 68 65 6D 61 22 3E 0D
001/XMLSchema">.
0x00000230 0A 20 20 3C 73 6F 61 70 3A 42 6F 64 79 3E 0D 0A .
<soap:Body>..
0x00000240 20 20 20 20 3C 73 6F 61 70 3A 46 61 75 6C 74 3E
<soap:Fault>
0x00000250 0D 0A 20 20 20 20 20 20 3C 66 61 75 6C 74 63 6F ..
<faultco
0x00000260 64 65 3E 73 6F 61 70 3A 53 65 72 76 65 72 3C 2F
de>soap:Server</
0x00000270 66 61 75 6C 74 63 6F 64 65 3E 0D 0A 20 20 20 20
faultcode>..
0x00000280 20 20 3C 66 61 75 6C 74 73 74 72 69 6E 67 3E 53
<faultstring>S
0x00000290 79 73 74 65 6D 2E 57 65 62 2E 53 65 72 76 69 63
ystem.Web.Servic
0x000002A0 65 73 2E 50 72 6F 74 6F 63 6F 6C 73 2E 53 6F 61
es.Protocols.Soa
0x000002B0 70 45 78 63 65 70 74 69 6F 6E 3A 20 53 65 72 76 pException:
Serv
0x000002C0 65 72 20 77 61 73 20 75 6E 61 62 6C 65 20 74 6F er was
unable to
0x000002D0 20 70 72 6F 63 65 73 73 20 72 65 71 75 65 73 74 process
request
0x000002E0 2E 20 2D 2D 2D 26 67 74 3B 20 53 79 73 74 65 6D . ---&gt;
System
0x000002F0 2E 45 78 63 65 70 74 69 6F 6E 3A 20 41 41 0D 0A .Exception:
AA..
0x00000300 20 20 20 61 74 20 4B 42 33 30 57 53 2E 54 65 73 at
KB30WS.Tes
0x00000310 74 4D 65 74 68 6F 64 28 42 79 74 65 5B 5D 26 61
tMethod(Byte[]&a
0x00000320 6D 70 3B 20 53 69 74 65 49 64 2C 20 53 74 72 69 mp; SiteId,
Stri
0x00000330 6E 67 20 55 73 65 72 49 64 29 20 69 6E 20 64 3A ng UserId)
in d:
0x00000340 5C 6D 76 70 77 65 62 5C 6B 62 33 30 5C 6B 62 33
\mvpweb\kb30\kb3
0x00000350 30 77 73 2E 61 73 6D 78 3A 6C 69 6E 65 20 35 34
0ws.asmx:line 54
0x00000360 0D 0A 20 20 20 2D 2D 2D 20 45 6E 64 20 6F 66 20 .. ---
End of
0x00000370 69 6E 6E 65 72 20 65 78 63 65 70 74 69 6F 6E 20 inner
exception
0x00000380 73 74 61 63 6B 20 74 72 61 63 65 20 2D 2D 2D 3C stack trace
---<
0x00000390 2F 66 61 75 6C 74 73 74 72 69 6E 67 3E 0D 0A 20
/faultstring>..
0x000003A0 20 20 20 20 20 3C 64 65 74 61 69 6C 20 2F 3E 0D
<detail />.
0x000003B0 0A 20 20 20 20 3C 2F 73 6F 61 70 3A 46 61 75 6C .
</soap:Faul
0x000003C0 74 3E 0D 0A 20 20 3C 2F 73 6F 61 70 3A 42 6F 64 t>..
</soap:Bod
0x000003D0 79 3E 0D 0A 3C 2F 73 6F 61 70 3A 45 6E 76 65 6C
y>..</soap:Envel
0x000003E0 6F 70 65 3E 00 ope>.
Best regards,
Yanhong Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

--------------------
!From: "Marty McDonald" <mc******@wsdot.wa.gov>
!References: <#6**************@TK2MSFTNGP10.phx.gbl>
<bj**********@sparta.btinternet.com> <Ov*************@TK2MSFTNGP11.phx.gbl>
<fj**************@cpmsftngxa06.phx.gbl>
<#P*************@tk2msftngp13.phx.gbl>
<zJ**************@cpmsftngxa06.phx.gbl>
!Subject: Re: Confirm understanding - web service exceptions
!Date: Fri, 12 Sep 2003 08:37:34 -0700
!Lines: 42
!X-Priority: 3
!X-MSMail-Priority: Normal
!X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
!X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
!Message-ID: <ue**************@TK2MSFTNGP11.phx.gbl>
!Newsgroups: microsoft.public.dotnet.general
!NNTP-Posting-Host: 164.110.202.164
!Path: cpmsftngxa06.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTN GP11.phx.gbl
!Xref: cpmsftngxa06.phx.gbl microsoft.public.dotnet.general:108297
!X-Tomcat-NG: microsoft.public.dotnet.general
!
!This looks like a useful tool. But that tells me what happened after the
!fact.
!Example...
!At work, we have a C# web service that performs a calculation.
!It is used by a ColdFusion client. The ColdFusion client can use the
!service just fine. The problem is that when the web service throws an
!exception, the ColdFusion client recieves an HTTP 500 response - that is
not
!enough information for them to know what happened.
!I believe the ColdFusion client receives HTTP 500 because they are using
the
!POST protocol. If they used SOAP, they would see the exception details.
!So my whole question is this... when clients are using POST, we need a good
!way (besides exceptions) to let them know what happened. I can figure it
!out on my own, but wanted to know if anyone else did it already, I would be
!interested in their ideas.
!
!"Yan-Hong Huang[MSFT]" <yh*****@online.microsoft.com> wrote in message
!news:zJ**************@cpmsftngxa06.phx.gbl...
!> Hello Marty,
!>
!> Thanks for posting in the group.
!>
!> I just checked the post thread and have some idea for this issue. On my
!> opinion, the most direct way to confirm this is to check SOAP return
!> message from different actions to see what the difference it.
!>
!> In MSDN, we could find a good tool named "SOAP Trace Utility" after
!> installing SOAP toolkit. Please refer to
!>
!http://msdn.microsoft.com/library/en...w_5y49.asp?fra
m
!> e=true for detailed steps on using this tool.
!>
!> Hope that helps.
!>
!> Best regards,
!> Yanhong Huang
!> Microsoft Online Partner Support
!>
!> Get Secure! 每 www.microsoft.com/security
!> This posting is provided "AS IS" with no warranties, and confers no
!rights.
!
!
!

Jul 21 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.