I don't think this is correct. Any url can make use of the # directive.
It just tells a browser to go to a specific part of a document instead of
to the beginning. I don't know of any browsers that actually 'generate'
these internally.
But I think Peter is correct that, given a URL with a # inside it, the browser
doesn't send back the part beginning with #. That is, seeing the URL above, a
browser would ask www for a document /foo/bar.tar.Z and then look for the
anchor "blech.c" inside it--which is not what he wants.
The only problem with using ./ in the path would be that the browser
is likely to interpret it as a relative pathname. For example,
http://www/foo/bar.tar.Z#./blech.c would more than likely be translated
into http://www/foo/bar.tar.Z#/foo/blech.c by a browser.
It would be fairly easy to tell the replacing function not to replace
any . or .. after a # sign though. (I haven't tried this with mosaic or
lynx yet, but I know that my emacs browser would replace the ./ with nothing
so the url above would be http://www/foo/bar.tar.Z#blech.c)
As mentioned above, I don't think the browser should interpret the part after
# as part of a path, since the # character is supposed to be followed by an
anchorid and anchorids are not hierarchical. Wanted to note, though, that
according to the URL spec "/." may be simplified but "./" is not.
Of course, according to the URL spec gopher addresses have a slash between
gtype and selector, too, and that doesn't seem to have affected implementation
any.
-Bill Perry
-Erik