Re: SUDS: the SOAP Universal Delivery System

Date view Thread view Subject view Author view

From: Jeff Bone (
Date: Mon Oct 02 2000 - 19:16:31 PDT

Lisa Dusseault wrote:

> Well then, my thoughts:
> Half of this is solved by CONNECT. As I'm sure Rohit is aware, CONNECT can
> be used to tunnel a client through their own firewall (by "own", I mean a
> client inside a typical corporate firewall run by the user's company's
> administrators). It was intended to allow SSL traffic, but it's way cooler
> than that. If you can SSL to secure servers such as amazon's, I believe you
> can use CONNECT almost anywhere -- and once you CONNECT, you don't have to
> start SSL, and the firewall can't tell. I doubt many firewalls even
> enforce that you have to CONNECT to port 443. So, your example of using
> CONNECT from the IRC client to the EFNET server might be solved by this. In
> general, any public server, one with public services, isn't protected by
> their own firewall, so it works. Clients that use DAV sometimes take
> advantage of this to be able to send those wierd-o DAV HTTP methods over
> silly firewalls that think they know all the "proper" HTTP methods that
> ought to be used.

Oh! I realized I didn't even address Lisa's basic comment here. Sure, CONNECT
works on the outbound, but not the inbound. And as you point out, generalized
opening of inbound CONNECTs isn't *ever* going to happen. And then there's the
whole philosophical issue of whether HTTP needs more than GET or PUT or INVOKE
or whatever, but we've beat that dead horse enough. Suffice to say that if your
RPC lives close to the bottom of your stack world-view, then alot of these
methods live higher up and shouldn't be in your transport. CONNECT, arguably,
is one of the few that maybe should.

But there's a whole set of problems that are sloshing around in my head here
that this is a run at: discovery, naming, conventions for service naming,
connection management, management of security policies at a more semantic and
dynamic level, getting around the administrative liability for adoption of new
technology, etc...

Just talking off the top of my head here... thanks for the comments, Lisa!


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Oct 02 2000 - 19:33:59 PDT