Re: Proposal: clients whould punt to http://host on unknown protocol
"Steven D. Majewski" <sdm7g@elvis.med.virginia.edu>
Errors-To: listmaster@www0.cern.ch
Date: Thu, 23 Jun 1994 20:34:41 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <199406231748.AA15599@elvis.med.Virginia.EDU>
Errors-To: listmaster@www0.cern.ch
Reply-To: sdm7g@elvis.med.virginia.edu
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: "Steven D. Majewski" <sdm7g@elvis.med.virginia.edu>
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Proposal: clients whould punt to http://host on unknown protocol
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
X-Mailer: Mail User's Shell (7.2.3 5/22/91)
On Jun 22, 15:32, Kevin Altis wrote:
>
> At 11:02 PM 6/22/94 +0200, Steven D. Majewski wrote:
> >Proposal:
> > That clients should "punt" to http://host on unknown protocol field
> > in URL.
>
> Basically, what you need is a default_proxy environment variable which is
> the proxy server URL a client uses when the other proxy environment
> variables don't apply. It also allows you to set just one environment
> variable if you always use the same server for proxying all protocols
> (typical case). So, under Bourne shell in Unix:
>
> default_proxy=http://host.domain:port/
> export default_proxy
>
> would be enough for most sites. As new URLs are created and support is
> added to the proxy for those URLs, clients automatically get use of the new
> proxy functionality. WAIS support is an example of that today.
>
Although I think "default_proxy" is a good idea, I don't think it
covers everything.
The question is what should a "reasonable" client do when it is handed
a URL with a protocol part it doesn't know. There should be both a
reasonable default action, and a way of specifically instructing it
to do a particular action.
In the absense of "default_proxy" or any proxy being set, I think it
would be reasonable to attempt a proxy connection to a http server
at the same host part address as the unknown protocol URL. (*)
A setting of "default_proxy", or "proto_proxy" would override that
default behaviour.
The other type of override is with client-side helpers.
Most clients don't do telnet: themselves - they call another program
to open a telnet session for them. The list of helpers for output
data types is usually extensible, but I don't think any of the current
clients allow extensible mapping of protocol helpers.
[ I use imap: in the example below, since that is one of the
gateways I am currently prototyping, but the intention is
to allow general extensibility of supported prototypes and
to not freeze useful URLs at those *currently* supported by
Mosaic and other WWW browsers. ]
So, a proposed "reasonable" client, on getting, for example a url:
imap://user@host/mailbox#message
where it didn't know how to "speak" the imap protocol, would by
default ( without any proxies being set ) transform that URL into:
http://host/imap://user@host/mailbox#message
And try for the existance of a http-imap gateway on that host.
( If a host is going to give out imap URL's when that protocol
is not widely supported by clients, then it is also "reasonable"
for that host to provide a gateway. But the original URL remains
a logical access method specifier that will still be valid if and
when support for additional protocols is added. )
This default behaviour could be changed by either the setting of
"default_proxy", "imap_proxy", or by the designation of a client-
side "imap_helper" program. [ And if pine or some other imap
mailer is given command-line imap URL support, then it could be
dispatched to access that URL, just as in the current telnet case.]
Note that setting "imap_proxy" to a different host than the one
in the imap URL would allow a third party gateway. This might be
acceptable for read-only public mailboxes ( and is, in fact, the
main use a present I have for such a gateway, which will probably
only support a subset of IMAP functionality - just enough to fetch
a message out of an acrhive. ) but would make passing plain-text
passwords (to access a private mailbox by URL) even *MORE* unsafe.
[ Don't use an untrusted proxy if you are going to pass passwords!]
[ Sorry for broadcasting this so widely: I looked in the newsgroups
and mailing list archives and didn't see any discussion of this
issue, and I wasn't sure where the appropriate forum was, since it
falls in the cracks: it has to do with client server interaction, but
doesn't really have anything to do with the protocol or HTML. It
has to do with the interpretation of a URL, but the URL/URI drafts
seem to intentionally distance themselves from semantics.
(*) Note: The above would violate the notion (expressed in the drafts)
that everything after the proto: was an opaque representation.
However, it is already the case that there is a defacto standard
syntax and a defacto semantics for parts of URL's. It is embedded
in various libraries of URL parsing code, so it's not unreasonable
to assume that if a url has a host part, it should follow the
proto://[user[:password]@]hostname[:port]/... syntax, even if the
rest of the following string is opaque. ]
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics