Re: A tale of two bindings

Jacek,

> 
>  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

1. With a URI scheme of "http", the default port is 80, so
tunnelled-SOAP traffic would find itself intermingled with
HTTP port 80 traffic.  Firewalls secure port 80 more than
they do the HTTP protocol, so this presents practical problems.

2. If I was using SOAP-over-HTTP in the way I described, say
with the java.net client libraries, I would be unable to
determine the success or failure of my HTTP method invocation
by looking at the response code returned by HttpURLConnection's
getResponseCode().  So even though I sent the message through
this interface, I wouldn't be able to get the response from
that interface.

> 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.

When I send a SOAP message with HTTP semantics, a SOAP error
*is* an HTTP error.  But I agree that when I send a SOAP
message that doesn't use HTTP semantics (such as when a tunnel
is created), then the response code doesn't matter at all
(and I would support a tunnel binding that only used a 200
response code).

> 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.

What about HTTP intermediaries, like firewalls?  Shouldn't they
have the right to know?

I'd also suggest that if the use of the SOAP tunnel was
implicit, that a URI scheme other than HTTP should be used.

> 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.

It needn't be anything more than an if statement.  Or if it is
implicit, dispatch need not occur - the bit could be there
just for the use of intermediaries.

MB

Received on Tuesday, 24 July 2001 19:32:25 UTC