If we take:
http://example.com/foo
is it fair to say that:
ftp://example.com/foo
.. points to the same resource, just using a different mechanism for resolving it (and of course possibly a different representation, but perhaps not)?
This came to light in a discussion we were having surrounding some internal tooling with Git. We have to process some Git repositories, and they come to use as “git@{authority}/{path}” , however the library we’re using to interface with them doesn’t support the git protocol. I suggested that we should make the service robust in of that it tries to use HTTP or SSH, in essence, discovering what protocols/schemes are supported for resolving the repository at {path} under each {authority}.
This was met with some criticism: “We don’t know if that’s the same repository”.
My response was: “It had better be!”
Looking at RFC 3986, I see this excerpt:
URI “resolution” is the process of determining an access
mechanism and the appropriate parameters necessary to dereference a
URI; this resolution may require several iterations. To use that
access mechanism to perform an action on the URI’s resource is to
“dereference” the URI.
Which makes me think that the resolution process is permitted to try different protocols, because:
Although many URI schemes are named after protocols, this does not
imply that use of these URIs will result in access to the resource via the named protocol.
The only concern I have, I guess, is that I only see reference to the notion of changing protocols when it comes to traversing relationships:
it is possible for a single set of hypertext documents to be
simultaneously accessible and traversable via each of the “file”,
“http”, and “ftp” schemes if the documents refer to each other with
relative references.
I’m inclined to think I’m wrong in my initial beliefs, because the Normalization and Comparison section of said RFC doesn’t mention any way of treating two URIs as equivalent if they use different schemes. It seems like schemes named/based on IP protocols ought to have this notion, at least?
1
It’s common for static pages to be mapped by ftp also be available by http, but you should not assume this is the case. Anything else is almost certainly NOT the case. Many pages accessed by HTTP have some form of active processing, and for other protocols, GIT included, any resemblance between what you “git” and what FTP might see is purely coincidental.