Re: another approach to status codes, etc. in HTTP binding

Yeah, I was puzzled by this as well. The Expect usage has the server
responding with a 417 Expectation Failed status which is in the
Client Error range of status codes, not the server range. Therefore, 
applying that to the mU faulting analogy in SOAP, a 4xx status would 
seem more suitable than a 500.

So, Mark B, are you suggesting that the mU fault should be reported
with a 4xx status or are you suggesting something completely different?

My take is that it is the client that erred in expecting the server
to support some feature, not the otherway round. 

Cheers,

Chris

Mark Nottingham wrote:
> 
> How does Expect help in this situation?
> 
> On Thu, Jul 19, 2001 at 10:26:35AM -0700, Mark Baker wrote:
> > Oops, hit send prematurely.  I'll just respond to the one point I missed.
> >
> > 7/19/2001 3:20:30 AM, christopher ferris <chris.ferris@east.sun.com> wrote:
> >
> > >Mark,
> > >
> > >Okay, if we take this approach (reuse application semantics)
> > >to its fullest interpretation, then yes, SOAP Server.* faults
> > >would be reported using 500 and possibly MustUnderstand.*
> > >faults (of course, depending upon your perspective, either
> > >the client is at fault for including a header that the server
> > >doesn't understand or the server is at fault for not understanding
> > >the header;-).
> >
> > Yah, I got a headache over this one at first too until I looked at the Expect feature of HTTP 1.1.  Then all was made
> > clear; it is within the capabilities of the client to resubmit the request without mustUnderstand="1".  The server doesn't
> > have a choice.
> >
> > MB
> >
> 
> --
> Mark Nottingham
> http://www.mnot.net/

Received on Thursday, 19 July 2001 18:02:46 UTC