----- Original Message ----- From: "Jeff Greif" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 17, 2002 1:14 PM Subject: Re: SOAP stacktrace
> Another data point at the other end of the scale: > The Amazon web service reports "bad request" either when you supply the > search category as 'book' rather than 'books', but also when your SOAP > message is completely garbled. yeah, that sounds like crossing over from the 'provide no clues for people trying to break in' has devolved to 'provide no clues to people trying to debug' > > Something in between a stack trace and a message like this is needed for > clients. The approaches discussed below seem a good start. > > Jeff my own experience is strongly in favour of including server identity info, so when one jvm in a cluster gets wedged, you can find out which one it is from the support call itself: http://www.iseran.com/Steve/papers/when_web_services_go_bad.html Another thing that raised a call one day was the customers saying 'you are sending back bad xml'. "How so," we ask? "Our side is getting XML parser errors" "can we get a full trace". ... a full trace comes back, with enough info to determine that the xml parser is barfing on trying to read the HTML coming from the IIS 404.html error page. Except we werent running our service on IIS, which caused much confusion till we resolved that they were using a URL pointing to a completely different machine, then complaining that our code didnt work. The moral there is that there is a limit to what you can do server side; client side diagnostics are helpful too :) -steve
