Re: Proposal: clients whould punt to http://host on unknown protocol

Steven D. Majewski (
Thu, 23 Jun 1994 13:48:10 -0400

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:


where it didn't know how to "speak" the imap protocol, would by
default ( without any proxies being set ) transform that URL into:


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