[jdev] (Newbie question) Can Jabber act as a gateway for HTTPS-based WebDAV?

[Waqas Hussain]

On Wed, Mar 28, 2012 at 9:33 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> Hi all.
>
> I have already posted the following query at "JAdmin" mailing list; but I am
> not sure as to which mailing list is the appropriate one.
>
> Anyhow, since my query refers to a very conceptual doubt, I am posting this
> here as well, to avoid any delay. I am sorry if I sound too desperate, but
> the answer to the following query is indispensable; only then can I decide
> on the go/no-go for the design.
>
>
> #######################################################################################################
> There are two users Bob and Alice. Each of Bob and Alice have setup a WebDAV
> server on their local machines over SSL, and listen on port 443. In a normal
> environment, Bob is able to access Alice's share by typing "https://<Alice's
> IP Address>/webdav". Alice is able to the same.
>
> Next, both Alice and Bob log onto a Jabber server set up by their common
> friend Tom; and the only way they can communicate is via Jabber. They still
> want to make their shares available to each other; and wish for the simplest
> way to do it - via their browser. So, can Tom configure his Jabber server in
> a manner, so as to allow Bob and Alice to access each other's WebDAV shares'
> via their respective browsers?
> #######################################################################################################
>
>
> Looking forward to a reply.
>
>
> Thanks and Regards,
> Ajay

So your problem basically boils down to a reverse HTTP(S) proxy,
tunneling over XMPP. You are probably considering XMPP to avoid
worrying about IP addresses and firewalls, and trying to expose local
services to contacts.

Possible? Sure. But note, at a minimum you'll need a custom client,
and a custom server (or server plugin), since nothing supports your
use-case out of the box.

Here's how I might do this:

I'm assuming Tom's server is public (not behind a firewall, can accept
connections). I'm assuming Alice's server is behind a NAT/firewall, so
can't accept direct connections. I'm also assuming you want large file
transfer support.

Alice is running a local httpd. Alice's client will open a TCP stream
to Tom's server, and a TCP stream to the local httpd, and then will
act as a dumb proxy between these connections. This is fairly simple.
You can probably use some existing HTTP proxy codebase. The client
initiates the connections when it receives a signal over XMPP from the
server. There can be multiple connections at the same time.

On the server end, it's a bit more complicated. Take an existing HTTP
proxy codebase. Then you need to modify its connection opening logic
to signal the appropriate client via the XMPP server, which opens a
reverse connection to the server proxy. Then that connection can be
used for proxying as normal.

Here's how it would flow:

1. Bob requests http://tom.com/webdav/alice/ using his web browser
2. Tom's server signals Alice's client
3. Alice's client connects to Tom's server and local server
4. Tom's server forwards request to Alice's server via Alice's client
5. Bob gets response from Alice's server via the two proxies

Why use XMPP for this? For signalling, authentication, persistent
connections, and other various features XMPP has standardized.

Why not transfer data over XMPP itself? That would be much simpler,
but large file transfers would be highly inefficient, so we open
separate connections for the HTTP tunneling.

--
Waqas Hussain