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

"Steven D. Majewski" <>
Date: Thu, 23 Jun 1994 20:34:41 +0200
Message-id: <>
Precedence: bulk
From: "Steven D. Majewski" <>
To: Multiple recipients of list <>
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:


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