Re: XMLP WG Issue 12

On Thu, May 31, 2001 at 07:08:15PM -0400, christopher ferris wrote:
> Some comments interspersed below.

And some of mine. 


> > > Perhaps an even more central question is this: Is the HTTP
> > > server merely part of the transport level upon which the
> > > XMLP/SOAP server (in the Application level) has been layered or
> > > does the HTTP-SOAP binding mean that the two servers co-exist
> > > within the same OSI level?  (Maybe if we answer this question,
> > > then we can resolve both this issue and also the SOAPAction
> > > issue:) If we decide that they fall into two separate levels,
> > > then I believe, we will have a difficult time arguing that the
> > > SOAP server (application level) should be mucking with the HTTP
> > > server (transport level).  If we decide that they fall into the
> > > same level, (both application level as Henrik has proposed)
> > > then it seems less problematic to have one communicating
> > > behavior information to the other.

The OSI stack is a tool to help understand the relationships between
different technologies and their purposes; it is not a protocol
design oracle.

We are designing an XML messaging convention that is intended to be
shuffled on the wire by generic application-level transfer protocols.
In the OSI sense, they are both Application layer. I don't know that
we can draw any useful conclusions re: this issue from that. 

I would observe that it's quite unusual for a content format to poke
its head up into the protocol. In the HTTP, when you submit a form
and you forget to include your street address, is the response code
500? 

HTTP status codes are a simplistic way of making the client software
aware of the state of the server regarding the response. They are
(mis-)used for a variety of things on the Web today. My concern is
that the software that implements the SOAP processor and the software
that implements the HTTP server may, in many cases, not be tightly
coupled. If your SOAP processor is a CGI script, does it have (in a
HTTP server-neutral way) a reliable way to effect the status code?
Does it have a guarantee that that status code will not be modified
by another part of the HTTP server trying to be 'smart' about the
content (as Larry points out, Apache encourages use of a module that
intercepts 4xx and 5xx errors on the way out to make entity bodies
'user-friendly)?

On the other side, does a SOAP client have a guarantee that a message
with a 500 status code is equivalent to a SOAP Fault? If not, SOAP
clients will need to parse the response for the actual fault no
matter what they do. It seems that using 500 is another instance of a
'hint' in the protocol binding that is searching for a purpose; what
concrete use cases are there for the hint?


> > I think that dividing the world into 2 categories (200 and 500) is
> > somewhat simplistic. The definition of the 500 error code[3] is:
> > 
> >   10.5.1 500 Internal Server Error
> > 
> >    The server encountered an unexpected condition which prevented
> >    it from fulfilling the request.
> > 
> > and the 5xx errors[4] are defined as:
> > 
> >    Response status codes beginning with the digit "5" indicate
> >    cases in which the server is aware that it has erred or is
> >    incapable of performing the request.

Not all SOAP faults are (origin-)server-side; some may be caused by
client-side errors, or intermediary issues. Using 500 implies that
they are. The other approach is to try to map SOAP fault semenatics
completely onto HTTP status semantics; IMHO that way madness lies. 
The reason that we're using faults is to get away from the problems
of HTTP status codes.

Finally, an editorial issue - the current described use of status
codes seems to be RPC-centric; if you want to send a one-way message
over a HTTP protocol binding, you won't be expecting a 500 error code
with a SOAP fault; at the most you would be expecting an ordinary
HTTP error status code if the infrastructure failed you for some
reason.


-- 
Mark Nottingham
http://www.mnot.net/

Received on Thursday, 31 May 2001 22:10:05 UTC