- From: Philip Eskelin <philip@eskelin.com>
- Date: Thu, 7 Jun 2001 23:17:14 -0400
- To: <xml-dist-app@w3.org>
- Cc: <dkgunter@lbl.gov>
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