W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2001

Re: A tale of two bindings

From: Rich Salz <rsalz@zolera.com>
Date: Wed, 25 Jul 2001 09:46:41 -0400
Message-ID: <3B5ECDC1.BE31DC58@zolera.com>
To: mark.baker@sympatico.ca
CC: xml-dist-app@w3.org
> 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.

Zolera Systems, Securing web services (XML, SOAP, Signatures,
Received on Wednesday, 25 July 2001 09:45:18 UTC

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