NON-DELIVERY of: NON-DELIVERY of: Proposal: clients whould punt to
SDMajew@MAIL.ZD.ziff.com (SDMajew)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 22 Jun 1994 23:46:19 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <01HDUNOTSN0I0004D7@zcias1.ziff.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: SDMajew@MAIL.ZD.ziff.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: SDMajew@MAIL.ZD.ziff.com (SDMajew)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: NON-DELIVERY of: NON-DELIVERY of: Proposal: clients whould punt to
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Intended recpient(s): sbrown
Failure reason: User sbrown not listed in public Name & Address Book
O-CMS-ErrorsTo: listmas @ INTERNET (listmaster) {listmaster@www0.cern.ch}
Intended recpient(s): sbrown
Failure reason: User sbrown not listed in public Name & Address Book
O-CMS-ErrorsTo: listmas @ INTERNET (listmaster) {listmaster@www0.cern.ch}
Proposal:
That clients should "punt" to http://host on unknown protocol field
in URL.
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.
proto://host.name/path/...
Would be mapped to something like ( maybe this mapping should be a
server config option ):
http://host.name/proto/path
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:
| ERROR
|
| 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.no@murdoch.acc.Virginia.EDU>,
Steven D. Majewski <sdm7g@elvis.med.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:
>
>/usr/local/etc/httpd/htdocscgi-bin/xxxx://today
>
>which is ALMOST what I wanted.
>
>
>xxxx_proxy="http://loghost//cgi-bin/"
> ( ^ 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"
>environment string.
>
>
>- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
>- UVA Department of Molecular Physiology and Biological Physics