Re: Issue #12: HTTP Status Codes 500 v 200

Dan,

I'll make it brief and return to lurking as well.  My understanding is that
HTTP is specifically designed to allow for semantic extensions, hence this
is where SOAP status information would go.  As far as I know, this is
basically the approach for XML-RPC.  As a programmer I prefer XML-RPC all
the way.  Going too meta with stuff like SOAP just makes my job more
frustrating.

Actually, while we're at it, why don't we create some kind of automatic meta
schema adjunct facility or XSL translation mechanism that dynamically binds
SOAP to the protocol of choice -- I'd get a big laugh if someone did for the
RPC standard ;-)

Thanks for your response,
Philip

----- Original Message -----
From: "Dan Gunter" <dkgunter@lbl.gov>
To: <xml-dist-app@w3.org>
Cc: "XML Dist-App" <xml-dist-app@w3.org>
Sent: Thursday, June 07, 2001 8:38 PM
Subject: Re: Issue #12: HTTP Status Codes 500 v 200


> (( I promise to make this brief, then return to lurking.. ))
>
>  From what I understand, SOAP is _not_ an extension of HTTP, instead
> it is a protocol with an HTTP binding. I really hope that other
> bindings remain possible.
>
> Pushing SOAP status information up into HTTP seems to me like a hack
> that's going to cause no end of headaches for other bindings (what
> happens when an intermediary needs to translate from HTTP<->UDP? does
> it have to parse all the messages going back HTTP-side so it can stick
> in the right error code? ugh..). Also, it complicates the spec.
>
> I like the XML-RPC take on the issue: "Unless there's a lower-level
> error, always return 200 OK.".
>
> Thanks for listening,
>
> - Dan Gunter

Received on Thursday, 7 June 2001 23:19:57 UTC