W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

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

From: Rich Salz <rsalz@zolera.com>
Date: Wed, 18 Jul 2001 20:14:09 -0400
Message-ID: <3B562651.93AAC0CD@zolera.com>
To: Mark Baker <distobj@acm.org>
CC: xml-dist-app@w3.org
> But it isn't, it's a
> protocol that extends application protocols.

Some would disagree.  I view the bindings more as a "tunneling"
mechanism, a way of carrying new traffic in old bottles.

>  So when the work is done to bind it to an application protocol, the
> semantics of that application protocol have to be reused.

Buy the premise, buy the flick.  I don't buy the premise.

This is one of those elegant theories that fails in the real world. You
cannot get identical semantics across different network layers.

> HTTP has an existing semantic for specifying that an
> unexpected error has occurred that prevents the response from being provided at this > time, the 500 response code.

Except that the HTTP/1.1 RFC says "User agents SHOULD display an
included entity to the user" (sec 10.5).  Display to user doesn't match
"deliver to soap engine." In particular, it allows for the entity to be
dropped (it's a SHOULD not a MUST, so caches and proxies could drop
and/or rewrite it, e.g) or otherwise modified.

When SOAP has something to communicate to a SOAP peer, it should use the
underlying protocol mechanisms to say "here is data for you."

Zolera Systems, Securing web services (XML, SOAP, Signatures,
Received on Wednesday, 18 July 2001 20:13:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:14 UTC