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.
If the user selects the link, what data goes to the proxy?
GET urn:234lkj23/4lk2j#section1 HTTP/1.0
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:
<p> See <a href="../overview.html">the overview</a> for
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
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...