Re: HTTP fault codes

Hi,

I agree that <Result> abstract element could be used.
But what is the SOAP fault interest if all errors can be managed through 
Result element through ResultMajor and ResultMinor ?
Don't we have to keep same levels of errors between HTTP and SOAP bindings ?

I don't size up clearly the separation between XKMS errors (Major/Minor) 
and binding errors. For instance, what mechanism do I use when the 
server receives a request for an operation that is does not support ?
  - SOAP fault with env:Sender/xkms:MessageNotSupported ?
  - or XKMS result with Sender.MessageNotSupported ?

I have the same question for other cases.
Don't you think there is an overlapping between SOAP fault 3,4 and 5 and 
XKMS result codes ?
  - 3 : SOAP:Receiver could be managed through XKMS:Receiver.Failure
  - 4 : SOAP:Sender.MessageNotSupported could be managed through 
XKMS:Sender.MessageNotSupported
  - 5 : SOAP:Sender.BadMessage could be managed through XKMS:Sender.Failure

Regards,

Frederic



Tommy Lindberg wrote:

> Hi Frederic -
> 
> The beauty of the result messages is that their type hierarchy
> includes a general <Result> element that can returned in response to
> any request.  I use this in situations that you describe below, i.e.
> if something goes terribly wrong and provided I catch all exceptions,
> I can still return a valid XKMS result message; I could even sign it.
> 
> Regards,
> Tommy
> 
> On 5/9/05, Frederic DELEON <frederic.deleon@crf.canon.fr> wrote:
> 
>>Hello,
>>
>>In bindings specification, SOAP faults are described inside SOAP binding
>>chapter.
>>On the other hand, nothing is defined for HTTP binding, and for instance
>>nothing is defined for HTTP faults. Are we free to implement this as we
>>like ? Is it possible to return free XML error message inside HTTP
>>response or do we have to return HTTP error such as 500 error code ?
>>
>>Frederic
>>
>>
>>-- Frederic Deleon
>>-- Canon
>>
> 
>>

Received on Tuesday, 10 May 2005 13:01:05 UTC