Client-side expanded url's
Mirsad Todorovac <tm@rasips2.rasip.etf.hr> Thu, 07 March 1996 10:34 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10706;
7 Mar 96 5:34 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10702;
7 Mar 96 5:34 EST
Received: from services.Bunyip.COM by CNRI.Reston.VA.US id aa04647;
7 Mar 96 5:34 EST
Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id
EAA13515 for uri-out; Thu, 7 Mar 1996 04:25:52 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by
services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA13510 for
<uri@services.bunyip.com>; Thu, 7 Mar 1996 04:25:47 -0500
Received: from rasips1.rasip.etf.hr by mocha.bunyip.com with SMTP
(5.65a/IDA-1.4.2b/CC-Guru-2b)
id AA24058 (mail destined for uri@services.bunyip.com);
Thu, 7 Mar 96 04:24:57 -0500
Received: from rasips2.rasip.etf.hr (tm@rasips2.rasip.etf.hr [161.53.67.3]) by
rasips1.rasip.etf.hr (8.6.10/8.6.9) with ESMTP id JAA14353;
Thu, 7 Mar 1996 09:59:43 +0100
Received: (from tm@localhost) by rasips2.rasip.etf.hr (8.6.10/8.6.10) id
JAA26689; Thu, 7 Mar 1996 09:59:38 +0100
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Mirsad Todorovac <tm@rasips2.rasip.etf.hr>
Message-Id: <199603070859.JAA26689@rasips2.rasip.etf.hr>
Subject: Client-side expanded url's
To: uri@bunyip.com
Date: Thu, 7 Mar 1996 09:59:35 +0100 (MET)
Cc: Mirsad Todorovac <tm@rasips2.rasip.etf.hr>
Reply-To: mirsad.todorovac@fer.hr
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1474
X-Orig-Sender: owner-uri@bunyip.com
Precedence: bulk
There are situations, especially in documents related to Internet and
some other areas, when you can fetch desired document from multiple sources.
The locations may differ in "net length" between client and paticular servers,
and servers may differ by their average load.
Therefore it would be of practical value to have such URL's where part of
the URL would be expanded on client, by some brosers setting or environment
variable.
Then URL would break into two parts:
- client modifiable part with default value
- database specific part
Eg. when we reference RFC1738, we could do it like this:
http://{$RFC_DEP|ds.internic.net:/rfc/}rfc1738.txt
[ Now, please ignore the syntax, because it is not a part of proposal, just
a way to express desired subject. ]
This would mean:
Get rfc1738.txt from ds.internic.net, directory /rfc/
or from your preffered site, specified in environment variable
WWW_RFC_DEP, which you can set to your nearest mirror.
This proposal, in contrast to URI's, requires only minor changes to
clients, and it should be considered how to deploy it into current URL
scheme, and whether it is posible to do it without breaking existing
browsers (which in that case couldn't get object even from distant, slow
site).
--
| Mirsad Todorovac |
| Faculty of Electrical Engineering and Computing |
| University of Zagreb |
| Unska 3, Zagreb, Croatia 10000 |
| |
| e-mail: mirsad.todorovac@fer.hr |
- Client-side expanded url's Mirsad Todorovac
- Re: Client-side expanded url's Gary Adams - Sun Microsystems Labs BOS
- Re: Client-side expanded url's Gregory J. Woodhouse
- Re: Client-side expanded url's Reed Wade
- Re: Client-side expanded url's Mic Bowman