On Wed, Mar 28, 2012 at 9:33 AM, Ajay Garg <ajaygargn...@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 _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: jdev-unsubscr...@jabber.org _______________________________________________
