Are there exceptions for fragment identifiers, and search terms, and
relative paths, or not? For example:
<p>See <a href="urn:234lkj23/4lk2j#section1">section 1 of "The
Birds and The Bees</a> for more info.
</body>
If the user selects the link, what data goes to the proxy?
GET urn:234lkj23/4lk2j#section1 HTTP/1.0
or
GET urn:234lkj23/4lk2j HTTP/1.0
RFC1630 would suggest the latter. The current URL specs would suggest
the former, although it's not clear that it necessarily answers this
question. It's possible that a WWW client should remove #... at the
end of an HREF attribute before considering it as an internet URL.
Then suppose the resulting document (let's suppose the answer above is
urn:234lkj23/4lk2j ) contains:
<html>
<head><isindex><title>An Example</title></head>
<body>
<p> See <a href="../overview.html">the overview</a> for
more info.
What if the user selects that link? Is this an error? Must the process
of resolving urn:234lkj23/4lk2j yield some "local" address (ala the
HTTP URI: or Location: header or the HTLM <BASE> tag) for use
with relative HREF's?
Then suppose the user enters "frogs and dogs" as search keywords for
the ISINDEX search. What data goes to the proxy? RFC1630 would
suggest
GET urn:234lkj23/4lk2j?frogs+and+dogs HTTP/1.0
I suppose <isindex> doesn't have to work with methods besides http and
wais, but there's no reason for it not to. But perhaps a <FORM> is
necessary to search databases using other schemes...
>Frankly, I've never seen a need for multiple proxy servers. Has anyone
>ever used a different proxy for one protocol vs the other?
It's ironic that you would ask that in response to Michael's question:
clearly his scenario (testing a urn: proxy) motivates a capability to
select different proxies for different services. But it's not clear
that this feature is widely used...
Dan