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: Thu, 19 Jul 2001 08:14:57 -0400
Message-ID: <3B56CF41.3123E26B@zolera.com>
To: Mark Baker <distobj@acm.org>
CC: xml-dist-app@w3.org
> SOAP processors, even those using HTTP, are not HTTP user agents so are
> not bound by this requirement.

No but intermediate hop-by-hop HTTP agents have no way of knowing.

> So what's wrong with using the application semantics of the protocol

That is exactly what we should do.  We just disagree that 500 is a valid
status code to contain application data.

If a SOAP target wants a digitally signed message, and doesn't get it,
should it return 401, or should it leave that to the HTTP layer in case
the POST requires a basic auth?

If doing SOAP over email, a fault can only be returned by sending a
reply message, not by responding with a 451 status and using
continuation lines.  Right?

Once you start to "tightly integrate" SOAP messaging semantics with the
underlying transport, all sorts of nasty corner cases come up, like the
two I just mentioned.  That's why it's much simpler and much more clear
to think of it as tunneling.

Zolera Systems, Securing web services (XML, SOAP, Signatures,
Received on Thursday, 19 July 2001 08:13:51 UTC

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