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.
Something in between a stack trace and a message like this is needed for
clients. The approaches discussed below seem a good start.
Jeff
----- Original Message -----
From: "Steve Loughran" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, October 17, 2002 12:24 PM
Subject: Re: SOAP stacktrace
>
> ----- Original Message -----
> From: "Nelson Minar" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, October 17, 2002 12:10 PM
> Subject: RE: SOAP stacktrace
>
>
> > >We've discussed putting in a switch to turn this on and off for a
> > >service/engine, in fact.
> >
> > Speaking from my experience at Google, I'd say turning off stack
> > traces is a pretty important feature for a production web service. The
> > last thing you want to do is dump a bunch of details about your
> > implementation that may be proprietary and that the end user won't
> > understand anyway.
>
> Its an interesting issue.
>
> You dont ever want a stack trace to get out the wire, as it is meaningless
> and yet a security risk.
>
> A lot of the stack trace stuff should be disabled from axis now, as I did
a
> run through and controlled with an isDevelopment() switch (default
=false).
>
>
> At the same time, the Mindreef folks (mindreef.com) demoed their tool last
> week at the web services devcon (sellsbrother.com), and I was impressed
how
> they showed that a service could be instrumented for better logging for
> caller debugging. The aim is to give people enough info to determine why
> their call didnt work, without calling you up.
>
> Dave Siebel & colleagues do this with http headers to request extra
tracing
> and another one for the response, but they are thinking about SoapHeaders
to
> achieve the same goal.
>
> One thing we could do for Axis would be to add a getLog() method to
> MessageContext, which returns a message specific logger. Normally this
would
> go to the console, but with the right support plugins it could return a
> trace to the caller. Then when writing code you can log for caller and
> server with the explicit knowledge that callers only get the message
context
> info:
>
> serverLog.info("inbound call from "+ipaddr);
> if(!validate()) {
> serverLog.error("failed to validate "+ipaddr+" for
> "+validateErrorDetails);
> messageContext.getLog().("Validate error on "+getMangledServerID()+ "
> because "+validateErrorDetails);
> throw new SoapFault("Invalid request);
> }
>
> Thoughts?
>
> -steve
>
>
>
