NON-DELIVERY of: NON-DELIVERY of: Re: Proposal: clients whould punt to
MADolan@MAIL.ZD.ziff.com (MADolan)
Errors-To: listmaster@www0.cern.ch
Date: Thu, 23 Jun 1994 00:20:33 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <01HDUOSUS3BM0006S8@zcias1.ziff.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: MADolan@MAIL.ZD.ziff.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: MADolan@MAIL.ZD.ziff.com (MADolan)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: NON-DELIVERY of: NON-DELIVERY of: Re: 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}
At 10:59 PM 6/22/94 +0200, Steven D. Majewski wrote:
>
>Proposal:
> That clients should "punt" to http://host on unknown protocol field
> in URL.
This is certainly a better solution than "gack". However it presumes
a URL format for an unknown method. In other words, it assumes the
existance of "host[:port]". Where this will not work is if one's client
does not support news, for example. Then where does the proxy request go ?
Probably no harm in trying, though with some warning to the user that the
client is guessing.
Another possibility would be to explicitly define an "unknown method server".
In otherwords, have a client configuration parameter that defines a host to
accept unknown methods as a proxy. This would normally be a proxiable httpd,
but would not have to be.
Mike
------------------------------------
Michael A. Dolan - miked@cerfnet.com
TerraByte Technology (619) 445-9070