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 also don't understand waht "port 80 more than they do
the HTTP protocol" means.

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

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

> 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.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Received on Wednesday, 25 July 2001 09:45:18 UTC