This is nothing but standard URI "
fragment identifier":
http://en.wikipedia.org/wiki/Fragment_identifier[
^].
So, there is nothing specific to gmail or facebook. One little twist is the combination with the index file naming schema, which creates the URLs of the form "https://mail.google.com/mail/u/0/#inbox". The part before "#inbox" can be creates as a directory on the file systems mapped to a site with a server, with some file named like "index.html", "index.htm" or the like. Actually, it can be any file name matching some wildcard-based naming schema prescribed in the HTTP server options. In this case, "#inbox" merely addresses some fragment location within this file, nothing special.
See also:
http://en.wikipedia.org/wiki/URL[
^].
That would be all, but…
At the same time, I must admit that the interpretation of the URL part after the
domain
or
domain:port
part (see the above article), could be completely custom and not related to actual file structure on the host of the server. There is a number of techniques supporting URLs not directly mapped to the file system. Some of such techniques are actually pretty much standard. To get in idea, you can learn about URL rewriting, URL mapping and URL routing (!):
http://en.wikipedia.org/wiki/URL_rewriting[
^],
http://msdn.microsoft.com/en-us/library/ms972974.aspx[
^],
http://en.wikipedia.org/wiki/URL_mapping#URL_mapping[
^],
http://support.microsoft.com/kb/976111[
^].
There are some techniques related to particular server-side scripting models, such as WSGI created just for Python:
http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface[
^].
Probably there are some other approaches. After all, nothing prevents you from creating your own HTTP server (and even from available components) and create your own mechanism for mapping the URIs. From the client side, you cannot really know what's going on.
—SA