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

7/19/2001 8:31:25 AM, Rich Salz <rsalz@zolera.com> wrote:

>> A SOAP fault is as much "application data" as an HTML document saying
>> "Sorry, unexpected server error, try back
>> later" when carried on a 500.  i.e. it's not application data, at least not
>> by any definition of it that I'd use.
>
>They are different because the SOAP fault could, for example, indicate
>that a specific mustUnderstand element isn't understood, and the sender
>knows how to fix it.  For an HTTP 500, there's no semantic other than
>"didn't work." 

Right.  That's why I suggested we use 400 for SOAP client faults.

>As a result, the HTTP infrastructure can do all sorts of
>things.  (I particularly like SGI; try http://www.sgi.com/no-such-file a
>couple of times.)

Cute!  But the resource "http://www.sgi.com/no-such-file" is most definitely found, so should return on a 200 (as it 
appears to do).

>> I'll ask this again, because it's an important question; if we're doing
>> tunnelling, where are the application semantics
>> defined?
>
>Then I guess you'll have to point me to a definition of application
>semantics, becuase I don't understand.

I like to look to HTTP POST and PUT when describing what an application semantic is (at least when HTTP is being 
discussed).  Both can carry a message in the HTTP entity body, but each means very different things about what 
desired action is to be taken with that message.  These meanings are application semantics.  PUT means "replace" 
and POST means (roughly) "insert". "add", or, per 2616, "accept as a subordinate" (like a Javaspaces or Linda "add").  
If we tunnel SOAP over HTTP then we are not using the "insert" meaning of POST, we are using it purely for "send".

MB

Received on Thursday, 19 July 2001 12:17:20 UTC