[5767] in www-talk@info.cern.ch
Re: File Transfer Proxy
daemon@ATHENA.MIT.EDU (Richard Huddleston)
Sat Sep 24 15:31:15 1994
Date: Sat, 24 Sep 1994 15:42:47 +0200
Errors-To: listmaster@www0.cern.ch
Errors-To: listmaster@www0.cern.ch
Reply-To: reh@wam.umd.edu
From: Richard Huddleston <reh@wam.umd.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
* > I'm part of a team that is working on an application where the NCSA
* > httpd would be an attractive choice as an agent transfering a file
* > to a host, where all of the necessary information is provided by the
* > browser/client in a URL (e.g., absolute path and filename, IP address
* > of target, etc.). The file is on the same host as the httpd, and the
* > client will access the file, via a network file system, once is has been
* > delivered to the target host--but the target IS NOT the client machine.
* > Right now, FTP is the protocol of choice. Probably not anon FTP.
* This would still involve direct connection between hosts?
* Have you thought about broadening this concept to include mail?
Absolutely. If it were just a matter of implementing a remote copy
via FTP agent, we'd just use a proxy FTP mechanism as someone already
suggested. This application is the first phase of a document access
system which would be entirely Web browser based, from the client side.
For various reasons, we don't want the documents to be directly available
on the server -- we want to transfer them to a client-accessible filesystem
after some authentication and accounting is done. We also want this to
be expanded into a general information server gateway: WAIS, gopher, etc.
This is why it's so important for us to make sure that we're keeping
the general spirit of the Web intact as we do this, instead of just
pasting a bunch of crap in that isn't conceptually integrated with it.
It *seems* to be conceptually related, but then I've only been working
with this stuff for about a month or so, and there's a substantial
amount of material to master... ;)
Richard
