Re: A tale of two bindings

> > Firewalls secure port 80 more than
> > they do the HTTP protocol
> 
> I don't understand what you mean be "secure" -- limit who can access, or
> something else?

I mean it in the sense of the functionality provided by firewalls;
filtering, access control, etc..

>  I also don't understand waht "port 80 more than they do
> the HTTP protocol" means.

I mean that they don't scan all ports to look for HTTP.  They scan
port 80 by default, plus whatever other ports the administrator
has asked them to scan (at least in all the firewalls I know
anything about).

> > 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().
> 
> And if you got "permission denied" you wouldn't know if it was because
> you needed to add a BasicAuth header to your message, or if the SOAP
> message should have been signed.

I answered this one already.  HTTP response code 401 is very
specific to HTTP authentication and does not include SOAP
signatures.  In that case it should return a 400, and then
the client MAY want to check the body for more information,
but doesn't have to because it at least knows that it erred,
and so shouldn't send the same message again.

> I do not find this argument compelling.  I prefer to view it this way: 
> if I get 200, then I should look in the body to see what happened;
> anything else and I can dispatch based on that alone.

But you always get a 200 in the binding that I believe you're
promoting.  Isn't that a bit inefficient?

> 
> > What about HTTP intermediaries, like firewalls?  Shouldn't they
> > have the right to know?
> 
> No more than they should have the right to know that a particular CGI
> form is being posted.
> 
> It's not a requirement that every SOAP message identify itself as such
> to anyone who might see it along the way.  Is it?  It *might* be *nice
> to have* but it's not a requirement.

How else would you suggest we allow firewall administrators to disallow
SOAP invocations over their firewalls?  I believe you're right that it
isn't currently a requirement (from memory), but I believe it should be.

> > I'd also suggest that if the use of the SOAP tunnel was
> > implicit, that a URI scheme other than HTTP should be used.
> 
> That defeats the whole point of tunnelling.  To use the existing HTTP
> based transport to ship SOAP packets around.

Not at all.  Using a new URI scheme does not preclude HTTP from
being the protocol used to access it.  Just as the HTTPS URI
scheme uses HTTP, so can the SOAP one.

MB

Received on Wednesday, 25 July 2001 13:22:00 UTC