Re: A tale of two bindings

 Mark,
 let me describe how I would specify the HTTP binding and please
reply with what needs it doesn't address:

Content-Type: text/xml or application/soap+xml or whatever
TCP Port: whatever, this is a part of the access URI, it's like
	you specified the host name
URI scheme: http
HTTP method: POST
HTTP response codes: 200 for SOAP responses (OK or faults), 400,
	500 for HTTP problems
SOAPAction: unnecessary, deprecated

I'm sure it has been said before, but sending 4xx or 5xx with a
SOAP fault is like sending 4xx or 5xx with a "login incorrect"
web page as a result of submitting a name/password HTML form.

In short: HTTP error codes are IMHO for HTTP errors.

As for your (**): you don't _need_ anything to identify that what
you're transmitting is SOAP because the thing behind the request
URI should know that. If it doesn't and so it dispatches to
something else based on whether the incoming data is or is not
SOAP, you're adding a whole another independent dispatch
mechanism beyond URI, which already does cause dispatch on the
client (hostname of the server) and on the server (the path part)
as well.

                            Jacek Kopecky

                            Idoox
                            http://www.idoox.com/




On Sat, 21 Jul 2001, Mark Baker wrote:

 > All,
 >
 > It seems there's a large disconnect between the two different uses
 > of SOAP-over-HTTP that I've discussed.  Unless this disconnect is
 > resolved by defining a binding that addresses both needs (*), I
 > believe that the WG should seriously consider defining two HTTP bindings.
 > I would not be happy about that, because I don't believe the typical
 > developer would know enough to choose the right one in most cases.  But
 > I don't see an alternative.
 >
 > In the hopes that this can further help explain my position and the
 > difference between the two uses of SOAP/HTTP, I've written down a high
 > level view of what features I believe each binding should include;
 >
 > Tunnel binding;
 > - Content-Type; (**)
 > - TCP port; not 80
 > - URI scheme; doesn't matter
 > - HTTP method; any that carries a body
 > - HTTP response codes; doesn't matter
 > - SOAPAction; (**)
 >
 > Application protocol semantics preserving binding (ack, that really
 > needs a better name);
 > - Content-Type; application/soap+xml
 > - TCP port; 80
 > - URI scheme; HTTP
 > - HTTP method; POST
 > - HTTP response codes; whichever makes sense for the POST based transfer
 > of each SOAP message; 200 for normal responses, 400 for mustUnderstand
 > or other client faults, and 500 for version or server faults.
 > - SOAPAction; unnecessary because of the SOAP-specific Content-Type
 > (assuming the Content-Type includes a parameter that specifies
 > the value of the SOAP 1.1 SOAPAction header).
 >
 > (*) As I previously stated, I believe that the binding for the
 > non-tunnelling view of SOAP-on-an-application-protocol is the
 > generic case and should be sufficient for both uses.
 >
 > (**) A tunnel binding only requires a single bit of SOAP-identifying
 > information on an inbound message in order to unambigously identify
 > to a receiving implementation that a tunnel needs to be established.
 > This could be done with either the Content-Type or SOAPAction headers.
 > However, if both bindings are defined (or at least if the tunnel binding
 > is defined and doesn't want to preclude the definition of other bindings
 > in the future), then the tunnel binding should include some tunnel-
 > specific identifier; a Content-Type of application/soap-tunnel+xml,
 > "SOAPActor: tunnel", or something else.
 >
 > MB
 >
 >

Received on Monday, 23 July 2001 12:53:58 UTC