Proposal: clients whould punt to http://host on unknown protocol"Steven D. Majewski" <firstname.lastname@example.org>
Date: Wed, 22 Jun 1994 22:59:07 +0200
From: "Steven D. Majewski" <email@example.com>
To: Multiple recipients of list <firstname.lastname@example.org>
Subject: Proposal: clients whould punt to http://host on unknown protocol
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Organization: University of Virginia
Organization: University of Virginia
That clients should "punt" to http://host on unknown protocol field
Proxy support in clients makes it possible to add support for
gatewaying new protocols, but it requires cooperation between
the client and server. The client must define "proto_proxy" to
redirect to a cgi script on a host that serves as a gateway for
the new protocol. It would be easier to extend client support
to new protocols if the default action, in the absense of a
"proto_proxy" , was for the client to send the request to the
httpd server at the host specified in the URL.
Would be mapped to something like ( maybe this mapping should be a
server config option ):
And if "proto" designated a cgi-script gateway to the protocol, it
could attempt to server the request.
Currently, it appears that Mosaic (for example), if given a URL with
a protocol part it doesn't understand, merely says:
| Requested document (URL zzzz://loghost:8080/index.html)
| could not be accessed.
| The information server either is not accessible or is
| refusing to serve the document to you.
Which is rather misleading, since what it SHOULD be saying is
something more like: "I don't know how to do protocol: zzzz:"
( i.e. the error message makes it sound like it's the server's
fault, when it is actually the client's! )
This idea came up while trying to prototype a http/imap
gateway. Note that I can make a (proposed) imap: URL
functional by defining "imap_proxy" for Mosaic, to force
the client to use http: requests for imap: URL's. This
could still be done to override the proposed 'punt to http:'
default, in the case that there was only a single gateway
to a protocol.
Basically, I think it is a "good thing" to decouple client
support for particular protocols, from the list of acceptable
and accessable URL's. If a client knows how to "imap:", then
it may obviously do it directly and bypass the gateway.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
[ I'm quoting my previous article in full, because this
proposal is being cross-posted to www-talk & www-proxy ]
In article <CrtBqE.email@example.com.Virginia.EDU>,
Steven D. Majewski <firstname.lastname@example.org.Virginia.EDU> wrote:
>Partial answer to my own question:
>> Can NCSA|CERN httpd redirect to CGI by protocol ?
>With help from client proxy support, it CAN (sort of)!
>As I have figured out a bit more about what is partitioned
>between the clients & servers in WWW software, I see that
>proxies are necessary to redirect a protocol to the httpd
>server. ( If client has no protocol "xxxx" support, it
>doesn't know what to do. Maybe some sort of automatic proxy
>should be the default for unknown protocols ? It would make
>the clients more automatically extensible. )
>xxxx_proxy="http://loghost/cgi-bin/" ; export xxxx_proxy; Mosaic
>now causes a request to url: "xxxx://today.py"
>to attempt a request of:
>which is ALMOST what I wanted.
> ( ^ note double slash )
>with a script named "cgi-bin/xxxx:"
>does seem to catch the redirect.
>So it *is* possible to redirect by protocol to a gateway, but
>it needs configuration of BOTH the client and server
>[ Using NCSA Mosaic and NCSA httpd ]
>- Thanks (I assume) to the authors of wwwlib, who made the
>proxy support generic enough to accept any "*_proxy"
>- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
>- UVA Department of Molecular Physiology and Biological Physics