If we take:


is it fair to say that:


.. 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?

  • In principle different URIs mean different semantics. There is a whole movement today called Linked Open Data that deals with such issues. Take a look at linkeddata.org if you want to understand more.
    – paxRoman
    Oct 10, 2012 at 7:51

1 Answer 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.