Re: How can one use '#' in a URL?

Erik Ostrom (
Fri, 18 Jun 93 16:58:36 +0200

> - this would indicate to the server that it is to unpack blech.c from
>/foo/bar.tar.Z and send it back as a normal file. However, I have only
>seen the # documented as something which browsers can use for internal
>hyperlinks, not as part of the a URL that can be sent to a http server.
>Is this a problem?

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

-Bill Perry